Slashdot Mirror
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.'"
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.
"Rocky Rococo, at your cervix!"
'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.'
In a later interview:"Only one known product suite on the market can protect you from these ongoing threats. MS-AntiVirus and MS-AntiSpyware. Only these two programs are equipt with the proper image handling algorithims to detect these known flaws inherent in all programs."
This seems like a big scheme to get people on their proprietary AV and AntiSpyware programs. Lets see... Find hole, fix hole, release press release about hole, plug product, patch hole for product users.
eesh.we will see.
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.
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.
John
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.
"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.
"Eve of Destruction", it's not just for old hippies anymore...
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).
I think the GP post's point is the loader should be written in a managed language... and I agree. Eventually I think we'll see unmanged code regarded in the same way as inline assembly is today - great for the places where you need absolue balls to the wall performance, but otherwise stay away from it.
Lets face it, except for corner cases managed code is usually within a few % of the same speed as unmanaged code, and that few % isn't always on the slow side either.
Of course its possible to write crap managed code, but its a hellava lot easier to write good managed code than good unmanaged code.
XML == Big fat files.
Binary == Little compact files.
Plus add the parser, schema, etc. and you got yourself a big chunk of bloat. A simple RIFF style binary file with GOOD coding practices will be much smaller and more efficient.
Good example: At a past employer, we wrote software that would generate output data files. They used to be binary, and were roughly 25 to 30 KB in size. Then the whole XML hype set in and our customers just had to have it all in XML. Now output files are between 1 and 2 MB, plus roughly 8 MB of support files (Xalan/Xerces), and they're slower to load. We could have rolled our own, but try justifying the extra cost to the customer.
Don't get me wrong, XML has its uses. But fast, efficient data storage isn't one of them.
BTW, there is nothing wrong with using pointers. You just need to know what you're doing. Programmers who write shoddy code with pointers says more about the programmer than the concept.
~X~
~X~
Apache hosts vastly outnumber everything else combined. Postfix/Sendmail/Qmail/Exim probably have 90% of the email server market. There are many more installations of MySQL than MSSQL. And yet, how many worms have you seen roaring through the Internet unstopped that affect those applications? By any count, relatively very few.
And yet the bad guys, who even have the full source code to each of those, haven't had as much luck attacking Unix-based systems as Windows, even though Unix basically owns the Internet server market. So much for the "market share == vulnerability idea", even though the prize for owning a Unix server on a fat pipe is much greater than owning a Win95 box on a dialup.
This hypothesis gets trotted out every time the subject comes up, but it really needs to die. The overwhelming amount of evidence supports the theory that solid design is the path to good security - obscurity doesn't seem to have much to do with it.
Dewey, what part of this looks like authorities should be involved?