Microsoft Responds to WMF Vulnerability 221
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.
Every version since 3.0? (Score:5, Insightful)
Re:Every version since 3.0? (Score:5, Interesting)
The WMF vulnerability isn't a programming flaw, it's a problem with the original spec. The code may have been rewritten many times, and the potential for damage never noticed. Indeed, the WINE people did reimplement it, complete with the vulnerability.
While it seems obvious that allowing arbitrary code to execute, it is clearly sufficiently non-obvious that a flaw in a well-documented spec went unnoticed for more than 10 years.
What's most likely is that security wasn't a big thing when the spec was written (this much we know), and the WMF code was never audited because is "obviously" isn't related to security. After all, nobody uses it any more, WMF isn't used much on the web, and it's "just" an image format.
I would be worried about how many similar flaws may exist. I'm willing to forgive them for missing this one (and I'm not a Windows user), but if it doesn't lead to a proper audit of legacy APIs, the next time around they deserve everything they get.
Re:Every version since 3.0? (Score:5, Funny)
Yep - the WINE people are reimplementing the windows API bug-for-bug
Re:Every version since 3.0? (Score:2, Funny)
Otherwise sotware would not crash as expected.
Re:Every version since 3.0? (Score:3, Interesting)
Otherwise sotware would not crash as expected.
Actually, that's been incredibly useful for me: I don't have any Windows machines, but I (admittedly haphazardly) maintain a Win32 port of some software.
This has helped me find bugs in Microsoft's own implementation of Win32- or if you'd prefer, bugs in the MSDN documentation.
The WINE people have spent a considerable amount of time inspecting Win32 function calls- more time I'm sure than Mi
Re:Every version since 3.0? (Score:2)
Windows was designed as a stand alone OS without network connections so it is full of problems like this. They are fundamental to the architecture.
OTOH, the *nix OSs were designed from the start for a network environment with appropriate security.
Windows will never be ready for the net without a complete re-write.
Re:Every version since 3.0? (Score:2)
Re:Every version since 3.0? (Score:2)
The design specification has to have been reviewed and revised many times as Windows advanced through Win3.0, Win95, Win98, etc, to Vista. While I can see that a subtle undocumented bug buried in legacy code could have survived through these changes, I find it really hard to understand how something dangerous in the highly visible design specification documents could have survived these multiple periods of intense scrutiny. The only possibilities I can think of is that either Microsoft deliberately avoided
Re:Every version since 3.0? (Score:2)
I am not a Microsoft minion, but if I were, I'd propably be more worried with the endless task of trying to stop IE and Outlook from executing everything they happen to come accross in the Internet, rather than the possibility that t
Re:Every version since 3.0? (Score:5, Informative)
I believe it was a part that WINE reimplemented, and it's certainly documented. I don't follow WINE that closely, though, so I can't say for sure.
The WMF spec allows a file to define a callback function that is executed in case of an error (it resembles ON ERROR GOTO more than modern exception handling). This was presumably useful for some reason, although I'm not aware it was ever used. The exploit defines a malicious callback function, then deliberately creates an error condition.
Any correct implementation of the spec should have the same vulnerability, whether it's done by Microsoft, WINE, or anyone else.
Re:Every version since 3.0? (Score:5, Insightful)
I understand the importance of being able to run old programs, but surely Vista could have included a virtual machine or something for XP compatibility - is it really that hard to create a new OS from scratch with proper security etc. as a starting point, not an add-on? Yes it would be a mammoth task, but MS is pretty big, you know.
I don't know - when you have vulnerable code from Windows 3.1 in your latest release, don't you want to just cut the cord and start again?
Re:Every version since 3.0? (Score:2)
That's what you worry about at night? I tend to worry about whether or not I've held her long enough that I can get out of bed and leave.
Re:Every version since 3.0? (Score:5, Insightful)
Did Windows NT 3.1 count, or is it disqualified for inheriting code from VMS and OS/2?
Linux can trace its kernel lineage back to 1991, and many of its utilities are much much older than that. Are we ever going to receive a brand new OS from Torvalds?
What's the incentive for anyone to re-invent an operating system from scratch? A desire to create the next BeOS? There's too much collected knowledge in the decades' worth of "legacy" OS code that would be foolish to throw out.
Re:Every version since 3.0? (Score:2, Troll)
I suspect that its because Windows is such a mass of spaghetti code that they simply just don't know how to anymore.
Bob
Re:Every version since 3.0? (Score:5, Insightful)
Re:Every version since 3.0? (Score:2, Informative)
Re:Every version since 3.0? (Score:2)
I never thought 10.1 was extremely bad . . .
Slow compared to 10.2 onward, but not bad.
Re:Every version since 3.0? (Score:3, Informative)
At some point Microsoft will release a completely new OS. It will probably look something very much like Singularity [microsoft.com]. Reliability and security, rather than speed or features, will be the focus.
Re:Every version since 3.0? (Score:2)
Re:Every version since 3.0? (Score:2)
Re:Every version since 3.0? (Score:2)
Re:Every version since 3.0? (Score:2)
You can rest easy with your Windows 3.0 as it is is secure against the
Re:Every version since 3.0? (Score:2)
Re:Every version since 3.0? (Score:2, Insightful)
What was the end result of their efforts? An extremely secure operating system. Now, Microsoft probably wouldn't need to take it to that extreme. But even putting out a quarter of the effort of the OpenBSD team could lead to security iss
Re:Every version since 3.0? (Score:2, Troll)
On the other hand, if this bug features in WINE, why wasnt it flagged as a potential issue when the developer implemented the feature? Surely it should have been as blatant as anything at that point, and shouldnt have ever made it to this point.
Re:Every version since 3.0? (Score:2)
Re:Every version since 3.0? (Score:4, Informative)
"ahead of schedule" meaning "after a number of exploits have been released but before our original delayed release date"?
Re:Every version since 3.0? (Score:5, Funny)
Indeed. Here's the original schedule, as found in the source to Windows 3.0:
Re:Every version since 3.0? (Score:2)
The WMF flaw was patched ahead of schedule and it works fine.
It is true that you can say that the patch was released ahead of schedule. It is also true that the schedule for developing and releasing the official patch was putting the global community of Windows users at unnecessary risk. Which was why 3rd party security concerns who strongly prefer to remain neutral felt they had to come forth in this instance and recommend unofficial patches. Basically watching MS' corporate behavior wrt to the .wmf exp
Re:Every version since 3.0? (Score:2)
Do you remember the "Microsoft releases faulty patch" headlines from not long ago? No? MS remembers them.
This is what happens when you release without testing well enough.
This is not a hack like a "neutral 3rd party" can afford. It's an official patch MS is held accountable for and which becomes an integral part of the system when applied.
But of course, with MS it's damned if you do, damned i
Re:Every version since 3.0? (Score:2)
This is not a hack like a "neutral 3rd party" can afford. It's an official patch MS is held accountable for and which becomes an integral part of the system when applied.
True enough, though I fail to see how it applies to the schedule of the release, which was the original point. Microsoft could have announced the work-around during the days between the publication of the vulnerability and the announcement of the first unofficial patch-- the work-around was pretty obvious. Yet MS did not do so-- perhaps
Re:Every version since 3.0? (Score:2)
If you open a malicious WMF while browsing in Vista (with IE7) the malicious code will run, but not have the privilege to read and/or change files, settings and so on. So in a way you'd be protected since the code will run but it can't harm you.
Now
Ah those were the days. (Score:5, Funny)
when there were no disgruntled employees and no spies (international or industrial)
everyone used telnet and ftp
and there was no user 0
Re:Ah those were the days. (Score:4, Insightful)
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
Re:Ah those were the days. (Score:2)
Novell Netware
Re:Ah those were the days. (Score:2)
ya, nobody did networking or worried about network security in THO
Why does Windows have so much legacy? (Score:5, Interesting)
Re:Why does Windows have so much legacy? (Score:5, Funny)
Re:Why does Windows have so much legacy? (Score:2)
No. Apple ditched their code in favor of something that predates Windows.
Re:Why does Windows have so much legacy? (Score:2)
Those two statements don't contradict each other. Just because something was produced later doesn't mean it's more modern. A newly made horse carriage is less modern than a 50 years old car.
Re:Why does Windows have so much legacy? (Score:2)
Re:Why does Windows have so much legacy? (Score:2)
Re:Why does Windows have so much legacy? (Score:5, Informative)
There are a large number of 16 bit (ie Win3.0/3.1) apps out there that are still in industrial use. They tend to be obscure things - applications for subtitling TV transmissions, interfacing to medical kit etc. Although it may be hard for you to believe there are no apps out there more than 10 years old in fact there are, and often the computers these apps run on are upgraded to new versions of Windows as time goes by (because it'd be a huge pain to have like 8 versions of Windows in use in a single organisation).
Fixing this flaw does in fact break backwards compatibility, and that means somewhere some random app we've never heard is is broken right about now - of this I am almost certain. That has a cost, and nobody wants to break peoples apps and cause network admins headaches without good reason.
Apple realized that it's legacy code was no good years ago and succesfully ditched it in favor of something more modern, why can't windows do the same?
Apple did no such thing - they maintained a compatibility mode in the OS and more importantly kept the Carbon APIs around mostly complete so legacy code could be ported over very easily. And of course, Apple had hardly any mission-critical apps running on their platform anyway so the pain and cost was much less than it would be for Microsoft.
In fact, Windows does run Windows 3.1 apps in a VM type process these days, it's called a WoW (Windows on Windows) VM, but the integration is so tight most users never even realise it. Except for looking a bit dated the apps continue to run correctly and appear on the same desktop etc. In other words, Microsoft already did what you asked for!
Now it didn't mitigate this vulnerability, because the Microsoft developers who wrote the Windows Image/Fax viewer wanted to support every file format they could, and when supporting WMF was so easy why not do it? They unfortunately didn't get the memo about this being a potential attack vector: this is a failure of corporate communications, and perhaps over-zealous developers, not a failure of operating system design.
As an interesting historical aside, Raymond Chen has said that back in the early days of the Windows 95 project there were in fact two competing approaches to 3.1 compatibility: a VMware type approach where the 16 bit environment ran inside a window box that was in turn running a copy of Windows 3.1 .... and the approach they actually ended up using which was based on API thunks. The thunk approach was more complex but had much better integration, much lower resource usage (not running two operating systems on top of each other) and in usability tests came out on top every time. Everybody who tried the tight integration approach preferred it, and MS management felt they couldn't ask users to put up with a very jarring experience - potentially forever, in the case of apps that'd never be ported to Win32.
Re:Why does Windows have so much legacy? (Score:2)
A worldwide botnet that cripples the Internet is the potential price to pay for (ass-) backwards compatibility? No fucking thanks. Hint: if you want real backwards compatibility, release the source. Then it's a small matter of changing a few lines when your critical functionality becomes a virus infection vector.
Re:Why does Windows have so much legacy? (Score:2)
Microsoft said that the flaw DATES from Windows 3.0, and is present in all versions since then.
NOT JUST WINDOWS 3.0! (Sheesh!!!)
Re:Why does Windows have so much legacy? (Score:2)
Please read comments before you respond to them. For instance, the following things were mentioned in the article that are newer than Windows 3.0:
Re:Why does Windows have so much legacy? (Score:2)
i'd imagine a great many of those are unlikely to run on the NT lineage (reliance on direct hardware access etc) and they probablly run on dedicated pcs anyway.
still its a good indication on why you should require source for anything you rely on that isn't well supported off the shelf software.
[OT] So that's what WOW stands for (Score:3, Funny)
So that's what the "wow" in wowexec means . . . and here I always thought it was some overworked coder saying "wow, we actually managed to get this ancient crapola working". You learn something new every day!
Re:Why does Windows have so much legacy? (Score:3, Informative)
Re:Why does Windows have so much legacy? (Score:2)
Apple?! With all due respect to Apple fans, their market share is insignificant next to Windows. There are tons of manufacturing and industrial shops using software running on Windows 3.1, DOS, OS/2, OS/9000 and other "legacy" operating systems.
Apple's segment of
Security a top priority since 2002 (Score:4, Informative)
Inverse security evolution (Score:5, Interesting)
With WMF we want to be very clear: the Windows 9x platform is not vulnerable to any "Critical" attack vector. The reason Windows 9x is not vulnerable to a "Critical" attack vector is because an additional step exists in the Win9x platform: When not printing to a printer, applications will simply never process the SetAbortProc record.
Which makes me wonder, why on earth did they remove that security measure in later versions of Windows?
Re:Inverse security evolution (Score:4, Insightful)
Re:Inverse security evolution (Score:4, Insightful)
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...
Re:Inverse security evolution (Score:3, Informative)
Re:Inverse security evolution (Score:2)
-Rick
Re:Inverse security evolution (Score:2)
LoB
Odd thing to introduce... (Score:5, Interesting)
Interesting - according to the article, Win95/98/ME don't actually run the hook set via SetAbortProc when rendering a metafile (unless you're printing it and the print job is aborted), but some change was introduced in 2000/XP such that it was called after the next metafile record is processed (which is an *extremely* odd thing for Windows to do, considering what SetAbortProc was designed to do). This seems to fit with what people are reporting (and explains why the Metasploit exploit, which adds leading and trailing records, works).
Maybe Gibson was accidentally on the mark about it being an intentional backdoor. After all, that's about the same time a vulnerable program able to display metafiles was introduced and bundled with Windows (was that in 2000 or XP?).
Re:Odd thing to introduce... (Score:2, Informative)
What "saved" windows 9x is that it was a completely different code-base from NT (derived from Win3.x); it was likely altered independently by the 9x product team. But because of the separate code-bases there was no cross-pollination of this change to the NT line. Presumably the recent patch implements an equivalent fix (so that SetAbortProc is only handled whe
Re:Odd thing to introduce... (Score:2)
The Toulouse blog basically proves, as if it weren't obvious, that Gibson is full of crap.
Re:Odd thing to introduce... (Score:3, Insightful)
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
Re:Odd thing to introduce... (Score:4, Informative)
Re:NEW study finds win 9x more secure (Score:3, Interesting)
The funny thing is, the statement is not as ridiculous as it sounds. They are of course not more secure, but they are actually less likely to get compromised by an attack. Since most of the current malware and virus uses newer functionality which do not exist or function slightly different on the older systems. Resulting in the malware simply not working on those old systems. I guess the mallware writers are not too concerned about b
Re:NEW study finds win 9x more secure (Score:2, Interesting)
I'd even go so far as to say that when used as
Source code leak? (Score:3, Interesting)
Re:Source code leak? (Score:2)
Why make it a vulnerability? (Score:2, Interesting)
What I found interesting was this quote:
The reason Windows 9x is not vulnerable to a "Critical" attack vector is because an additional step exists in the Win9x platform: When not printing to a printer, applications will simply never process the SetAbortProc record. Although the vulnerable code does exist in the Win9x platform, all "Critical" attack vectors are blocked by this additional step.
Well, that explains (sort of) why they didn't feel obligated to update the 9x series, but it lacks a great d
"Landscape has changed" (Score:5, Insightful)
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.
Re:"Landscape has changed" (Score:2)
Sure, MS *could* make Windows into a real server OS, but it would require some pretty substantial changes that would alienate their entire click-and-drool sysadmin community. (Not saying all Windows sysadmins are the click-and-drool type, but probably a very large percentage probably are.)
Re:"Landscape has changed" (Score:2, Interesting)
If you want to compare like with like, you must check Windows against MacOS. Both MacOS Classic and OS X have a very poor track record of security: there have been multiple instant code execution exploits for OS X that can be triggered via a web browser in brand new code, not stuff that was written decades ago. Worse,
Re:"Landscape has changed" (Score:2)
I'm always hearing from random people who say "Oh, it's quite easy to write OS X spyware." Yet we never, ever see it.
Re:"Landscape has changed" (Score:5, Informative)
> or even Netware in those days?
Plenty. At one point, it was possible to hack a Sun box running sendmail using nothing more than telnet.
Yeah, baby, a root shell prompt without even logging. Now THAT was scary.
Re:"Landscape has changed" (Score:3, Interesting)
Ah yes, the DEBUG mode in sendmail. I remember it well, since I spent an entire day patching sendmail from various vendors during the Robert Morris, Jr. Internet worm.
I know there have been lots of other unpleasant security issues with sendmail over the years. However, that particular one could have been completely avoided if the people releasing binary copies of sendmail had read the Makefile.
Also, another point needs to be made. Sendmail is not a part of the UNIX OS. It is an additional program
Re:"Landscape has changed" (Score:2)
The real point was that this was still the era of non-preemptive (cooperative) multitasking among Windows applications. The point of having a callback was that it was the only way to cancel a print job was through a callback. So there was a reason for having this design, even if it was long-term-stupid.
Re:"Landscape has changed" (Score:2)
Heh, you don't remember sendmail or BIND do you?
Of course, the Sendmail and ISC groups appear to have the mind-think of Microsoft, so maybe this isn't really a jab at UNIX, but simply at people who used these pieces of junk...
I think maybe Windows' landscape has changed
Yup. They're almost up to 1997.
Cold War junk code? (Score:2, Funny)
Thinking back to http://it.slashdot.org/article.pl?sid=04/03/02/071 9247 [slashdot.org]
Was M$ helpeing to add a little extra into the USSR as US software flooded east?
The fun of a free door into any network thanks to M$ moving around the world?
In America bad code is no problem, it is just for end users.
In Soviet Union, expensive stolen code kills YOU.
Was M$ just a CIA front company gone too far?
Incorrect sizes? (Score:2)
Then how come only size 1 worked, not other incorrect sizes?
Re:Incorrect sizes? (Score:2)
Presumably if a record exists that has invalid data, some sort of failure will happen. Whether that is the first record, last record, or some arbitrary record in the middle of the wmf file. What Steve has reported is that if he sets an invalid record size of 1 on that record, it causes the system to treat the data
Why XP/2000 and not 9X? (Score:3, Insightful)
I am inclined to believe in incompetence before conspiracy theories... (although incompetence does not leave me all warm and glowy)
What WINE does (Score:5, Informative)
First the file dlls/gdi/metafile.c contains a function called PlayMetaFileRecord with the following signature:
BOOL WINAPI PlayMetaFileRecord( HDC hdc, HANDLETABLE *ht, METARECORD *mr, UINT handles )
Which is simply WINE's implementation of the same Win32 API (which is documented here: http://msdn.microsoft.com/library/default.asp?url=
The third parameter (mr) is a METARECORD pointer (a METARECORD is just an entry in the metafile and is detailed here: http://msdn.microsoft.com/library/default.asp?url=
typedef struct tagMETARECORD { DWORD rdSize; WORD rdFunction; WORD rdParm[1]; } METARECORD, *PMETARECORD;
With the rdSize being the size of the record in words, the rdFunction being the function and the rdParm the data (which in the case of an exploit would be executable code). PlayMetaFileRecord handles META_ESCAPE like this:
case META_ESCAPE:
Escape( hdc, mr->rdParm[0], mr->rdParm[1], (LPCSTR)&mr->rdParm[2], NULL);
break;
You'll note that parameter 3 is a pointer into the metafile parameter block, i.e. if executed parameter 3 would execute code in the metafile. Now Escape has implemented like this (dlls/gdi/driver.c):
INT WINAPI Escape( HDC hdc, INT escape, INT in_count, LPCSTR in_data, LPVOID out_data )
and the SETABORTPROC is handled with the following code:
case SETABORTPROC:
return SetAbortProc( hdc, (ABORTPROC)in_data );
So if you have an ESCAPE/SETABORTPROC record in a metafile then under WINE the AbortProc is set to point into the metafile (since in_data is corresponds to &mr->rdParm[2]).
So it's quite clear from the WINE implementation that this is a way to set a pointer into the metafile for execution. All it would take is that the metafile's AbortProc is called and arbitrary code could be executed.
In WINE at least this looks nothing like an intentional backdoor. It looks more like a bug caused by the fact that Escape is rather powerful and can set a pointer to code.
Now it's possible in WINE (I believe) to force the AbortProc to execute with another ESCAPE record that has NEWFRAME as the function. Again looking at the Escape code you'll see that NEWFRAME has handled like this:
case NEWFRAME:
return EndPage( hdc );
EndPage is a standard GDI function (see here for documentation: http://msdn.microsoft.com/library/default.asp?url=
INT WINAPI EndPage(HDC hdc)
{
ABORTPROC abort_proc;
INT ret = 0;
DC *dc = DC_GetDCPtr( hdc );
if(!dc) return SP_ERROR;
if (dc->funcs->pEndPage) ret = dc->funcs->pEndPage( dc->physDev );
abort_proc = dc->pAbortProc;
GDI_ReleaseObj( hdc );
if (abort_proc && !abort_proc( hdc, 0 ))
{
EndDoc( hdc );
ret = 0;
}
return ret;
}
Note that this function always called the Abo
FTFA (Score:2, Informative)
Thanks.
Re:Of course MS will say that... (Score:2)
Gibson was conspiracy theorizing that it was some kind of insidious backdoor that Microsoft put in there.
Re:Of course MS will say that... (Score:2)
It's irrelevant. Gibson's claim was based on faulty analysis in the first place.
Re:Of course MS will say that... (Score:2)
I thought your question was too asinine in itself, so I wondered if you simply misunderstood me. I re-read my original post and supposed there could've been room for misunderstanding, so I brought Gibson's conspiracy theory into it.
But if you're still sticking to your original question, here's how I replied to a similar question:
Re:FTFA (Score:2)
but its not a backdoor because MS say so.
The cat's out of the bag now. There's very little to be gained by lying about it, but so much to be lost if there's evidence of malicious intent and Microsoft covers it up. If there is malicious intent, Microsoft's obligated to investigate, take disciplinary action, and say so. Managers/employees responsible get fired.
Or maybe you think Bill Gates walked into some developer's office one day 12 years ago and said "put this subtle vulnerability into the WMF han
Stop, and think for a moment (Score:4, Informative)
Did anybody even RTFA? I've seen a lot of people already writing that Microsoft should have re-implemented the Legacy code, yadayadayada, write a new OS from scratch, introduce a new virtual machine just for OS compatibility. However, you all missed something very important. WMF is a well-defined standard (not saying a good one, but a well-defined one!) which means that Microsoft (or Wine for that matter) HAS TO IMPLEMENT IT WITH CERTAIN CONSIDERATIONS. One of them, is the SetAbortProc [microsoft.com] procedure that's been causing so much trouble. If Microsoft would failed to implement one part of this standard we would be getting comments like "M$ is 3vil, they don't respect standards...". I bet they're sorry that the security flaw got missed. I think it shows on their stock [google.com] also! But non the less, it's fixed now.
Come to think of it, I think that, in a world where there were no exploits (PC-wise) the whole callback function scenario was pretty cool. You'd just say that if something fails, notify the user with this procedure in my code, and since you already no it failed (no return false statement
One more sidenote, Microsoft HAS REIMPLEMENTED the code. This is proven by the following statement in the article:
With WMF we want to be very clear: the Windows 9x platform is not vulnerable to any "Critical" attack vector. The reason Windows 9x is not vulnerable to a "Critical" attack vector is because an additional step exists in the Win9x platform: When not printing to a printer, applications will simply never process the SetAbortProc record. Although the vulnerable code does exist in the Win9x platform, all "Critical" attack vectors are blocked by this additional step.
I have no idea why they've let this slip though in the XP.
You might do the same... (Score:4, Interesting)
It was a bad idea then.
It's a bad idea now.
What else is in their specs that's a bad idea?
Something like this WMF exploit, or perhaps less problematic but still annoying,
like GetTempFileName- where in 16 bits, you used a zero for the main drive and
a 1, 2, or so forth for the drive you wanted it to and in 32 bits, it's a string
with a canonical path to the place you want the temp file to be generated. Oh,
and by the way, zero's what most people used for their 16-bit code and a null
(zero on machines of the day...) produced undetermined results from the 32-bit
version of the API. Sometimes it'd work, sometimes it wouldn't. To be sure,
that sort of problem code wouldn't have gotten out the door. But if they've done
that sort of thing with their API's, I wouldn't trust that something never went
out with issues due to lurkers in the API's and specs that will come back to
bite someone on the ass down the line.
What else is lurking in MS' products that we don't know about? If they didn't design
it with security in mind then, what possesses you to think that they can go back
after the fact and bolt it on afterwards without causing it's own set of problems?
That'd be like using a hollow core door on the entry or exit of a house, and
not having a lock or deadbolt on the door- and then putting just a deadbolt on the
selfsame door when your house gets entered and people take things from you.
MS just simply needs to work at some solution to the issue of backwards compatibility
for their current OS products and start fresh with security in mind when they
do things. Anything else is like the door analogy I just gave.
Re:You might do the same... (Score:2)
It was a bad idea then.
It's a bad idea now.
Except, under the hood, WMF is used to batch together GDI calls, which means it needs this functionality. So how do you fix it?
'ported' isn't really the word (Score:5, Informative)
The reality is the windows codebase has a ton of legacy in it. One positive step taken for Vista is that *all* code, including legacy (actually, most importantly, legacy), was SAL annotated so that static analysis of the full codebase could be performed for a large variety of coding mistakes that lead to vulnerabilities. Related to that, all memory/string functions that don't take bounds have been removed from the codebase, which allows SAL to statically analyze for buffer overruns. There's been a few times when thanks to updates to the SAL agent I've had bugs assigned to my code that catch obscure issues. You can read more about the technique at: http://research.microsoft.com/slam/ [microsoft.com] At the same time, WIM is doing a second security sweep of all windows components. This is in no way complete, given that things like this WMF vulnerability still got through, but still it is a start, and is a process that is evolving every day.
I'd like to point out that in Vista WMF is mitigated by the fact that unless you are logged in as the straight Administrator account, the arbitrary code executed from the WMF exploit will only have limited user access to the system (no access to write to the windows directory, program files directory, and system registry for example) even if the account is part of the Administrators group. Honestly this is probably the #1 reason to move to Vista -- it finally has a coherent LUA story and by default I can run all my apps with low priviledges.
Re:'ported' isn't really the word (Score:2)
Ture that MS didn't patch all Windows versions? (Score:2)
If so, where is the non-MS patch now?
Is this a sneaky way to force upgrades on older OS's?
Re:Ture that MS didn't patch all Windows versions? (Score:2)
It is true that there is no patch for Win 9x/Me. It is also true that they weren't affected in the first place.
The only OSes to which this could apply would be NT 3.1, 3.5, 3.51 and 4.0. MS has been far from sneaky in saying that nobody who cares at all about security should even consider running these anymore.
I haven't re-installed any of these dinosaurs to check, but my immedi
Re:Ture that MS didn't patch all Windows versions? (Score:2)
That doesn't jib with what I've heard that this affects every Windows OS back to 3.0.
So where does Microsoft refute Gibson?? (Score:4, Informative)
Gibson: [grc.com] Except that, when I was pursuing this and finally got it to work, what Windows did when it encountered this Escape function, followed by the SETABORTPROC metafile record, was it jumped immediately to the next byte of code and began to execute it. That is, it was no longer interpreting my metafile records record by record, which is the way metafiles are supposed to be processed.
Microsoft: [technet.com] If you are seeing that you can only trigger it with an incorrect value, it's probably because your SetAbortProc record is the last record in the metafile.
Gibson: It turns out that the only way to get Windows to misbehave in this bizarre fashion is to set the length to one, which is an impossible value. I tried setting it to zero. It didn't trigger the exploit. I tried setting it to two, no effect. Three, no effect. Nothing, not even the correct length. Only one.
Microsoft: The vulnerability can be triggered with correct or incorrect size values.
Even though the Microsoft guy claims he is going to "get rather technical here" he never specifies what he considers an 'incorrect' or 'correct' size value to be. More importantly, he never refutes the claim that a record with a length of one byte would always cause Windows to spawn a new thread and begin executing 'data' as code.
Re:Microsoft smoke & mirrors (Score:2)
WMF Exploit with different record lengths, completely invalidating Gibson's claims [slashdot.org]
Like they say, politicians always know best! (Score:2, Funny)
Re:MS shooting itself in the foot? (Score:2)
FYI -- Microsoft has announced that it is extending support for XP Home.
Link: http://www.itnews.com.au/newsstory.aspx?CIaNID=21
Re:MS shooting itself in the foot? (Score:3, Insightful)
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 'graphic
Re:MS shooting itself in the foot? (Score:2)
RTFA. Win 9x is not vulnerable to this problem at all. Never has been.
Of course, if you care a bit about security, you should ditch Win 9x (and Me) immediately and never look back, but this is not an example of one of their many vulnerabilities.
Re:Illegal byte size in the metafile record (Score:4, Insightful)
It's important (from MS' viewpoint) because Gibson used the incorrect data to support a claim that this was an intentional backdoor. Given Gibson's general modus operandi, I'm sure the data being entirely incorrect won't slow him down a bit, but at least anybody with a somewhat unclouded view of reality realizes he was full of nonsense.
While you can trigger this with broken data, those who RTFA realize that the broken data is entirely incidental.