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.'"
Not just any image- a MetaFile. Other than when I'm on a Windows Machine using the Clipboard, I stay away from those suckers. They can, and do, contain just about anything.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
So a lot like Firefox. Multiple GIF and JPEG arbitrary code execution vulnerabities found to date, though only one PNG arbitrary code vulernability (best vegas odds for the next FireFox image vulnerability?). OS X has to pick up the slack when it comes to some of the more obscure formats, having suffered execution vulnerabilities in oddball stuff like PICT.
Internet Security Systems != Microsoft.
This has nothing really to do with IE. IE here just happens to be a vector. If FF on windows was depending on those libraries to display those image formats they would be vulnerable as well.
OS X just seems to be bulletproof : no major hacks yet.
the current flaw affects WMF (Windows Metafile) and EMF (Enhanced Metafile) file formats only. This is not the same thing as any jpeg or png-related vulnerability
Of course, we also have recent announcements of imaging bugs and vulnerabilities in Apple's QuickTime that can allow machines to be hijacked. As such, I gather *nix systems can and do have similar problems.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
As such, I gather *nix systems can and do have similar problems.
The volume is different, to be sure. That is probably an artifact of the number of users running the OS.
But your point is well taken; no operating system is immune to attack. Unfortunately, Windows users generally lack the discipline to patch their machines regularly. I don't know many *nix system users who do not perform regular updates.
That probably accounts for the low infection rates of *nix-related system.
"Rocky Rococo, at your cervix!"
Ironic.
The usual MS obfuscation for "because we don't support 9x anymore, by definition there are no critical updates for 9x" is to state that 9x is "Not Critically Affected", with a URL to a page that defines "critically affected" in such a way as to exclude 9x.
"Not Affected", as claimed in MS05-053, is a stronger claim. That's not to say there aren't similar bugs in image-handling in 9x; only that the hole in this notice probably doesn't affect 9x.
Times like this, you wish /. would use some other format for the posting date. Maybe one with the year in, for example. Sheesh.
If only there was some place that you could configure how posting dates are displayed. Perhaps in your user preferences somewhere...
A good product for public places like schools/libraries...etc
If you actualy wanted to use such a product I guess it is possible (although probably annoying) to use it on a personal computer (idealy for kids).
When I tested this out for a client (public library) I browsed around and obtained several viruses/spyware variants, rebooted and all was fine :)
You might hit unwritable (possibly unmapped or kernel) memory before your uninitialized pointer overflows the stack. This makes the backdoor very unreliable. Also, on a 64-bit machine, you might have to transfer many terabytes of data.
Fixed code:
void echo(void) { char S; char *s= gets(s); puts(s); putchar('\n'); }
Note that the fixed code neatly avoids many stack protection mechanisms by not using a normal array. An improvement would be to use a more interesting struct to hold the data, with enough room to hide the backdoor from testers.
Uh, this was intended to be a backdoor, right? You didn't say what the code was expected to do.
Maybe it's a bit ironic that sometimes exploits like this can be considered "good" - for example, just recently a buffer overflow vulnerability in libtiff opened up the way to running homebrew code on the PSP 2.0 firmware. Of course, Sony patched up the hole in the next update.
:)
Fortunately, PSPs aren't getting remmotely compromised over the internet (yet?...) Windows boxes are a whole different story, though
The main cause is the C string operators, which traditionally use Null terminated strings. So the potential length of a string is unlimited. In Linux, functions like gets() are (have been) phased out in favour of getsn(), which has an explicit length:
int getsn(char *cp, int size);
This has been a huge effort executed using automated search methods and hand coding, to vet enormous amounts of Free code. Consequently the quality of GNU systems have improved dramatically, while the same cannot be said for MS code.
The problem is that if you overflow a buffer defined on the processor stack, then you can force a new return address into the Program Counter when a routine exits, thus giving the attacker control over the next piece of code to execute. This pice of code is typically part of the string that was used to overflow the buffer.
Oh well, what the hell...