Export (0) Print
Expand All

GDI+ 1.0 Security Update Overview

 

Cyra Richardson
Lead Program Manager, GDI+

October 2004

Applies to:
   Microsoft Windows
   GDI+

Summary: This document provides IT professionals and developers with an overview of the recent security fixes to GDI+. Included is an outline of the buffer overrun vulnerability, and information necessary to help you identify applications at risk, APIs that expose risk, and existing versions of GDI+ installed on your system. Please refer to Microsoft Security Bulletin MS04-028, Buffer overrun in JPEG processing (GDI+) could allow code execution. (5 printed pages)

Vulnerability

A buffer overrun vulnerability exists in the GDI+ processing of image formats that could allow remote code execution. An attacker who successfully exploits this vulnerability could take complete control of an affected system.

How to Determine if GDI+ Is On Your System

Either your operating system or your application can provide GDI+. The Windows XP and Windows Server 2003 operating systems install their own version of GDI+ onto your PC during setup. Microsoft, through Windows Update, is already distributing an updated GDI+ that fixes the buffer overrun. The Side-by-Side system service (SxS) manages installation and instantiation of the different versions of GDI+.

Applications that require GDI+ may install their own copy of GDI+ during their setup. Unfortunately, at this time there exists no single method for updating application local copies of GDI+.

For End Users and IT Administrators

It is frustrating when applications function improperly, or worse, break your system. For application developers, it is also frustrating when APIs or services they depend on compromise their applications. While it is possible that applications that use GDI+ may be susceptible to its vulnerabilities, it is conversely true that fixes to GDI+ scale across applications as well. Unfortunately, not all applications will have updates available to their customers as quickly as everyone might like. The important thing to keep in mind is that even though an application uses GDI+, it will not be vulnerable unless it accesses the right image and it has a stack frame that can be exploited by the vector.

This situation quite naturally leaves individuals and organizations wondering if they have applications that use GDI+. Currently there is no single conclusive system or utility to identify which applications on your system are using GDI+. The more germane question might be, where are all the copies of GDI+? While there is currently no conclusive method, one could search for all of the GDIPLUS.DLLs on the computer in question. Because applications typically install GDI+ in their program directory, you can make an educated guess about the application that is using GDI+ based on the file folder. Windows installs its copies of GDI+ under the %%SysDir%%\WinSxS directory. Note that this method is not foolproof. Some applications have renamed the DLL so that it no longer appears as GDIPLUS.DLL. Other applications may have installed their own copy of GDI+, but use the system-provided DLL.

For customers that are concerned about determining which version of the gdiplus.dll file that is in use by an application, you may be able to use a third-party tool to make that determination. The Process Explorer utility from http://www.sysinternals.com/ntw2k/freeware/procexp.shtml states can help determine the files that are loaded by an application. This may be able to help you determine which instance of the gdiplus.dll file is used by an application. Since this tool is dynamic, you would have to run it through your complete application suite in order to hope to identify the correct application, but it is a little more deterministic than using the DLL directory as an indicator. This is a non-Microsoft, third-party utility and is not supported by Microsoft.

Applications running on Windows XP or Windows Server 2003 that have not renamed the DLL would utilize the operating system dll, even if they installed their own copy of GDI+ (assuming, of course, the developer has followed all of the guidelines for safe use of side-by-side components, and the administrator has not done anything to explicitly bypass the central update). As mentioned earlier, applications that use GDI+ are not automatically vulnerable. The application must accept new images or allow users to input, change, or open image files. Only in the situation where new or changed image files are introduced to the application is the presence of the DLL a potential indicator of vulnerability.

Looking into Applications

After potentially identifying an application at risk, customers have asked about running the application code through a debugger to attempt to verify that it uses dangerous APIs. Any GDI+ application that opens an image file that may have been modified is potentially at risk, so the value of going through this exercise may be minimal. Simply opening an image is a risky operation. The most risky behaviors involve directly reading metadata and performing pointer arithmetic based on that data.

Fixing Applications

Though there may be significant desire to attempt to repair third-party applications without involving the application developer, be warned that this is itself a risk proposition. Although the updated GDIPlus.dll is designed to be compatible with previous versions, there are always applications that are too tightly designed to the idiosyncrasies of a given version. The result can be a situation not anticipated by you or the application developer. So we encourage you to work in concert with your software vendor for an update that has been tested with the latest version of GDI+.

For Developers

The potential for exploitation exists in GDI+ and in applications that use data from corrupt image files to calculate memory buffer sizes. In this case, the data source is from metadata encoded in the image. Through GDI+, applications use metadata both explicitly and implicitly.

Explicit or Direct Metadata Usage

Explicit APIs provide applications with the means to read PropertyItems or individual metadata items. The risk associated with this type of data is mostly in the application itself. Applications often rely on the accuracy of data from the image; they assume that it is truthful and accurate. Neither assumption is safe to make any longer. Attackers have used this expression of developer naivety to create images that trick applications into allocating buffers that are too small for the raster data in the image. Good coding practices dictate that developers use defense in depth, as described in Writing Secure Code by Michael Howard, to protect their code and their users from malicious images. In this specific example, applications must not assume the height and width reported in metadata correspond to an equivalent amount of raster data in the file.

Implicit or Indirect Metadata Usage

Conversely, APIs such as GetThumbnailImage implicitly cause GDI+ to use image metadata. While many calculations are checked in GDI+, there are cases in which implicit use of metadata will create an exploitable situation.

From an application developer's perspective, it is difficult to avoid all direct and indirect use of metadata. Other than avoiding images from untrusted sources, applications should assume that all data coming from images is suspect. Application developers should take every measure to validate data from all image files.

How to Ensure You Use the Correct OS-Managed GDI+

In general, the best way to ensure that your application uses the correct version of GDI+ is to rely on the operating system to pick the best version.

The primary reason you want to use the OS-managed DLL is because of servicing. Windows Update can automatically update GDI+ when it is managed by the operating system. Unfortunately, the Side-by-Side system used to select the DLL is currently only available on Windows XP and Windows Server 2003. On down-level systems, the applications should rely on the system-provided GDI+.

After the correct version of GDI+ is on the system, you will have to ensure that your application uses the correct version. As long as your application does not use LoadLib or some other explicit method for calling a specific version of GDI, there is no action required to use the latest GDI+ version. Anytime you bypass SxS, you take on additional responsibility to service the component you are directly accessing. Please see Knowledge Base Article 835322: Applications that bypass globally serviced side-by-side assemblies may be vulnerable to issues that are fixed by a Microsoft software update.

Though there is every effort to maintain compatibility, some set of images will no longer load. For the most part, these images have some form of corruption that no longer pass the more stringent verification process used.

How to Ensure You Use the Correct Application-Managed GDI+

Two separate tasks are required to use the correct version of GDI+: installation and instantiation.

  1. Before you construct a setup for your application, get the latest version of GDI+ from the Windows Platform SDK download site.
  2. Ship your application with an application manifest that lists the version of the side-by-side assembly that your application was built or tested with.
  3. Always deploy the manifest file of the side-by-side assembly with the side-by-side DLLs, even if you choose to deploy to the application folder.
  4. If you install your application on a computer that is running Microsoft Windows 2000 or earlier versions of Windows, do not ship the side-by-side assembly in your application folder to those operating systems. Instead, the side-by side assemblies should be used from the system folder. If you install gdiplus.dll to the system folder as part of your setup, make sure that you are not downgrading the version if one in previously present!
  5. Do not use the .local feature, also known as DLL/COM Redirection on Windows.
  6. Do not call the LoadLibrary function on the side-by-side assembly DLLs with an explicit full path. Instead, use static linking or use the LoadLibrary function with the raw DLL file name. For example, use "Gdiplus.dll" as the file name.
  7. Don't rename the dll, or if multiple DLLs are involved, ship all of them as a unit with the manifest intact.
  8. Do not tamper with the manifest of a side-by-side assembly.
  9. Do not ship the application configuration with <publisherPolicy apply="no"/>. This is meant for administrators to use if they have a compatibility problem, and it will lock you out of valuable central updates.

Changes Required to Use the New GDI+

As of the writing of this document, no changes are required to your application to use the latest version of GDI+. However, application code must more closely check return codes for API calls. Image parsing and decoding are stricter than they previously were. Consequently, some of these files will no longer decode because they are potentially corrupt.

In Conclusion

The GDI+ team will continue to take steps to anticipate and prevent vulnerabilities, and repair our product. As the need for security and the protection of privacy grows, we will be called upon to respond to these types of issues. This means our team will make updates available to you as quickly as possible. To be best prepared, whether you are an end user, administrator, or developer, you should deploy Windows XP Service Pack 2 (SP2), or Windows Server 2003, with the Windows Update automatic update feature turned on.

Show:
© 2014 Microsoft