GDI+ exploit mutations and how it re-teaches an old lesson

In September they announced the JPEG buffer overflow in gdiplus.dll. Again, it was a case where data became code. Although there are scanners to determine if your dlls are vulnerable (see http://isc.sans.org/gdiscan.php ) the issue remains: a file that was once considered a safe data file is now potentially executable code. This happened before when email became active code thanks mainly to MS Outlook. How many Outlook vulnerabilities have we had to deal with? This has also happened with other multimedia files (e.g. winamp buffer overflows.)

There have already been a few variant proofs-of-concept released. In response, there are SNORT rules circulating to detect these exploit attempts. There are folks playing around with the code in order to evade those signatures ( http://archives.neohapsis.com/archives/fulldisclosure/2004-10/0475.html ) and I suppose there will be new signatures developed to catch the new versions.

If you read that last paragraph alone (and ignore the URL link,) it could have been written about any vulnerability. JPEG vulnerabilities are not going to end with patches to gdiplus.dll?it?s a new family of vulnerabilities.

It?s not a new discovery, but it is an important lesson. Once data has the potential to be executed as code, it has to be inspected. There?s really no reason to inspect a file differently because of its extension. Even compressed files should be inspected in raw and uncompressed form.
How to (Not) report an attack by a large company

While at the day job, interesting things come across my desk. Recently it was an email from a distraught webmaster complaining that my firm was attacking his simple web-forum. Normally, I contact the complainant, do a big of log searching, and solve the issue. This time I wasn?t able to help, we?ll see why below.

What to do if your website is under ?attack?:

Firstly not everyone knows what an attack is, and not everyone agrees upon the threshold that determines an attack from ?popularity.? I?m going to avoid that debate and simply say, it?s an attack worth reporting if you?re impacted enough to take the time to identify and report it. But how do you report it and not pull your hair out (or shoot yourself in the foot) in the process?

Gather logs. You?ll need them to prove to the ISP, webmaster, SANS handler, etc. that the event happened. If you don?t have logs, you will not get help. Instead, you will get requests for logs.

Now that you have your logs, and your case written, you need a sympathetic ear to complain to. Although WHOIS records are going to give you contacts, do not rely on them-- especially if it?s a large organization that owns them. Large organizations have lots of departments. And the guys running the DNS server (the likely technical contacts of the domain) aren?t in the security team. So when you send your report, feel free to include all of the WHOIS contacts, technical, and administrative, for the domain and the IP net-block. Also be sure to use the abuse@ address which is required by RFC 2142. A visit to the organization?s web page may offer other contacts as well. The key is to try all of those contacts at the same time. You don?t want to add delay and added frustration by sending email to the WHOIS contact and have it ignored.

Most importantly, in wording your report/request for help, the absolutely last thing you want to do is threaten retaliation or legal action. You are understandably upset when you have to sift through gigs of weblogs and research an incident from a firm that you expect to ?be secure? or ?play nicely,? but threatening the organization is not going to solve your problem any faster. In fact, it?s going to delay things.

This is why I couldn?t help the webmaster who needed it. Once he mentioned lawsuit, I had to cease all communications with him, and direct everything through the legal department. That adds months to the resolution process. Which can take years off of your life and hairline.

To recap, when dealing with any organization, large or small, you?ll want the logs handy for when they request them, you?ll want to shotgun your message across as many of the public contacts as you can find (in moderation?don?t email their employee list, :-P) and be nice to your first contact.

Kevin Liston
kliston at greenman-consulting dot com