Image Handling Flaw Puts Windows At Risk

An anonymous reader writes "Microsoft has released word that several image handling flaws may open Windows PCs to Spyware or viruses. From the article: 'We will continue to see this type of vulnerabilities in every major application for the foreseeable future ... It is not just images, but any type of complex file format. This is something that security researchers and hackers have realized to be a weak point in many applications.'"

Comments

MSN Messenger felled by this months ago

[saskboy]

Both jpg and png was flawed in Windows, MSN Messenger, and even other image apps by a buffer overflow exploit where a specially crafted jpeg file with a virus "attachment" would crash the program and execute virus code. I have to agree that if they are still finding flaws, we'll be stuck with them for a while. Just imagine, every Windows 98 computer out there probably has this problem too, and there's no way it's going to be really fixed. It will never be safe to run even "safe" things like jpg and mp3 on old computers now. It's very, very disapointing news.

In a Messenger program that is always accepting new input in the form of pictures and messages, it's especially dangerous because anyone who's online will instantly become a zombie spewing out infection to their friends on their contact list. You really will get viruses through your personal contacts more than spamming-strangers in the future.

Of Course

[NanoGator]

Of course, I think the developers who left these vulnerabilities open should be financially responsible for the damage this may cause.

Re:Of Course

[Anonymous Coward]

Actually, I posed this in both this thread and in the Lupper thread. Just curious if there's a different opinion depending on whether the victim of maliciuos code was Microsoft or Linux. Unfortunately, I picked a bad specimen here since MS didn't write that lib and the other thread was looded with comments by the time I got it. Oh well.

So, no, I wasn't serious.

Re:Of Course

[Mistshadow2k4]

Here's why these things happen so much with Windows: no developer ever sees all of the code, only their own portion. They don't work together. One developer has few, if any, clues what the other developers are doing. This is Microsoft's idea of securing the code (Didn't work, did it?)

Traditionally, Microsoft Windows is built by thousands of software engineers, each producing their own segments of code that are stitched together into one program. From Microsoft Admits Trouble with Windows

Imagine it this way. Joe, Bob, Dave and Greg are coding a program. Each of them is assigned different parts of the same program. Bob's code conflicts with Greg's. Dave's code covers part of what Joe wrote, but accomplishes the same thing in a different fashion. Nobody writes a bit of code that would protect the program from a vulnerability to a certain file type.

Now multiply that by a few hundred, like a freakin' huge patchwork quilt added onto and re-sewn by generations of half-blind seamstresses. That's how Windows has been written, from 95 and on. So are the indivdual developers to blame? Some certainly could have been lazy or just mistaken (and probably have been). But since Microsft has deliberately made the code for their OS into such a total mess, how could you find out which developers to hold responsible? So you see, the problem isn't really Micorosoft's developers, it's Microsoft the company.

Now, normally, I'd agree with you. If you've got, say, 20 developers on a project working together and a vulnerability like this crops up, they are directly resposible. But in a case when they are effectively working blind at the company's behest, they don't know what their co-workers are doing or have done, so they can truthfully say they only did the part they were supposed to and wasn't that supposed to be taken care of by Department Z and not even be passing the buck, just confused.

When writing a parser, length checking is a must

[Harry Balls]

When writing a parser (for a graphical or non-graphical data file) it is advisable to sanity check the input data at every step.

Consider ASN.1 data (used, for instance, for digital certificates, certificate revocation lists, certificate requests and so on).
Each and every ASN.1 data element and each and every sub-element contains a length field. The ASN.1 parser should check whether the length field of a sub-element goes beyond the length of the enclosing data element, and so on ad infinitum.
If the parser detects a violation, parsing stops.

Re:Critical Bug?

[Anonymous Coward]

Yeah, like viewing an image from usenet. No one ever does that.

Somehow I detect sarcasm here, but it's actually quite true without it.

Another brownie point for the cause of DRM?

[xclay]

It's a tangental thought, but the debate around online security, including this one, seems to be paving a wide path for DRM, or more centrally-managed content distribution methods in commercial applications.

typical case of code-based formats

[radarsat1]

The WMF and EMF formats are just basically little programs full of GDI instructions. When you create one, you execute a bunch of GDI calls, with the WMF file as your Device Context. So essentially it's a shortcut-- an "easy" way to create a file format, based on the structure of the operating system's drawing code. I don't know about how the potential exploit works, but at first glance it seems like this is a typical case of designing a file format for "code convenience". Loading the file basically consists of loading a series of instructions and executing them. Now THAT sounds like a good idea! Easy to code for, but also easy to take advantage of. In other words, it's a lazy approach to coding. Lesson to be learned: File formats can be complicated! They must be designed to be a good *format*, not just to make coding easier. The more Microsoft designs its own file formats for each new technology it comes up with, the more we'll see this kind of thing. Better to find out what file formats are already out there, finding one that suits your needs, and supporting THAT, instead of coming up with one on your own. This is a case of re-inventing the wheel, badly.

Re:typical case of code-based formats

[elsilver]

Loading the file basically consists of loading a series of instructions and executing them. Now THAT sounds like a good idea!

I'm sorry, but how does this differ from any other vector-based graphics file format? Of course it's the instructions for how to draw the item. Of course they are executed. What else would you want them to do?

This is also how Postscript and PDF work. Actually post script is more than simple instructions, it is actually a programming language. This is part of why Apple/NeXT chose to use PDF for their native graphic format on OS X, rather than PS as they used for NeXTStep. One of their concerns was, theoretically, printing a file could execute code to do something nasty like reformatted your HD. The commands the PDF contains have more limited access to the environment.

This is also how the new MS Avalon (I think I've got the right code name) drawing engine works.

So the moral of the story is not that vector-, or instruction-based graphics formats are bad, but that only a limited set of commands is needed, along with some good sanity checks.

E.

Re:So, Windoze merely has an image problem?

[Anonymous Coward]

I just applied this patch to my Win XP x64 Edition box,
and everything still functionally works ok, but there are
tons of serious graphical glitches all over the OS now.
I tried updating my video drivers (ATI x700, 5.9 to 5.10),
that did nothing. Tried changing my color schemes, same thing.
Finally tried removing the patch, and oh! things are back to normal
now.

Hooray for Microsoft! :-\

D

Re:Managed code

[plalonde2]

But all the managed code's libraries weren't necessarily written in managed code. It's easy to see how "trusted" formats can have various pointer-arithmetic unchecked. Consider an image format that includes an offset to the start of some of its data: intercept the image, change the offset, and off you go at least feeding bad data to the application. Few loaders check that all these kinds of binary data are in range, programmers are lazy and just add the offset to their pointer :-( I guess more and more loaders will be checking more carefully now...

Re:An interesting question

[dgatwood]

No, it isn't. There are plenty of ways to fix programming languages so that they don't have a risk of buffer overflow exploits without the performance hit of some bloated vitual machine. All that is really required is for there to be a lot stricter checking when doing operations involving pointers.

Change the following:

1. No static buffers. All buffers declared in a static fashion should be replaced by run-time dynamic buffers of the same size. This way all data objects are managed by malloc. This creates a slight performance hit, but not much. This alone nearly eliminates the possibility of buffer overflows resulting in execution because arrays are never on the stack.
2. Make each malloc store the size of the region right before the pointer. Then, when the compiler generates an array dereference (the first time it does so for a given index), it should do something like "cmp index,0; bl ERROR; cmp index, @(baseptr-4); bge ERROR;" where ERROR triggers a segfault programmatically.
3. Pointer arithmetic: the in-memory storage for a pointer should be increased to twice the actual architectural size of a pointer. When arithmetic occurs, the pointer should be stored as a base followed by an offset. This way, the original base address is always available, and thus, the original size is always available.

It's easy to very nearly eliminate these problems without every memory access being managed through a virtual machine. It's easy to fix this without a heavyweight runtime environment. It's easy to fix this without any changes to the C language at all beyond the compiler level. So why don't we? If the choice is between a relatively small performance hit doing array bounds checking and a huge performance hit from everybody doing this managed code crap, the decision should be a no-brainer....

This is probably going to get modded as funny, but

[Patchw0rk F0g]

...I've been trying to get porn flash ads off MSNBC and Yahoo for weeks now, at home, when at work the sites are just fine. Spyware, right? Well, Spybot, Norton, and AdAware say... a resounding "No". Nothing there. Yet the front page of MSNBC and my Yahoo mail still have ads for some guitar software, daBoink.com, and some fucked-up screensaver rotating with nauseating frequency.

Oh, and before you ask... twice a week virus scans, two noted spyware blockers, and a reliable firewall. How reliable? Shit, /. port-scans me every time I freakin' post!

Okay, now go on and say it... all together now... "Serves... YOU... ......."

Re:An interesting question

[UncleFluffy]

The problem is with lazy programmers.

I've posted this before on Slashdot, so apologies for the dupe, but...

My first technical question in an interview is "what is wrong with this C code?"

void echo(void) { char *s; gets(s); puts(s); }

Over 50% of the "experienced C coders" I interview fail to get the answer right, and this has been a constant for about the last five years. Scary, isn't it? What's even scarier is when an employer hires them after I've flagged this in the post-interview chat.

Adblock filters

[TopSpin]

Add *.wmf and *.emf to your adblock filters (I presume if you browse with Windows you're using Firefox and Adblock, otherwise...) These formats hardly ever appear on the web. If you see one, it's probably an exploit.

Re:Avoid useless Adblock filters

[adtifyj]

Mozilla won't download these files from the internet anyway.

Bug 88691 : [RFE] ability to show Windows Metafiles (for windows only builds) referenced by <IMG> is desired

...
Why do we need to add Windows Metafiles support to the imagelib? Nobody uses it on the net. WONTFIX!

Re:To Finish Microsoft's Quote.....

[drsmithy]

Lemme finish off that ... for them. "... until we learn that integrating IE directly into the OS was the biggest fuckup we ever made."

Let me guess, you're one of these dimwits who think "integrating IE directly into the OS" means it's part of the kernel ?

Re:Time to switch to Macintosh

[R3d M3rcury]

Hear hear! Actually, my favorite was the one in ColorSync. Very scary stuff, because some programs ignore ColorSync profiles, so you might still be able to view your images. But Safari and IE do not ignore them...

As an aside, this is where the the comment about "Macs have no viruses because they have low marketshare" holds some sway with me. I agree with everyone who says Macs are more secure than Windows, don't get me wrong. Once your code is running, it's much tougher to do anything to spread a virus in the same way that viruses spread in Windows. But part of it is that nobody really does the immense amount of reverse engineering necessary to write a virus or worm based upon an a published vulnerability. While, with Windows, an entire cottage industry has been built to figure that stuff out because there's money in it.

These things, as with many things in life, do not stem from one reason. Windows has viruses because of poor security. Windows has lots of viruses because of marketshare. Macs have fewer viruses because of better security. Macs have no viruses because of marketshare.

Re:Critical Bug?

[Taladar]

Aren't you putting users at risk when telling them to patch in an Email? After all there are lots of scams with that theme (big vulnerability, patch here, patch is trojan).