[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <09130A33C60C9C4982D35105CBABB278561ABCAD@Exchange.hammerofgod.com>
Date: Mon, 23 Nov 2009 17:11:13 -0800
From: "Thor (Hammer of God)" <thor@...merofgod.com>
To: "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: RE: Millions of PDF invisibly embedded with your internal disk paths
Knowing the path of the home directory of an unknown host has little, if any, value. Even if you know the host, you would have to get the user to run code interactively to leverage this "privacy issue" in addition to ensuring that the interactive user was indeed the same user that created the PDF doc. And that code would have to be written specifically for that particularly host/user, which is inefficient (barring network based home directory settings). Any time I've needed local user path for proof-of-concept code, I simply parse the HOMEPATH environmental variable to ensure the code runs properly and that it can be easily applied to any host.
t
-----Original Message-----
From: Inferno [mailto:inferno@...urethoughts.com]
Sent: Monday, November 23, 2009 7:46 AM
To: bugtraq@...urityfocus.com
Subject: Millions of PDF invisibly embedded with your internal disk paths
Millions of PDF invisibly embedded with your internal disk paths
----------------------------------------------------------------
I found an interesting privacy issue while analyzing PDF files. This bug
occurs when you are using Internet Explorer to print locally saved web pages
as PDF and affects all IE versions including IE8. It does not matter which
PDF generation software you are using like Adobe Acrobat Professional,
CutePDF, PrimoPDF, etc as long as you are invoking it from inside the IE
print function. In Windows, even when your default browser is not IE and if
you right click a file to select the PRINT from the context menu, then by
default it invokes the IE print handler. So, you will still see this issue
in the generated PDF.
This bug is NOT ABOUT the local disk path appearing in the FOOTER of your
pdf since it is clearly visible and already known by most people. This is
easy enough to hide by just going File -> Page Setup -> Change the Footer
value from "URL" to "-Empty-". After doing that, you will not expect your
internal disk path being put anywhere else. However, that does not happen.
The privacy issue arises from the fact that your local disk path gets
invisibly embedded inside your PDF in the title attribute. Only when you
open the file in an Editor like Notepad, you will see it. Currently, there
is no option in IE to disable it. The only workaround is to manually nullify
this value by editing the PDF file. Note that this problem does not occur
when using other browsers such as Firefox and Chrome. In fact, Chrome
handles the other footer issue intelligently as well by showing your disk
path as ".", rather than exposing it.
Proof of Concept:
-----------------
Steps to reproduce:
-------------------
1. Pick a .HTM or .HTML or .MHT file on your local computer.
2. Open this file in IE and click Ctrl-P.
OR Right-click the file in explorer and select PRINT from context menu.
4. Select any PDF writer as Printer such as Adobe PDF / CutePDF / PrimoPDF /
etc.
5. Click Print. When the PDF writer asks for a filename, provide any name.
6. Open the generated pdf in notepad, and search for "file://" without
quotes.
Search for this on your favorite search engine (Google/Bing)
------------------------------------------------------------
filetype:pdf file c (htm OR html OR mhtml)
Google Search 1 (for drive C)
[http://www.google.com/search?hl=en&q=filetype%3Apdf+file+c+%28htm+OR+html+O
R+mhtml%29&btnG=Search&aq=f&oq=&aqi=] - 4 million results
Google Search 2 (for drive D)
[http://www.google.com/search?hl=en&q=filetype%3Apdf+file+d+%28htm+OR+html+O
R+mhtml%29&btnG=Search&aq=f&oq=&aqi=] - 13 million results
and so on.. (I added till drive letter J and total was more than 50
million..)
So, out of 280 million pdfs accessible on the internet, more than 20% look
to be exposing internal disk paths which is a huge number. I have contacted
the Microsoft and Adobe Security Teams about this issue. Microsoft has plans
to fix this in IE9, while Adobe has opened the case but hasn't planned the
timelines yet.
Examples:
http://www.eda.gov/PDF/EDA_vol1;%20Issue10.pdf
01.<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 4.0-c316
44.253921, Sun Oct 01 2006 17:14:39">
02. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
03. <rdf:Description rdf:about=""
04. xmlns:dc="http://purl.org/dc/elements/1.1/">
05. <dc:format>application/pdf</dc:format>
06. <dc:creator>
07. <rdf:Seq>
08. <rdf:li>LewtasS</rdf:li>
09. </rdf:Seq>
10. </dc:creator>
11. <dc:title>
12. <rdf:Alt>
13. <rdf:li xml:lang="x-default">file://C:\Documents and
Settings\lewtass\Desktop\eda newsletter</rdf:li>
14. </rdf:Alt>
15. </dc:title>
16. </rdf:Description>
http://www.oregon.gov/OMD/OEM/plans_train/grant_info/fy2009_hsgp_investment_
justification.pdf
01.<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="3.1-701">
02. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
03. <rdf:Description rdf:about=""
04. xmlns:pdf="http://ns.adobe.com/pdf/1.3/">
05. <pdf:Producer>Acrobat Distiller 7.0.5 (Windows)</pdf:Producer>
06. </rdf:Description>
07. <rdf:Description rdf:about=""
08. xmlns:xap="http://ns.adobe.com/xap/1.0/">
09. <xap:CreatorTool>PScript5.dll Version 5.2.2</xap:CreatorTool>
10. <xap:ModifyDate>2009-03-18T15:07:10-07:00</xap:ModifyDate>
11. <xap:CreateDate>2009-03-18T15:07:10-07:00</xap:CreateDate>
12. </rdf:Description>
13. <rdf:Description rdf:about=""
14. xmlns:dc="http://purl.org/dc/elements/1.1/">
15. <dc:format>application/pdf</dc:format>
16. <dc:title>
17. <rdf:Alt>
18. <rdf:li
xml:lang="x-default">mhtml:file://O:\fema\shsp_2009\draft ijs\fy 2009
investment jus</rdf:li>
19. </rdf:Alt>
Share:
Thanks and Regards,
Inferno
Security Researcher
SecureThoughts.com
Powered by blists - more mailing lists