in

eEye Digital Security

The endpoint to vulnerability starts here.

 

Audit ID 9826 Microsoft Visual Studio ATL Vulnerabilities (969706) - VS 2008 SD

Last post 11-20-2009 4:59 AM by carmstrong. 5 replies.
Page 1 of 1 (6 items)
Sort Posts: Previous Next
  • 10-21-2009 6:25 AM

    Audit ID 9826 Microsoft Visual Studio ATL Vulnerabilities (969706) - VS 2008 SD

     I have been trying to figure this one out.  All my windows XP SP3 machines, the Scan says that file C$\Program Files\Microsoft Visual Studio 9.0\VC\ce\dll\x86\atl90.dll is version 9.0.21022.220 and should be at 9.0.30729.4154.  MS09-035 is installed as well as other KB's associated according to a WSUS report .  Is this another type of 3rd party add in? How can I get rid of this vulnerability?

  • 10-22-2009 3:56 PM In reply to

    • bpatten
    • Top 10 Contributor
    • Joined on 09-24-2007
    • Irvine, CA
    • Posts 125

    Re: Audit ID 9826 Microsoft Visual Studio ATL Vulnerabilities (969706) - VS 2008 SD

    What audit version do you have?

  • 10-23-2009 5:49 AM In reply to

    Re: Audit ID 9826 Microsoft Visual Studio ATL Vulnerabilities (969706) - VS 2008 SD

     5.10.18.2150

  • 10-29-2009 3:24 PM In reply to

    • bpatten
    • Top 10 Contributor
    • Joined on 09-24-2007
    • Irvine, CA
    • Posts 125

    Re: Audit ID 9826 Microsoft Visual Studio ATL Vulnerabilities (969706) - VS 2008 SD

    Clearly its not updated, and could be installed from a 3rd party app which may or may not be vulnerable. I can suggest downloading the MS patch and manually extracting the updated version and overwriting the old dll, but this may cause your 3rd party app to not properly fuction. Its advised that you determine what application installed it and seek the application owner to update it. The MS advisory only speaks to Microsoft products.

    Hope that helps.

     

  • 10-30-2009 10:25 AM In reply to

    Re: Audit ID 9826 Microsoft Visual Studio ATL Vulnerabilities (969706) - VS 2008 SD

     I would love to try that.  I have read on extracting the files from a patch but have not had much luck on doing that.  Google did not help.  Hate to be a burden, but can you tell me how to do that?

  • 11-20-2009 4:59 AM In reply to

    Re: Audit ID 9826 Microsoft Visual Studio ATL Vulnerabilities (969706) - VS 2008 SD

    Disclaimer: I'm at home, it's late.... I'm doing this off the top of my head and will probably get deeper than I need to resulting in more confusion.  Trivial spelling errors should be overlooked and an understanding of Microsoft's SideBySide is required in order to make sense of this reply.

    Your FP is the result of MS's SideBySide (SxS) implementation to deal with "DLL Hell". What the hell were they thinking?

    It was just recently that we were made aware of the SxS problem with the audit that addresses MS03-048 (I think? Sorry, REVISIT MY DISCLAIMER). Anyway, it deals with gdiplus.dll, mso.dll, and vgx.dll which are all subjected to SxS . 

     Audits that rely on the version of a file with an absolute path specified in the audit become victims of SxS if they are included  in the registry hive "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs". Visual Studio DLLs are considered shared DLLs and are at the mercy of the SxS implementation, thus the FPs. To complicate matters, SxS is not limited to just the files in this registry hive when determining the actual version of a system DLL. I will only focus on shared DLLS since I'd be here all night explaining the quirks.

    What??

    The original installation of a file will always reside in it's destination path. If you open Explorer under XP/2003 and look at the version date of say, system32\gdiplus.dll, it will show the attributes of the original installation even though you know you've installed patches that have updated the file. What the %*%*#???? The good news is that programs requiring a "SxS controlled" DLL will always use the latest version (tucked away by SxS under C:\Windows\winsxs\???) and not the version Explorer reports. The bad news is that Retina, like Explorer, obtains file version information via API calls that don't take SxS into consideration which can lead to FPs.     

    Huh???

     When a file is controlled by SxS, it uses "Soft Links" (it might be Hard Links) to redirect file access to the latest version maintained by SxS. When a program loads a DLL, the LoadLibrary() API call is used and is aware of these links and finds the latest version. Just like links in Linux; transparent and kewl. What's not kewl is the fact that MS didn't make all APIs relating to file access "Soft Link/SxS" aware. eeerrrrrr...............

    So what will eEye do?

     EeEye will do whatever it takes. SxS exposure is an issue and MS should provide SxS awareness in all their APIs or at least document how it works. Since we can't wait for MS, I've implemented my own SxS awareness into Retina for XP/2003 targets. At this time it is only applicable to the audit mentioned above. We are still researching the ramifications of making all audits that deal with file versions SxS aware.

    Besides the audits that deal with Visual Studio DLLs, only a small handful of other audits are subjected to the SxS trickery. We will have this issue resolved soon so bear with us! 

    Hmmm...  Maybe I should have just replied that "We know this is an issue and we are working on it." :-)

    Craig Armstrong

    Senior Engineer

    Team Retina

    carmstrong
    Sr. Software Engineer
    Retina Team
Page 1 of 1 (6 items)
© 1995 - 2009 eEye Incorporated