Adobe confirms PDF backdoor, offers unsupported workaround

Adobe confirms PDF backdoor, offers unsupported workaround

Summary: In a pre-patch advisory, Adobe offered a complicated (and unsupported) workaround for its customers and promised a comprehensive fix will be ready before the end of October 2007.


Adobe confirms PDF backdoor, offers unsupported workaroundAdobe has fessed up to a dangerous code execution vulnerability affecting software programs installed on millions of Windows machines.

The flaw, publicly disclosed more than three weeks ago, could allow hackers to use rigged PDF files to take control of Window XP computers with Internet Explorer 7 installed.

The bug affects Adobe Reader 8.1 and earlier versions, Adobe Acrobat Standard, Professional and Elements 8.1 and earlier versions, and Adobe Acrobat 3D.

[SEE: ‘High risk’ zero-day flaw haunts Adobe Acrobat, Reader ]

In a pre-patch advisory, Adobe offered a complicated (and unsupported) workaround for its customers and promised a comprehensive fix will be ready before the end of October 2007.

The workaround involves disabling the mailto: option in Acrobat, Acrobat 3D 8 and Adobe Reader by modifying the application options in the Windows registry.

In its advisory, Adobe provided step-by-step instructions for manual editing of the registry but Windows users should be aware that careless registry editing can cause serious problems.

Adobe's public acknowledgment comes a day after Heise Security warned of similar URI handling bugs affecting a wide range of Windows applications. These include Skype (silently fixed), AOL's Netscape browser, mIRC and Miranda.

[SEE: Microsoft should block that IE-to-Firefox attack vector ]

According to security alerts aggregator Secunia, this is a "highly critical" Windows vulnerability that should be fixed by Microsoft but Redmond's security response officials have no such plans, insisting it is "very difficult" to put protections in place without breaking existing applications.

Topics: Windows, Enterprise Software, Operating Systems, Security, Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • The security cost of feature bloat

    A "mailto" feature in Acrobat Reader? Why, oh why? The vast majority of people who have Acrobat Reader installed only have it for those occasional times when web sites insist on providing certain documents only in PDF. Nobody wants to use Reader; when they have to use it, they want it to do its job and nothing else.

    Acrobat has gotten so bloated in the last several years, and now the cost of that bloat is coming back to bite Adobe.
    • Agreed.


      It seems absurd on its face -- but I found that one of the most significant changes I've made in my computing environment in recent years with regards to greatly reducing my blood pressure was uninstalling the absurdbly bloated and increasingly buggy Adobe reader and replacing it with the mostly very good and much, much lighter-on-its-feet FoxIt Reader.

      Adobe could have prevented the hemorrhaging of its Acrobat userbase by releasing an unubtrusive, non-resident "lite" version of its reader for those who don't want do deliver up a substantial amount of their computing power in order that Adobe can build in more and more back doors and undesired "functionalities" to a program that was initially designed to be a simple, straightforward document presentation applet.
  • many thanks to Adobe

    for publishing a workaround.

    It is not 'complicated' for many, including company security adminstrators. If legalities permit, perhaps it could be made into a click-installer.

    Microsoft once again looking like the big dummy. When will they get it through their heads that they can't be living in the 1980's any more, and playing stuffed shirts from their hack background.

    That'll be the day, as a certain large cowboy figure used to say. It will be a very fine day, actually.

    Narr vi
    • huh?

      An unfixed exploit exists in multiple versions of the bloated and buggy Acrobat reader and we should THANK Adobe and attack MS?

      I'm all for attacking MS on GP but Narr vi's take on this is unsupported here and, far as I can tell, may well be unsupportable anywhere in the logical universe.

      Granted that security in XP, Vista, and OSX should be better but when a vulnerability exists in an APPLICATION program I say that that program -- and its purveyors -- should be the first stop for the Blame Train.
  • Microsoft shares the blame, Apple blindly copies them

    URI and MIME type handling in both Windows and OSX is profoundly
    broken. It's second only to ActiveX in the opportunity for exploits... the
    basic problem is that when apps register handlers for local use (eg,
    'help:' or '.chm') they are available to untrusted content by default. The fix
    is to have separate registries or separate flags that allow applications to
    explicitly register as handlers for internal use, or for use on untrusted
  • Foxit is the way to go

    If I have to read websites that uses pdf I use Foxit instead. It's a small download compare to Adobe's bloated version. Never had a problem with it. Go Foxit. Get it at
    • xpdf works nicely as well. (nt)

      Henrik Moller
    • i use this too, it's great! (on xp)

      on ubuntu, I just use the built-in document viewer.
      Both mega fast compared to Acrobat.

      Acrobat used to be quite efficient back on version 3, but now it's absurd.

      How do large companies allow these bloatwares (like Office 2007 and Vista, and the current Acrobat) to get past their QA departments.

      The rare breed of Testers must be of sterner stuff than any I ever knew to be able to sit testing bloatware, waiting for it's molasses-like response.
    • Foxit option

      Given that I was unable to find any mention (let alone help) on the website for a known security problem (i.e., Adobe Acrobat backdoor), I tried Foxit and my first impression is that I really like it. The only thing I can complain about, and it is not really a complaint, is that most people are probably looking for a normal windows installer download and will probably not download the 3rd file down (the .msi package) on the windows files list (my initial mistake). Thank you for a link to a nice lean program that appears to be a terrific alternative to Adobe's presently bloated and apparently unsafe Acrobat Reader products.
  • RE: Adobe confirms PDF backdoor, offers unsupported workaround

    The Adobe registry change does not seem to apply to Acrobat version 7, at least on my WinXPpro PC, since there is no registry path to: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe
  • Responsible disclosure

    It shameful the way this vulnerability was handled. First pdp doesn't disclose it, just brags he has it. Then so-called "security researchers" goad him into sharing it. This boosts their egos, gains them press time, and in the process increases the risks for everone.
    • Who's the irresponsible party?

      At what point is it Adobe's responsibility to be proactive about internal QA?

      After all, URI handling issues have been in the news for months...

      Ryan Naraine
  • Adobe's fix instructions broken for Acrobat Pro 7.0

    Even though Adobe's advisory--which is about editing the Windows registry--says the vulnerability applies to Acrobat and Reader 8.1 and earlier, the registry locations given in the advisory for Acrobat do not exist at all--that is, there is no Adobe subsection under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\, precluding even monkey-piles-more-boxes-to-reach-higher-banana-class permutations of version number to find the therapeutic registry location--in this XP machine running IE7 and Acrobat Professional 7.0. (No, not in the corresponding location in HKCU--no bananas for you, either!)
  • RE: Adobe confirms PDF backdoor, offers unsupported workaround

    I got rid of Adobe last year-- I had been looking for an alternative for a while... when I found one it was gone immediately.
  • RE: Adobe confirms PDF backdoor, offers unsupported workaround

    This has nothing to do with Microsoft. And it's Mozilla's fault ANYWAYS. How the hell is IE supposed to know what a valid output is? IE's ONLY job is to take off the protocol handler (i.e. firefoxurl:) and then pass all the arguments untouched.
    • Sarcasm?

      wng_z3r0, I hope you were being sarcastic and not just way off-topic.
  • Another workaround

    You can use the Firefox extension PDF Download - it has an option to view as HTML (the PDF is downloaded to a server somewhere and converted to HTML). This is adequate if you just want to read the text, though it wrecks the formatting:
  • remote code execution flaw in Linux KDE with PDF files

    remote code execution in KDE with PDF files


    A remote attacker could entice a user to open a specially crafted PDF
    file in KWord or KPDF that would exploit the integer overflow to cause
    a stack-based buffer overflow in the StreamPredictor::getNextLine()
    function, possibly resulting in the execution of arbitrary code with
    the privileges of the user running the application.

    KOffice is an integrated office suite for KDE. KWord is the KOffice
    word processor. KPDF is a KDE-based PDF viewer included in the
    kdegraphics package.

    Affected packages

    Package / Vulnerable / Unaffected
    1 app-office/koffice = 1.6.3-r1
    2 app-office/kword = 1.6.3-r1
    3 kde-base/kdegraphics = 3.5.7-r1
    4 kde-base/kpdf = 3.5.7-r1
    4 affected packages on all of their supported architectures.
    • ...which flaws have already been fixed

      ..but because of how you have presented this information--in particular, the broken table that includes the "Package/Vulnerable/Unaffected" header (see the *correct* presentation of that info at Gentoo)--the effect is confusion at best and conveyance of the incorrect implication that the koffice, kword, kdegraphics, and kpdf packages listed in your message are vulnerable. To fix this, you must either take out the word "Vulnerable" from that heading, or add to the listings beneath it the <= listings that explicitly convey the packages that *are* affected.

      The bottom line is that this vulnerability has already been fixed in KPDF. Depending on the Linux distribution you use, the new packages may not yet have been promulgated to you as updates. but that's certainly in the works for all popular distributions.

      And the ongoingly cool underlying fact is that because GNU/Linux is open source, with just a bit of initiative effort one can rummage around and get what one needs to update one's GNU/Linux installations with the fixed code oneself. One can even fix the code oneself!

      With Adobe and Microsoft products, experts, regularbies, and newbies alike can all go hang: As a point of comparison, the Adobe PDF vulnerability has not yet been fixed--*and* their posted registry-edit-based workaround *does not work* for many, many existing installations.

      For now I've installed FoxIt as the default PDF handler/reader on all Windows machines I control.
      • The flaw fixed by Adobe in Reader 8

        Reader 8 contains now a validator and new settings for enabling or disabling the rendering of external dataflows (such as external documents, or images loaded freom the web) which are created by specifying a URI within the PDF document.

        By default, it disables all external dataflows, however, specific external URIs can now be enabled in Reader's user settings within the new Security manager option panel.
        With this panel, you can enable specific URIs, however it validates the format of URIs and will reject "mailto:" URIs as valid external data flows; but it will allow you to specify specific "mailto:" URIs for example if the PDF contains code such as a input form document which is to be submitted via email to the author of the PDF document.
        However this panel will not allow you to specify invalid "mailto:" URIs, because Reader first validates its format, instead of giving it directly to the Windows Shell for external execution and delivery.

        The current active bug involves URIs starting by

        mailto:%/../../../windows/system32/cmd.exe /c/q "command/line..."

        embedded within a PDF/PostScript dataflow named "/URI()" and interpreted by the internal PostScript interpret within Reader. The "specially crafted URI" contains a very long string before the "" part of the mailto address. Syntaxtically, it is not invalid, but the long string matween "mailto:" and the next "@" is interpreted as ifit was a user name in the email address, however the whole URI is too long for Windows and somewhere, the URI is truncated, and the string after "mailto:" is directly executed by the shell, which does not see the "" part, and so it is executed.

        Here the cmd.exe processor is found by the shell at the specified location, and its command line interpreted by cmd.exe to perform any action. The current action currently creates a batch of commands to be executed by cmd.exe, in a invisible window, and this batch contains various commands to disable your Windows firewall, create files, downloading some file by FTP from the internet, and running it.

        Reader now will reject the specified "mailto:" address because it does not conform to the normal URI format for email addresses, but also it will invalidate it because the domain is not authorized, or the username part is too long according to recommanded practice, and cause buffer overflows or truncation in agents (like the Windows Shell) that handle the "mailto:" URI protocol, causing the normal agent handling the URI (as set in your registry, protocol by protocol) to not be used, but another application to be run.

        The new Reader 8 configuration panel disables the external dataflows by default. You may enable it, but it will need to be configured to allow specific URI protocols, and approved domain names for each protocol (like "http:" or "https:" or "ftp:", the normal usage of the external dataflow, but also the "file:" protocol which is very dangerous to permit blindly, as the dataflow will be read using the broken Windows Shell service.)

        In other words: the Windows Shell has been patched to avoid buffer overflows, but this was done by forcing buffer truncation, without seeing if this affected the semantic of the URIs. Here the truncation by the shell transforms a "mailto:" URI into a URI that can't be processed by your email reader (note that Windows remove the "mailto:" prefiix from the URI before sending it to the associated mailto URI handler), so it gives it back to the shell which attempts to open it without the leading protocol. This is what is causing the specified local program to be launched by the shell.

        This is against the specification of the "mailto:" URI scheme; This would not have happened if the Windows Shell ALSO validated preventively the URI schemes and their format, before truncating the URI stupidly and sending it to the installed protocol handler.

        We should expect soon security patches in Outlook, Outlook Express as well as many email agents, whose URI validator is not safe. Another security patch shoud be included in the Shell itself, allowing it to validate the URIs even before giving it to a URI handler (for now it does not validate the format because there's no setting in the Shell to specify the format, but just an association between a URI scheme like "mailto:" and a URI handler to which it redirects, by delegation, the rest of the URI without the URI shecheme prefix).

        The windows Shell needs new settings for protocol handlers, at least for all the wellknown (and almost universally present) protocols supported by Windows: maximum length, formal syntax, or a builtin parser for these wellknown formats.

        And Windows needs now a URI validation API for use by all applications, instead of forcing each application to rewrite the same code, more or less successfully.