14 Replies Latest reply: Dec 23, 2009 12:15 PM by mbc RSS

Is Nessus scanning for the new Zero-Day Adobe Read flaw

Good morning,

 

As you likely know there is a new Zero-Day Adobe Reader / Adobe Actobat v9.2 or earlier flaw,

apparently published on 12/15/2009.

 

Any chance that the Nessus 4 scanner is already scanning for this?

 

http://www.adobe.com/support/security/advisories/apsa09-07.html

 

Thanks and Best Regards,

 

TheGoose

  • Re: Is Nessus scanning for the new Zero-Day Adobe Read flaw
    Renaud

    Hi there,

     

    We published two plugins last night: plugin 43182 (Acrobat) and 43183 (Acrobat Reader) check wether Adobe's workaround has been put in place.

     

     

    Thanks,

     

    -rd

  • Re: Is Nessus scanning for the new Zero-Day Adobe Read flaw
    rbabcock

    Your plugin looks at

      HKLM\SOFTWARE\\Policies\\Adobe\\Adobe Acrobat\\'+ver[0]+'.0\\FeatureLockDown\\cJavaScriptPerms

    and

      HKLM\SOFTWARE\\Adobe\\Adobe Acrobat\\'+ver[0]+'.0\\JavaScriptPerms

    That's where

      http://kb2.adobe.com/cps/504/cpsid_50431.html

    says blacklists should be found.  But if I look at the .reg files Adobe provides for end users, the blacklist entry is made under HKCU.

    Is this an undocumented location for blacklists?  If so, it's a bad one because it won't be seen if a different user logs in and remote

    scanners can't see it.

     

    Also, I notice that the above Adobe TechNote says the blacklist is at

      HKLM\SOFTWARE\Wow6432Node\Adobe

    for 64-bit Windows systems.

     

    Looking again, the reader plugin adobe_reader_apsa09-07.nasl is using the same registry path as the Acrobat plugin.

    The product for reader should be "Acrobat Reader" not "Adobe Acrobat".

    • Re: Is Nessus scanning for the new Zero-Day Adobe Read flaw
      rbabcock

      Adobe has silently updated the reg files for end users.  They now point to HKLM, not HKCU.

      I've still got the file APSA09-07_C_Reg_Keys.zip I downloaded originally, and it says HKCU.  The Enterprise .reg files are unchanged.

       

      So anyone who was diligent and applied the workaround right away thinks they are protected but really they are not.  Thanks Adobe.

    • Re: Is Nessus scanning for the new Zero-Day Adobe Read flaw
      theall

      rbabcock wrote:

       

      Also, I notice that the above Adobe TechNote says the blacklist is at

        HKLM\SOFTWARE\Wow6432Node\Adobe

      for 64-bit Windows systems.

       

      While the plugins don't specifically mention those locations, our API will fall back to looking under HKLM\SOFTWARE\Wow6432Node when the target is a 64-bit system and the entry is not found under HKLM\SOFTWARE.

      Looking again, the reader plugin adobe_reader_apsa09-07.nasl is using the same registry path as the Acrobat plugin.

      The product for reader should be "Acrobat Reader" not "Adobe Acrobat".

       

      Yes, that's how Adobe handles the blacklist in both products. We published separate plugins, though, because they each look at the associated product version number and may use that to report the vulnerability.

       

      George

  • Re: Is Nessus scanning for the new Zero-Day Adobe Read flaw

    It seems to me that this plugin may not be functioning as effectively as possible.  This vulnerability affects all versions of Adobe 9.2 and 8.1.7 and lower.  For example, if I scan a machine that is running version 8.1.6, the vulnerability is not detected.

     

    Also, in my understanding, the Adobe JavaScript Framework Blacklist is only available in versions 9.2 and 8.1.7.  Please refer to the following link: http://kb2.adobe.com/cps/504/cpsid_50431.html.  Because of this, the registry key only mitigates the vulnerability if the current version of Adobe (9.2 or 8.1.7) is installed.  I ran a test where the registry key was created on a machine running version 8.1.2.  In this case, Nessus did not report the vulnerability.

     

    Would it be possible to enhance the plugin to where he machine passes the check only if the following conditions exist?

     

    • The installed version of Adobe is 9.2 or 8.1.7

         AND

    • The JavaScriptPerms\tBlackList\DocMedia.newPlayer registry key exists in HKEY_LOCAL_MACHINE
    • Re: Is Nessus scanning for the new Zero-Day Adobe Read flaw
      rbabcock

      Won't older versions of Acrobat be flagged as having other security vulnerabilities (assuming the appropriate plugins are enabled)?

    • Re: Is Nessus scanning for the new Zero-Day Adobe Read flaw
      Tenable Brian

      The plugins do two different checks.  The first check:

       

       

      # For 9.2 and 8.1.7, check for the JS workaround

      if (

        (ver[0] == 9 && ver[1] == 2 && ver[2] == 0) ||

        (ver[0] == 8 && ver[1] == 1 && ver[2] == 7)

      )

      {

        # ...checks the registry...#
      }

       

      This is the check that you suggest near the end of the comment, so I think we're on the same page there.
      If 9.2 / 8.1.7 is _not_ installed, the plugin will attempt another check:

       

      # For all earlier versions, do a version check.  Since we can't determine if
      # the workaround (disable javascript) has been enabled on earlier versions,
      # only do the version check when paranoid
      if (report_paranoia < 2)
        exit(1, "This plugin only runs if 'Report paranoia' is set to 'Paranoid'.");
      if
      (
        (ver[0] == 9 && ver[1] < 2) ||
        (ver[0] == 8 && (ver[1] < 1 || (ver[1] == 1 && ver[2] < 7))) ||
        (ver[0] < 8 && ver[0] >= 6)  # Doc.media.newPlayer was introduced in 6.0
      )
      {
        # report as vulnerable
      }

       

       

      "Customers who are not able to utilize the JavaScript Blacklist functionality can mitigate the issue by disabling JavaScript in Adobe Reader and Acrobat using the instructions below:

      1. Launch Acrobat or Adobe Reader.
      2. Select Edit>Preferences
      3. Select the JavaScript Category
      4. Uncheck the 'Enable Acrobat JavaScript' option
      5. Click OK"

       

      Since this is a user-specific setting, testing for it is impractical.  So in order to avoid potential false positives, the plugins will only report a vulnerability if you're scanning in Paranoid mode.