Last update: 2004-09-28. The latest version of this
article can be found at
GERMAN: Die deutsche Version dieses Artikels steht unter http://www.installsite.de/go/gdiplus.htm
You've probably already heard about the critical security vulnerability that Microsoft has discovered in their GDI+ library. (If you haven't, you should immediately read the JPEG Processing (GDI+) Security Update bulletin.) The first exploits surfaced only a few days after the bulletin had been released.
While most articles about this topic describe which actions you should take as a user of Microsoft products, this article will focus on the implications this vulnerability has for software developers, particularly in setup programs.
Note: You may be redistributing GDIPLUS.DLL without being aware of it. Many development tools have an option to automatically include required runtime files in your setup. In case of Windows Installer (MSI) tools this is usually accomplished by adding the gdiplus.msm merge module to your setup. Therefore it may not be immediately obvious to you that GDIPLUS.DLL is included in your setup.
In order to exploit the vulnerability, a specially crafted JPEG image would have to be displayed by the GDI+ library. This could be an image on a web site or in an e-mail, or from any other source. If your application displays images from untrusted sources, which includes user supplied photographs or a user selectable logo for instance, your software poses a critical risk for your customer's computer. Any processing of JPEG using GDI+ in your application could expose the vulnerability. On the other hand if you use GDI+ only to display hard coded images that are built into your application and cannot be replaced by the user, the risk is comparatively low.
In this section I'll introduce several scenarios. Once you have identified the scenario that applies to you, a description of the actions I'd recommend to you can be found in the next section.
First of all you need to update the redistributables on your development and build machines. If your application uses GDI+ in a vulnarable way, e.g. you display JPEG files from untrusted sources, you need to create an update for your application and send it to your customers as soon as possible. If your application uses GDI+ in a less vulnerable way, you should include the new GDIPLUS.DLL in your next regular update.
The .NET Framework redistributable versions 1.0 SP2 and 1.1 without SP are both affected by this vulnerability. You should update the .NET Framework redistributables on your development and build machines to version 1.0 SP3 and/or 1.1 SP1. If your application is using GDI+ in a vulnerable way, you should also send the appropriate .NET Framework service pack to your existing customers, or advise them to install the service packs using Windows Update. Although Windows Update automatically offers the .NET Service Packs as "high priority" updates there are users who have disabled Windows Update, or companies that are blocking automatic updates until they are approved by their IT administrators. Therefore you may want to notify your customers that they are at risk and encourage them to install the update.
Windows XP and Windows 2003 Server include gdiplus.dll out of the box. If you only target these platforms and therefore don't need to redistribute the DLL, Windows Update should take care of the issue. However there are users who have disabled Windows Update, or companies that are blocking automatic updates until they are approved by their IT administrators. If your application uses GDI+ in a vulnarable way, e.g. you display JPEG files from untrusted sources, you may want to notify your customers that they are at risk and encourage them to install the update.
You're in luck - this time. You should update the redistributable files on your development machine anyway. And you should prepare a method to inform your customers should the need arise in a similar situation in the future.
Whatever action you take: act quickly. Only three days after the vulnerability has been published the first images are available on the web that crash Internet Explorer by causing a buffer overrun. They don't seem to include malicous code yet, but that won't take long I suppose.
If you are using Visual Studio .NET 2002 or 2003 you should download and install the appropriate patch from Microsoft Security Bulletin MS04-028. This will update the gdiplus.msm merge module for use in Visual Studio's Deployment projects.
If you are redistributing the GDIPLUS.DLL by itself you can download the GDI+ Platform SDK Redistributable from Microsoft Security Bulletin MS04-028. This package only includes the GDIPLUS.DLL, but not an updated merge module.
If you are using an earlier version of Visual Studio, or don't have Visual Studio at all, there is currently no way to obtain the updated gdiplus.msm merge module from Microsoft. However InstallShield X includes Microsoft merge modules such as gdiplus.msm, and InstallShield has made the fixed gdiplus.msm file available for download from their merge module gallery.
The GDI+ vulnerability is fixed in the recently released service packs for the .NET Framework. These service packs are:
The redistributable install packages for .NET Framework 1.0 and 1.1 do not have the service pack built in. This means that you need to install the respective service pack in addition to the .NET Framework base package.
InstallShield X has built in functionality to install the .NET Framework if needed and plans to add support for the latest service packs. Alternatively you can find sample code to detect .NET Framework 1.0 and 1.1 and service packs in Aaron Stebner's WebLog. (Aaron works at Microsoft, creating the setup for Visual Studio). The service packs and all other .NET Framework redistributables can be downloaded from the Microsoft .NET Developer Center.
Rebuilding your application and setup with the fixed version of GDIPLUS.DLL is only the first step. You also need to send that updated version to your customers. One option is auto-updating applications, e.g. using the Updater Application Block. But this doesn't work well for applications that have been installed using a Windows Installer (MSI) setup. In this case you should create a small or minor update, either as a Windows Installer Patch (.msp file) or as a full MSI Package (.msi file).
If your application is vulnerable to the GDI+ security issue your should inform your customers proactively to make sure they install your application updates or the .NET Framework service pack in a timely fashion. One way would be to send e-mail to your customers. The problem with this approach is that you may not have the e-mail addresses of the persons who actually use your software, or your e-mail address database is out of date, or your e-mail could end up in the spam bin.
In my opinion a better solution are update notification services which can notify your users that an update for your application is available or advise them to install the .NET Framework service packs. InstallShield X includes such a service at no additional cost. InstallShield Update Service polls a web site for updates on a regular basis. If you are using InstallShield X you may already ship the update notification client without being aware of it, as this option is turned on by default. In this case all you need to do is go to the configuration web site and publish a notification.
Even if you are not affected by the GDI+ problem I would recommend including an update notification client with your setup to be prepared for similar emergencies in the future. To emphasize this here's a quote from industry expert and book author Mike Gunderloy in ADTmag:
"I expect quite a few application vendors are going to be spending time in the near future devising ways to notify their customers that it's time to install a security patch, even though Windows Update won't necessarily inform them that this is the case. If you're one of them, you have my sympathies."
You can avoid such headaches by preparing for situations like this. With InstallShield X you can add the Update Service client to your setup with a single click, and there are no extra costs to be prepared for emergencies.
Stefan Krueger is working as freelance setup consultant and is running the InstallSite.org web site, a place where setup developers share resources and information among peers. Stefan has been recognized by Microsoft as an MVP (Most Valuable Professional) for Windows Installer.
Disclaimer: This article represents my current understanding of the matter. I will try to update it if new information emerges, but I cannot guarantee for its accurateness or completeness.
|News||Discussions||Windows Installer||Related Tools||More Help||InstallScript||About InstallSite||Shop||Site Search|
|Neuigkeiten||Diskussionsgruppen||Windows Installer||MSI FAQ||Artikel||Shop||Suche|
Copyright © by InstallSite Stefan
Krueger. All rights reserved. Legal
By using this site you agree to the license agreement. Webmaster contact