Microsoft Responds to WMF Vulnerability
beuges writes "In an entry on the Microsoft Security Response Center Blog, Stephen Toulouse explains exactly how the WMF flaw could be triggered. BetaNews has an overview of the company's response." From the BetaNews article: "This code exists on every version of Windows since version 3.0, security firms have said. When this functionality was introduced, Toulouse said the security landscape differed from what it is now and metafile records were completely trusted by the operating system. Gibson claimed that the flaw could be exploited only by using a byte size of 1 in the metafile record, which Toulouse says is incorrect. He surmised that Gibson's tests had the offending function as the last entry in the metafile, which caused only incorrect sizes to trigger the flaw." We've previous reported on the backdoor claim.
That's quite a long time to have a flaw in your OS. Maybe they should focus more on security rather than a fancy new AeroGlass interface.
My journal: Clicky. Read it because it
I think maybe Windows' landscape has changed but security wasn't so passe' to other software makers. I wonder how much arbitrary code could have been executed by UNIX or even Netware in those days? And I leave open the possibility that it could have. In the long run, this was left uncheck and maybe forgotten for what, 12-15 years now? And more importantly, was brought right into the server code from the desktop code.
I think therein lies the fundamental problem with Windows and why SA's warned for years about Microsoft's assbackwards approach to security. Windows is at it's heart a desktop OS and as such has a reverse understanding of security.
I think at that time, the typical protocols for those tasks on a PC were "walk to the computer you want to work on" and "floppy disk". Internet just wasn't that common outside academic institutions.
And Windows 3.x was single-user anyway (i.e. as soon as you had physical access to a computer, you didn't need to play any tricks with WMF files, you just could put your code in a
The Tao of math: The numbers you can count are not the real numbers.
My guess is they redid the printing system, and didn't fully check what other windows systems were affected.
Remaining in the PC world for the moment, let's look at SCO OpenServer. It still has compatibility with Xenix programs written in the early 1980s, before Windows 1.0 was even conceived, let alone released. Then there are mainframe systems today offering compatibility with software going back to the late 1960s.
Legacy support isn't the problem. There are many software products offering legacy support far beyond that of Windows that work just fine, with a relatively good degree of security.
The problem would be poorly written code building upon poorly written code, year after year, decade after decade. That appears to be the case with much of Microsoft's software, save the last five or six years.
Cyric Zndovzny at your service.
Gibson claimed that the flaw could be exploited only by using a byte size of 1 in the metafile record, which Toulouse says is incorrect.
Yeah, so? Most bugs of this kind is triggered by passing "broken" data.
Connection closed by foreign host.
Put another way: In NT 4 and later, GDI calls are translated to kernel service calls, in 32-bit. In 9x, it's thunking to a globally mapped 16-bit DLL...
I wonder whether the reason the wmf vulnerability was fixed in 9X and then broken in XP/2000 has to do with the way the NT stream was created. If I understand it correctly the initially diverged from Win 3.0. Perhaps the code was "fixed" in 9X but they reverted to the NT core code as the development went on into 2000/XP. I hear a lot about the compartmentalisation at MS.
I am inclined to believe in incompetence before conspiracy theories... (although incompetence does not leave me all warm and glowy)
Get over yourself.
.exe or .scr file.
And for what it's worth, I don't consider it a bug, or a failure, or anything else like that. It's a feature that was implemented in the format. You should always be careful when running formats that can contain executable code, just as you would with a
From MSDN:
A metafile contains records that describe a sequence of application programming interface (API) calls. Metafiles can be recorded (constructed) and played back (displayed).
A metafile is not a 'graphics format' exactly. It is rather a macro of API calls. Obviously one would suspect that such a thing could be used to execute malicious code.
Big ones, small ones, some as big as yer 'ead!
Give 'em a twist, a flick o' the wrist...
The Toulouse blog basically proves, as if it weren't obvious, that Gibson is full of crap.
The Toulouse blog states that Gibson is full of crap, without providing any proof. He says the flaw can be triggered with a correct record length, but does not state anything about what conditions might be the trigger. Not that I would expect him to provide those details, but that's what it would take to prove Gibson wrong. Toulouse's response amounts to "Pay no attention to the man behind the curtain" or "These are not the droids you're looking for".
I suppose the proof is in a briefcase, along with all of the UNIX code that IBM copied into Linux.
I am not your blowing wind, I am the lightning.