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

Critical Bug?

[geomon]

Okay, so it is critical. The advisory contains the patch to correct the problem. This only becomes an issue if Windows users don't patch their machines.

What is the likelihood that users won't patch their machines? (cough!)

From TFA:

Mehta doesn't expect the latest Windows flaws to be exploited in a widespread attack. "We're not bracing for any major worm or malware outbreak, but we do expect them to be used in targeted attacks," Mehta said. "There is user interaction required, there has to be someone sitting at the other end in order to be compromised."

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

An interesting question

[ThePyro]

Microsoft's .NET platform, which is supposed to be managed code, has built-in support for rendering WMF and EMF images (the image formats that are affected by this security vulnerability). So are applications written in .NET still vulnerable to the buffer overflow exploit, or was the underlying rendering code rewritten for the managed environment?

Writing managed applications won't protect you (completely) if the underlying framework isn't also managed.

Re:An interesting question

[SilverspurG]

How about we just raise the bar on coding practices and actually secure programming? Maybe we could teach strict logic flow structures.

The biggest excuse I hear from programmers for why they've violated strict logic flow is always,"Well, I was coding for speed and efficiency". With 3.0+GHz machines, what does it matter anymore? It's all a lot of hooey, too. The person learned that excuse from someone in 8th grade and they've latched onto it. When pressed they rarely even know what logical structure they've violated. They only know the excuse.

I think the biggest problem facing us is the inundation of object oriented programming languages. There's very little need to learn the strict mathematics of programming anymore. It is this laziness, and not any particular language, which is the root cause of the problem. Programming environments with sandboxes (ie. Java) are band-aids to a bigger problem.

The problem is with lazy programmers.

Re:Another brownie point for the cause of DRM?

[plover]

I'm not sure how you extrapolated that. What makes you think the DRM code is going to be somehow "more resistant" to buffer exploits? It just shifts the focus from the "media viewer" portion to the "DRM decoder" portion of the software. But there are still buffers involved.

Besides, if you're passing "unprotected" content around you'll still have these issues. Not every JPG is going to suddenly be digitally signed and encrypted. Assuming the same "media viewer" application, you'll have the same bugs.

If anything, the DRM code just adds another layer of interpretation that's open to attack, making your system "less safe" rather than "more safe." More code == more potential for bugs.

Sorta like this quicktime one

[MushMouth]

While I hold no place in my heart for microsoft. Quicktime appears to be having a very similar problem. But also remember that the libjpeg and libz also had similar problems exploitable on Linux patched in the last year. Expecting an OS, ANY OS to save you is a bigger security threat than some exploitable jpeg code.

I like this line of Grade-A bullshit....

[HotNeedleOfInquiry]

"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."

If a programmer is taking the time and effort to interpret a complex file format, why can't he also take the time to validate it.

Re:I like this line of Grade-A bullshit....

[cnettel]

Of course you are right, but you are also ignorant if you don't realize that writing something that seems to interpret every valid file correctly is far easier than writing something that will accept every valid file and reject any invalid file, gracefully. Not to be said that it can't be done or that it shouldn't have been done. Just that it's far more difficult. Even when it's short and seems rather solid. zlib, anyone?

Re:typical case of code-based formats

[cnettel]

Oh, a file format based on instructions, just like, uh, PostScript?

If you want detailed control over layout, especially with low overhead for rendering, an instruction based approach is quite good. The point is that no GDI call, in itself, should be able to mess things up and simple parameter validation of the WMF input should be enough when spooling the calls.

(Hey, Postscript is even Turing complete. There's nothing wrong with describing a picture as instructions to a state machine with some rendering primitives.)

Besides, WMF is 15+ years old now. The availability of formats for vector graphics that matched the features of GDI (while not being expensive, money-wise or performance-wise, to render by GDI) back then was a bit different. The format has never been used much for real files, but quite a lot for clipboard transfer of vector data (Excel graphs and whatnot).