- Nokia “Comes with Music” group signs up Sony-BMG.
- Samsung goes for OLED in a big way.
- Microsoft new online CRM system seems risky to me.
- Weird stories emerge about AMD-ATI history.
- Warning about Adobe bugs.
- OLPC management getting threadbare.
Right click here and select ‘Save Link As…’ to download the mp3 file.
John,
I don’t know about this particular case, but many errors like this are buffer overflow errors, where the data overflows into another part of memory. Depending on where it goes, this can do all kinds of stuff. Or Adobe could have just written some crappy code that somehow allows execution of BMPs.
John,
Here’s a write up from Mary Landesman on a .bmp based trojan in 2004. http://tinyurl.com/6q33ax
Probably the same or similar mechanism but targeting Adobe viewer s/w.
Harumph!
J/P=?
Did you talk about cheese sandwiches in this podcast? I run about four shows behind and now I’m more than that behind because I was in Key West last week. But I saw John on Twitter today and he commented on my blog – http://www.bowlofcheese.com – on my cheese sandwich post.
Other than that, keep up the good work! Love Tech5.
Jeff
There are two kinds of BMP attacks, one is DOS – deny the user use of (read: crash) his application – this is petty and boring: just don’t open the overflowing file again and you’re fine. The other, however, is much more sinister. In a well crafted BMP overflow, data is read into a buffer, and when it overflows the software detects an error, this, in-turn, throws an error handling process. The application now loses control of the memory location of the malicious code, which falls into and is executed by the error handling process; with the user’s privileges.
The idea of malicious data originates in the concept of a unified memory, whereby computers store bits of code AND bits of data intermingled in RAM. Typically, malicious data causes poorly written programs to overwrite parts of RAM that are supposed to hold code or addresses to code. For example, an image may claim to contain more pixels per row than the program is designed to support, or may even claim to contain a negative number of rows. This may cause the poorly written program to behave unexpectedly, by overwriting the return address for the currently executing subroutine to point to some instructions planted in the data, or more directly, by inserting instructions into subsequently executing code addresses, for example. These examples are made up and over simplified, but I think you’ll get the idea…