Slashdot Mirror
Adobe Fixes Recent PDF Flaw, But Not Before Auto Exploit
SkiifGeek writes "With Adobe's patch for the JBIG2Decode vulnerability due in a few days time, new methods to target the vulnerability have been discovered that make it far riskier than previously thought. Didier Stevens recently showed the world how it is possible to exploit the vulnerability without the user actually opening an affected file, and now he has discovered a way that allows for completely automated exploitation that results in anything up to a Local System account without any user interaction at all and only relies upon basic Windows components and Acrobat Reader elements. There are some mitigating factors that limit the overall risk of this new discovery, but it does also highlight that merely uninstalling the Reader will not protect you from exploitation and does raise the possibility that other tools will access the vulnerable components and thus be vectors for attack." However, the fix is now in: nk497 writes "Adobe had finally released a fix for a PDF vulnerability discovered — and already exploited — last month. The update only applies to the most recent versions of Reader and Acrobat, with early versions and Unix editions not fixed until later this month. Adobe has taken its time with the patch, despite an independent security researcher releasing her own fix just days after the flaw was announced."
Do people even still use Acrobat Reader?
Yes.
It was vulnerable also, they got the patch out quicker.
http://www.networkworld.com/news/2009/030909-foxit-pdf-viewer-also-open.html
Yeah I didn't actually read that article, I had just heard that Fox-it had the vulnerability also and I just grabbed an article for Google as proof.
Shame on me, but in this case it is irrelevant.
Indeed. Just lazy design & programming.
As most good Windows admin know, it's helpful to keep a 'clean' PC or image around, with a 'base' install of the OS and required apps on it. When a nuked PC comes in, just backup user data and reimage from your base. I do a complete reinstall every year on my own machines. Amazing how much faster they are afterwards.
Why isn't there a decent open source PDF reader? Not Sumatra, it's just a little too basic.
I'm not volunteering though, I just don't care enough about PDF as a format, but it seems odd that nobody does. In theory the PDF format isn't that bad, but people mostly experience it though Adobe's reader which causes most of the problems.
http://en.wikipedia.org/wiki/List_of_PDF_software
Has the most common viewers.
"Adobe has taken its time with the patch"
Of course an independent research company was able to get a patch out quicker- they didn't have test their "fix" and they won't be held responsible if it breaks something else.
It is very naive to say this every time a patch for something is released by a company that "Slashdot" doesn't approve of. If I didn't know better I'd think the editors were just trying to get a rise out of the more childish component of their audience. (I know, I know, I must be new here.)
Unfortunately, the practice of leaving DLLs behind is not an easy one to solve. The problem lies in the fact that there are many installers that don't play nicely, either installing a DLL without properly registering its use with Windows, or making use of an existing DLL without doing the same. A "proper" Windows installer is supposed to update the registry(at least the last time I checked, haven't really taken the time to read the most recent guidelines) with a list of shared DLLs that it uses, so that Windows essentially has a count of the number of programs that use each DLL. The uninstaller is only supposed to remove a DLL if that count is at zero after removing the program being uninstalled from the count. But because of the many simple install/uninstall programs that don't properly handle this, you get either an uninstaller that leaves anything that is not in the app directory itself(i.e. anything in %windir%\system32), or one that asks you for what to do about each DLL that may be shared.
I believe it depends on the order of the install...since the modifications are made by the installer of the "new" program, it's my understanding that Acrobat Reader would have registered itself with Windows Indexing Service, not the other way around. So, the uninstall of Acrobat should have fixed the issue.
And how do you know that there isn't a vulnerability?
I'll let you in on a "secret". JBIG2 is a standard bi-level compression technique, that has been standardized. It uses statistical prediction, which makes for some interesting math. A standard reference implementation is available that works, and offers "reasonable" performance.
Almost every developer that is charged with JBIG2 implementation is going to use the reference implementation.
It is, of course, possible to generate other implementations. I wrote an alternate encoder that performed an order of magnitude more quickly for a client. But, it requires a great deal of analysis and skill to do so (no, I never touched decoding -- that was a hardware function. JBIG2 was used to transmit maps to a printer, which used a hardware decoder).
Anyone using an implementation based on the reference is probably at risk of an exploit (if that was the original source). So, you cannot state that using a non-Adobe product makes you safe (unless a source review is possible, and I suspect that the skill needed for defect detection in the JBIG2 decoder is probably beyond most C programmers as well).
But, the critical (and, unfortunately, "normal") problem of having service DLLs linked into core OS constructs certainly broadens the attack surface. Normal behavior (that is, incomplete de-installation) of system level components (because there is no reasonable way to determine the consequence of complete removal) simply exaggerates the issue.
I assume that your "alternative" also links into the shell constructs of Windows, exposing a similar attack surface.
You are probably not safe, either.
Just another "Cubible(sic) Joe" 2 17 3061
*Sigh* This isn't true. Some versions of the exploit used Javascript for the heap spray, but Javascript isn't required at all to exploit this issue.