TA10-238A: Microsoft Windows Insecurely Loads Dynamic Libraries

Original release date: August 26, 2010
Last revised: --
Source: US-CERT

Systems Affected

Any application running on the Microsoft Windows platform that uses dynamically linked libraries (DLLs) may be affected. Whether or not an application is vulnerable depends on how it specifically loads a DLL. Please see the Vendor Information section of Vulnerability Note VU#707943 for information about specific vendors.


Due to the way Microsoft Windows loads dynamically linked libraries (DLLs), an application may load an attacker-supplied DLL instead of the legitimate one, resulting in the execution of arbitrary code.

I. Description

Microsoft Windows supports dynamically linked libraries (DLLs) that are loaded when needed by an application. DLLs are typically loaded when the application is first started; however DLLs may be loaded and unloaded while the application is running. An application can request a DLL file in a variety of ways, and Windows uses several different search algorithms to find DLL files. The interaction between the application and Windows can result in a DLL file being loaded from the current working directory of the application, instead of the Windows system directory or the directory where the application is installed.

The current working directory could be the desktop, a removable storage device such as a USB key, a Windows file share, or a WebDAV location. When a file associated with an application is opened, a DLL in the same directory as the file may be loaded. Although an attacker may not have permission to write to the Windows system or application directories, the attacker may be able to write a DLL to a directory used to store files, or the attacker could provide their own directory.

Attacks against this type of vulnerability have been referred to as "binary planting." Please see Vulnerability Note VU#707943 and Microsoft Security Advisory 2269637 for more information.

II. Impact

By placing a DLL with the correct name (and possibly the relative directory path) in the current working directory, an attacker could execute arbitrary code with the privileges of the application that loads the DLL.

III. Solution

Individual applications that run on the Windows platform may require patches or updates. Microsoft Knowledge Base article KB2264107 describes an update that provides a registry key that can prevent Windows from searching the current working directory for DLL files.

Information about specific solutions for different vendors, general mitigation techniques, and secure ways for applications to load DLLs can be found in the Vendor Information and Solution sections of Vulnerability Note VU#707943.

IV. References

Feedback can be directed to US-CERT.

Produced 2010 by US-CERT, a government organization. Terms of use

Revision History

August 26, 2010: Initial release

TA10-231A: Adobe Reader and Acrobat Vulnerabilities

Original release date: August 19, 2010
Last revised: --
Source: US-CERT

Systems Affected

  • Adobe Reader 9.3.3 and earlier versions for Windows, Macintosh, and UNIX
  • Adobe Acrobat 9.3.3 and earlier versions for Windows and Macintosh
  • Adobe Reader 8.2.3 and earlier versions for Windows, Macintosh, and UNIX
  • Adobe Acrobat 8.2.3 and earlier versions for Windows and Macintosh


Adobe has released Security Bulletin APSB10-17, which describes multiple vulnerabilities affecting Adobe Reader and Acrobat.

I. Description

Adobe Security Bulletin APSB10-17 describes a number of vulnerabilities affecting Adobe Reader and Acrobat. These vulnerabilities affect Reader and Acrobat 9.3.3, earlier 9.x versions, 8.2.3, and earlier 8.x versions.

An attacker could exploit these vulnerabilities by convincing a user to open a specially crafted PDF file. The Adobe Reader browser plug-in, which can automatically open PDF documents hosted on a website, is available for multiple web browsers and operating systems.

II. Impact

These vulnerabilities could allow a remote attacker to execute arbitrary code, write arbitrary files or folders to the file system, escalate local privileges, or cause a denial of service on an affected system as the result of a user opening a malicious PDF file.

III. Solution


Adobe has released updates to address this issue. Users are encouraged to read Adobe Security Bulletin APSB10-17 and update vulnerable versions of Adobe Reader and Acrobat.

Disable JavaScript in Adobe Reader and Acrobat

Disabling JavaScript may prevent some exploits from resulting in code execution. Acrobat JavaScript can be disabled using the Preferences menu (Edit -> Preferences -> JavaScript; uncheck Enable Acrobat JavaScript).

Adobe provides a framework to blacklist specific JavaScipt APIs. If JavaScript must be enabled, this feature may be useful when specific APIs are known to be vulnerable or used in attacks.

Prevent Internet Explorer from automatically opening PDF files

The installer for Adobe Reader and Acrobat configures Internet Explorer to automatically open PDF files without any user interaction. This behavior can be reverted to a safer option that prompts the user by importing the following as a .REG file:

Windows Registry Editor Version 5.00


Disable the display of PDF files in the web browser

Preventing PDF files from opening inside a web browser will partially mitigate this vulnerability. If this workaround is applied, it may also mitigate future vulnerabilities.

To prevent PDF files from automatically being opened in a web browser, do the following:

1. Open Adobe Acrobat Reader.
2. Open the Edit menu.
3. Choose the Preferences option.
4. Choose the Internet section.
5. Uncheck the "Display PDF in browser" checkbox.

Do not access PDF files from untrusted sources

Do not open unfamiliar or unexpected PDF files, particularly those hosted on websites or delivered as email attachments. Please see Cyber Security Tip ST04-010.

IV. References

Feedback can be directed to US-CERT.

Produced 2010 by US-CERT, a government organization. Terms of use

Revision History

August 19, 2010: Initial release

Internet Explorer considered harmful

Now that this paper is officially public, the full story of CSS-based cross-origin theft can come out. (As an aside I'd like to note that I contributed little other than review to the paper so credit must go to the other named individuals).

For background reading, see my Dec 2009 original post and an update that notes Firefox fixing the issue.

In the original post, I state two mitigating factors that prevent the attack being very serious: the fact that quotes and particularly newlines stop the attack from working due to the way CSS parsing is specified.

It turns out that Internet Explorer is not compliant in either of these aspects, leaving it more vulnerable that the other browsers. Not only is it the most vulnerable, but it is also the only browser to not have a fix available for its latest stable version. Fully patched IE8 is still vulnerable.

For an example of how easily data can be stolen cross-origin, try this demo in IE:


It uses the font-family CSS property to steal all text from the injection point up to the next ; character. Alternatively, to get more control, we can use background-image:url( which will steal all text from the injection point up to the next ); sequence (which can be useful as it is less likely to occur by 'accident').

I have PoCs which will steal your webmail's XSRF token, with follow-on loss of account integrity and confidentiality. It's a nasty attack: e-mail someone a link and if they click it, they are owned with a pure browser cross-origin bug. I don't think it would be productive to share any PoCs at this time.

Talking to some greyhats, I was surprised to learn this bug has been public since at least 2008. If you speak Japanese, see:


That's a dangerously long time for such a bug to be live and known by hackers.

Browsers are complicated pieces of software and will always have bugs. Time-to-fix therefore matters for a browser. If security is a factor in your browser choice, I recommend you look at Opera or Chrome. These browsers fixed this bug the fastest.

Firefox fixes CSS-based cross-origin theft issue

Firefox just released version 3.6.7 of their excellent browser, and it fixes this:


This leaves 4 of the 5 major browsers with fixes (more on this in an upcoming post), which is my threshold for documenting a little tweak to exploitability. It is partially inspired by Gareth Heyes' attack on E4X using character set overrides. For interesting background reading, see:


Turns out, the same character set override applies to loading cross-origin CSS via the <link> tag. This means that you can use UTF7 in Firefox to get around one of the key restrictions in the original attack. Specifically, you can force the CSS to be interpreted as UTF7, which makes injecting either type of quote (single or double) trivial to do without it getting escaped. Of course, the larger newline-related restriction remains in sane browsers.

Also, it's worth documenting how the character set override works. Interestingly, in all the browsers I tested (Chrome, Firefox, Safari) -- any character set specified in a site's HTTP headers has a higher precedence that the attacker's attempted override in the <link> tag. Useful. You should always specify character sets where possible. It has also defended against other previously unknown attacks in the past.

One final note is that not all browsers support UTF7. Chrome for example does not. I'm sure no-one would shed tears if UTF7 died.