Slashdot Mirror
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.
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.
Windows 3.0?! Ok, if it was a problem back then, why didn't it get fixed when the security environment changed? Windows has too much of a legacy going for it, and I'm surprised they held on to it this long. 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?
Monstar L
An interesting quote from the first link:
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?
The Tao of math: The numbers you can count are not the real numbers.
Seeing as I didn't get an answer last time (probably posted too late), I'll re-post my response when this was linked to in a comment in a previous article:
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?).
Has anyone looked at the leaked source code to determine anything from the code written there? I've never actually seen or possessed the code and I wouldn't know where to look even if I did. But I'm sure SOMEONE out there still has it and so I wonder if anyone has examined the source to see if anything interesting appears there?
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 deal of explanation as to why they would:
a. Keep what they knew could be a problem,
b. Make it even worse in their "new" edition.
I can see why they might have put it in in the first place, as a way to cancel printing, but what I still can't understand is why you'd extend to that extent.
Oh... yeah... it's Microsoft!
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, there are tutorials out on the net showing you have to write programs that, eg, dump the contents of forms on Safari SSL connections - so you can quite easily write spyware that simply sends bank details to the owner.
Windows 95/98/Me operating systems are more secure than Windows 2000/XP.
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 backwards compability.
I'm suprised that for a company that calls it self innovative that they didn't anticipate the landscape changing and updated their softwares appropriately.
This should have never even been in the WMF specification in the first place .
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.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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 Microsoft trying to find what values and what commands do exactly what, and without that efforts, I would not maintain a Win32 port at all.
I'd even go so far as to say that when used as designed (single-user clients) were more secure. A box that runs no services listens on no ports, and a box that listens on no ports cannot be compromised remotely. Unbind NetBIOS from TCP/IP (5 minutes) and you eliminate the only attack vector on an out-of-the-box 9x installation. On XP (pre-SP1), you had to manually disable the uPnP service, NetBIOS service, Messenger, probably half a dozen other services that I'd forgotten, and use third-party tools (software "firewalls") to block port 135 and friends. Just about every service that came bundled with XP turned into a hole over the past few years. People running 9x was never affected.
People running IE (especially with the insecure default settings that enabled Javashit and ActiveX), or Outleak, were hosed -- but they got just as hosed on XP as they did on 9x.
It's not just that more people are targeting XP - it's that XP presented itself as a much bigger target.
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 which doesn't need to be present in order for a UNIX system to function. The vulnerabilities in Windows are a part of the OS.
Comments like this show that you probably don't have a lot of programming experience. The fact that they know what went wrong is because they already investigated it and fixed it. If they fixed it and still couldn't explain the problem, I'd worry that they didn't really fix it at all.
Hindsight is 20/20. Foresight is a little trickier.