Adobe Reader/Acrobat Unspecified Buffer Overflow Vulnerability

Hello kareldjag,
I recently uninstalled Adobe reader and began using PDFX-Change Viewer. I am pleased with its capabilities. I read that it is wise to disable JavaScript Actions in this viewer, which I did. (As a side note, they became enabled again somehow, which is a bit of a puzzlement.) But my question for you is, do you know if there is a patch released for this viewer as there was yesterday for Adobe Reader?

 

Opening all PDFs in a Sandbox like GesWall is a good option even for less tech savy users.

 

Hi,
Foxit is not vulnerable to this JBIG2 eploit.
But another JBIG2 exploit make some version vulnerable:
http://secunia.com/secunia_research/2009-11/
But as PDF reader number two, it will be more and more attacked in the future.
As i said, it is not more secure than Adobe (Adobe has more hardening functions).
As a nix user for important things, i think that Pdftk is a must: http://www.accesspdf.com/pdftk/index.html

I'm sorry for Aigle but sandbox like Geswall are not necessary to open safely a pdf, just open it online with site and firefox extension like pdfescape (http://www.pdfescape.com/ ) or openitonline ( http://www.openitonline.com ).
More over Sandbox is not the ultimate barrier, and i've experimented remote code execution via pdf under Sandboxie protection: as usual thinking "security as a product" is a restricted vision of Security.

PDFX Change has a java script disabling option, but it's suited to check the box "show warning when java script executes" (this really helps in malicious script attempts, and it warns for instance for this Adobe exploit).
And NO, PDF X Change viewer does not need a patch for this vulnerability, simply because this exploit affects Adobe Reader, but not the reader that i've linked (PDF X Change viewer, ExpertPDF, Drumlin reader).
On the other hand, Sumatra PDF is affected and there is currently no patch.

Rgds

 

Yes, not must but a good option. Online opening is not feasible if you have to save pds files n open them off n on.
Agree that a products is not security but it most cases a sandbox will mitigate any harm. You have experienced remote code execution with SBIE, was it able to damage the system as well while bypassing SBIE?

 

I had to confirm this with Tracker Software Products (a poorly named company if I ever did see one!), and here is what I learned...

 

Yes - I stopped at v.6 and will continue to use it until it won't open a PDF. Adobe hasn't listed v. 6 as vulnerable to an exploit for quite a while. It doesn't have all of the fancy coding and add-ons as do the later versions. In other words, it remains a simple Reader for those who don't need the newer features.

Have you analyzed an exploit file found in the Wild so we can know if they are any different than already reported that I mentioned earlier? Lots of PoC stuff and worrisome rhetoric, but no additional substance so far, since the early ones reported are easily blocked by various solutions.

----
rich

 

eXPert PDF 4 Pro v4.1.670.404 (can view, edit and create PDF files) is offered for free there. It's a french page for a french version but you can hack it to use in english (by deleting the .fra files). Installed and working fine here, I am also using the light PDF-Xchange when only needing a pdf viewer.

 

Hello,

A few words I've compiled together:

http://www.dedoimedo.com/computers/pdf-vulnerabilities.html

Regards,
Mrk

 

Are you sure? From http://www.adobe.com/support/security/bulletins/apsb08-13.html: "Affected software versions: Adobe Reader 8.1.1 and earlier versions Adobe Acrobat Professional, 3D and Standard 8.1.1 and earlier versions." I think they just don't update versions prior to v7 anymore.

 

From that advisory, I cannot be sure. That is the first advisory I've seen where Adobe did not list all of the vulnerable versions.

The only way to tell, of course, is to test. But these PDF files are hard to come by. Fortunately, a few days ago a link to one was posted in another forum (link no longer works).

Sophos identified the file as

Troj/PDFJs-L
Type: Trojan

Opening in a text editor, the creation date is revealed:

/CreationDate (D:2009 03 30 232257)

This exploit is a variant. The original was analyzed here:

Analyzing a malicious pdf - Troj/PDFJs-A
http://realsecurity.wordpress.com/2008/09/04/analyzing-a-malicious-pdf-trojpdfjs-a/

Opening the file in Acrobat Reader v.6, I observed nothing unusual, except a strange text used as filler:



Some of the code contained in the PDF file, viewed in a text editor:



Looking at the page code for the downloading of the PDF file is instructive:

Code:

<script
			
document.write('<iframe src="cache/readme.pdf"></iframe')

First, it requires scripting to be enabled in the browser.

Second, it shows what can happen if the browser is configured to open PDF files in the browser.
In the exploit, the user is redirected from a legitimate site which as been hacked, to the malicious site
which hosts the PDF file. Upon connecting to the site, the PDF file loads into the i-frame and opens.
No click required:





Using Opera which I have configured to prompt for download:





I have always stressed that documents on the web should be prompted for download rather than opened in the browser.

In this case, the user will be alerted to something she/he did not go looking for.

----
rich

 

I believe Adobe probably won't list v6.x as vulnerable anymore because they probably don't even test that version, or even earlier ones, anymore. Their support policies are listed here. V6 was released around 6 years ago. It appears that the last update for v6.x was on 1/16/2007, more than 2 years ago already. From the latest security advisory:

 

Thanks for the information. Your conclusions sound logical.

I've been thinking about this exploit and how it differs from the earlier targeted exploits using documents, where infected documents (PDF, DOC, XLS) were sent to everyone on a company mailing list - the list having been compromised somehow. This exploit, of course, requires the victim to actually open the document.

Recent PDF exploits are by remote code execution, the example above using i-frame. This could also work using an MSOffice document, such as MSWord.

So, are these exploiting the application (MSWord) or the browser? A little of both, since the browser acts as the triggering mechanism which then calls to the application.

When accessing documents on the web, I've always advised people to have the browser prompt to download.
In Opera, Preferences are thus:



Configuring for .doc extension:



Taking the code from the PDF exploit and substituting a Word document I used in another test, where a macro loads a DLL which connects out to the internet:

Code:

<head>
<script>
document.write('<iframe src="hmmapi2k.doc"></iframe')
</script>
</head>

I run the code in IE6 and the document is loaded into the i-frame, then starts and loads the DLL:



Using Opera, the Download Prompt dialog box appears:



People can try this to see how their browser treats documents. Just put the above code into Notepad and save as an HTML file. Use your own document filename. Put the HTML file and the Word document in the same directory, then open the HTML file in your browser. Scripting has to be enabled for this test.

Question: If the above prompt were for a document on the internet, if I choose to Open the document, am I reading the document on the server where it is hosted? Or is the document downloaded, then opened in MSWord?

If you chose the latter, you know that anything an application or browser displays is read from the computer. The document is download, then opened in the program.

The same with web site pages. Checking the browser upon connecting to Wilders, I see that the page is cached (downloaded) which then displays in the browser:



Since everything is downloaded anyway, prompting to download documents first is just a wise precaution, IMO. You are alerted to anything suspicious; you get to specify where the document is stored; and an opportunity to scan, if so desired.

----
rich