Slashdot Mirror
WMF Flaw not a Backdoor
koro666 writes "In a blog post, Mark Russinovich from SysInternals responded to the allegations made by Steve Gibson labeling the flaw as an intentional backdoor. It seems that the hype was about Steve's discovery that the code would only be executed if the size of the metafile record was deliberately tampered with, which is not the case. The technical details are explained in his post."
Not quite a backdoor in itself, but it makes a very nice doorframe. Complete with the Windows 'critical flaw of the month' moulding and Welcome mat placed in front of it, just ready for someone with a door to install it into the wall...
Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
At least not many people I know.
I think the real question about this WMF vulnerability is how on earth could it have survived five years under the new security aware, code auditting regime that we supposedly have at Microsoft?
(Please don't reply that the wine people implemented it too - their goal reimplement the windows API, not audit it for security)
My pics.
because the issue continues to draw media attention I've decided to publicly document my investigation.
:)
i.e., I'd better hurry and get this out before nobody cares.
FREE - Java, J2EE and Ajax Audiobooks for Software Developers - www.DeveloperAdvantage.com
I think the real question about this WMF vulnerability is how on earth could it have survived five years under the new security aware, code auditting regime that we supposedly have at Microsoft?
(Please don't reply that the wine people implemented it too - their goal reimplement the windows API, not audit it for security)
Sorry if I don't care about your rules for what I may and may not reply, but that the wine group did implement it says a whole lot of how difficult it was to spot. Their goal was to reimplement the API, sure, but you can bet your ass that they would have reported it if they saw it. And they did, despite it being right under their noses. Even Russinovich makes this point (but I guess you didn't really read TFA anyway, did you?). Forgive me if I trust his judgement a little more than yours.
That doesn't say anything bad about wine coders, who, as we all know, are pretty good coders, but it does about the subtlety of the issue. Yes, MS deserves some blame. But let's keep things in proportion -- this was a tricky little bug.
Conspiracy theories don't need reasons backing them up
You've got a good point here and it describes the other side of of Steve Gibson. After reading that site, you'll understand his stories are mostly made of popular speak or disinformation, rather then scientifical information.
So while you may admire him for his charisma, you shouldn't for his expertise. Would you e-mail him about an error, he'll silently correct it as if he'd always known it. You won't find him at an official security conference, but in the eyes of his fanbase he remains a god. I can image people are felling for his stories through, his stories make you get excited easily.
The best way to accelerate a windows server is by 9.81 m/s2
It's hardly a competition. Mark knows Windows inside and out. He was the first licensee of the Windows NT source code and used it to produce a toolkit that is used as the basis for many of the device drivers that have been produced for Windows. Gibson has written some apps and has shot his mouth off about something before he'd looked closely enough. Sure the documentation for SetAbortProc was wrong, but this is a mechanism that is used in many parts of the Windows API and he should have realised how it was used.
Hit counts don't count for much. Britney Spears is the highest in terms of web searches. I guess that means she beats both Mark and Gibson.
Sorry if I don't care about your rules for what I may and may not reply, but that the wine group did implement it says a whole lot of how difficult it was to spot.
My point was that the wine people's goal was to reimplement. Not audit.
MS's goal over the last 5 years was to audit. You would think they would have looked particularly hard at code with roots in Windows 3.1 (which, as Russinovich pointed out is a common source of poor API design)
Their goal was to reimplement the API, sure, but you can bet your ass that they would have reported it if they saw it. And they did, despite it being right under their noses. Even Russinovich makes this point (but I guess you didn't really read TFA anyway, did you?). Forgive me if I trust his judgement a little more than yours.
Well, forgive me if I don't trust some MS shill posting anonymously on slashdot, especially when they say:
That doesn't say anything bad about wine coders, who, as we all know, are pretty good coders, but it does about the subtlety of the issue. Yes, MS deserves some blame. But let's keep things in proportion -- this was a tricky little bug. [emphasis mine]
MS deserves some blame? Who else should we blame? The wine group? Mark? Steve Gibson? Slashdotters?
Microsft deserves all the blame for this - they're responsible for the bad design, the bad implementation and the lax audit. Suggesting they only deserve a portion of the blame shows your bias.
My pics.
So, why would M$ (or anyone there) need to create such an elaborate "back door" to Windows? I mean, they could put anything in anywhere they wanted to. If they wanted to download some stuff to my PC and execute it they could distribute it as an update. They could add the code to IE or the kernel. This is one of the dumber conspiracy theories I have read.
When Gibson was asked about the WMF thing being a back door he immediately replied "that's the only explanation." To me, that's not the language of a man who is open minded. There's no evidence that this is a backdoor other than Gibson's accusation and that is based on a false premise (that the metafile size was the deciding factor).
How did it get into Wine? Well, there are two ways it could have done. One involves Microsoft documenting the behaviour of the relevent calls, which, the TFA implies, they did. They did it in the context of the printing subsystem, but it was, certainly, documented, and the reasons explained in that documentation make sense. This is almost certainly how the behaviour got into Wine.
The other possibility is that there are a lot of WMFs around that make use of the feature, and after debugging, the Wine people found it worth implementing for compatabilities sake. We can safely assume that if there are that many WMFs around that us4e the feature, and they're not trojans or viruses (which we can assume they're not otherwise the Wine people wouldn't be trying to be compatable), then, again, Microsoft's reasons for incorporating the feature are, on the face of it, legitimate, and they're implementing something many programmers find useful.
As usual Steve Gibson, like his brother Mel*, is seeing conspiracies that appear to have more to do with his dislike for those he disagrees, and, even more probably, his wish to attract a large audience of people who dislike them even more, with than any real bad faith on (Microsoft)'s part. Unlike Mel, he doesn't seem to be that successful, probably because the vast majority of the audience are a little more open minded, their open intelligence and open-mindedness often being the reason they dislike the dominant operating system seller in the first place.
* Yes, I know he's not his brother, I'm just making a point.
You are not alone. This is not normal. None of this is normal.
If you want to render something postscript-like onto a screen, why not just reuse the printer code?
I can see how it happened. The original introduction of setabortproc violated separation of code and data, but it was needed for performance - and on the kind of hardware win3.1 ran on, that was vital. I suppose it shows that you should never compromise on design for the sake of performace - but in the real world, you have to. May I also point out that if the x86 had a working way to mark memory non-execute then this wouldn't be a problem.
I am trolling
Steve Gibson: 12,700,000 results.
William Gibson: 21,300,000 results.
Now who's your daddy?
Never ask for directions from a two-headed tourist! -Big Bird
Perhaps Steve would like to present his findings at the next DunceHats security conference. We could do with people of his caliber.
Tim Brown
I mean, if I worked for Microsoft, given the context, I can tell you right now that had I invented WMF, I probably would have made a similar error in the name of "flexibility", and I would have assumed that computers in five years time would be using real-time EPS (that's embeddable PostScript, the initials standing for Encapsulated Post Script, for you young'uns, that's what we were all talking about then as being the future of vector formats) renderers, not WMF, seeing it as a short-term hack until processing power became powerful enough. I certainly would have been surprised to see it still in operating systems in 2006. I'd have been surprised to see the ix86 range in computers in 2006.
Bad faith on Microsoft's part? Bullshit. Microsoft made no effort to hide this one. It made sense they implemented it that way given the context. It was an error, a short-termist attitude which has undermined many a Microsoft product. Until the late nineties, Microsoft was routinely making such errors, the most infamous being the support for embeddable, automatically run, Visual Basic scripts in Word documents. Why this is being treated as any different to every security error Microsoft has made in the past is beyond me.
You are not alone. This is not normal. None of this is normal.
I'll guess from your handle that you may not be a native speaker of English. In which case, allow me to offer some friendly advice - the word you were probably looking for is "analyze", with a "y". "Analize" with an "i" is also a verb meaning...well, something else.
Okay, mod me offtopic now....
ABSURDITY, n.: A statement or belief manifestly inconsistent with one's own opinion.
Either way, it is still hard to tell why it was designed that way in the first place, maybe one of these links can tell us?
It's quite simple:
WMF is used under the hood in lots of places in GDI. Any time GDI passes a bunch o' commands from one place to another, you'll find WMF. And as a result, WMF encapsulates almost everything you can do with GDI.
SetAbortProc is used to allow an app to display a custom "Printing Page xxx of xxx... [Cancel]" dialog to be displayed on Windows 2.0, 3.0 and 3.1, all of which are cooperatively multitasking and so need to drain their message queues on a regular basis - which they do every time that AbortProc is called.
There are even examples of this exact behavior on MSDN. It's still semi-useful under later versions of windows to be able to do this, and it's good for backwards compatibility, so it stuck around.
Coming soon - pyrogyra
While I'm not an apologist for Gibson, I think it should be pointed out that he stated quite clearly in the original interview that his view on the metafile vulnerability was conjecture, and was based on his limited work with the subsystem.
This wasn't a Chicken Little incident. I thought it was very reasonable, controlled, open to correction, and intended mostly to elicit a response from Microsoft, which clearly it did. All in all, I think this was a positive exercise in nearly every respect.
The sociology of this is more interesting than the programming details, in my opinion. It often happens that one person in the computer industry analyzes an abuse, and another person, who is competing for attention, attacks the first person. Admittedly, Steve Gibson of grc.com has a flawed, exaggerated manner of communicating. But many abuses never are fully recognized because technical people attack each other, rather than analyze carefully how they are being abused.
:-("
As others have mentioned in comments I have excerpted below, the U.S. government stated clearly and for the record that it wanted access to all computers. It appears that the government got what it wanted in what I think I can show logically is the only way possible.
Mark Russinovich of SysInternals is an extremely competent programmer. His utilities for Windows are the best available. Even Microsoft recommends using them, to supplement the limited and unfinished and flawed utilities supplied with Windows. However, Mark Russinovich is not a sociologist, so his comments may not take into account the complexities of the social issues.
The main issue seems to be, not that graphics files have the ability to execute code, but why was there inadequate testing in the code to prevent security vulnerabilities?
Here are quotes from Mark's article:
"The actual reason is lost with the original developer of the API, but my guess is that he or she was being as flexible as possible."
And: "... given a choice of believing there was malicious intent or poor design behind this implementation, I'll pick poor design. After all, there are plenty of such examples all throughout the Windows API, especially in the part of the API that has its roots in Windows 3.1. The bottom line is that I'm convinced that this behavior, while intentional, is not a secret backdoor."
Mark's perception of Microsoft's sloppiness seems correct to me. I coded a program for Windows 3.1 using the Windows 3.1 API that dialed to a bulletin board and downloaded stock quotes. I was amazed at the extreme sloppiness and bad design of the Com port API. The actual code that Microsoft shipped had the quality of code that I would expect from an overtired programmer's first draft. A rested programmer would not have been so sloppy, even in his first proof-of-concept code.
Quotes from the comments:
"Thanks for this excellent analysis! Steve Gibson certainly does not deserver to be taken seriously by anyone, but unfortunately he is
This is a reference to the fact that Gibson's language often contains a hysterical, exaggerated quality.
Another comment -- This commenter makes the point that Microsoft had hired a technically knowledgeable top manager, who would certainly demand that programmers check the security of any code that is supplied by a user:
"Q: When was this backdoor coded?
A: About 1992.
Q: How old was VMS at that time?
A: 15 years.
Q: Who directed the development of Windows NT?
A: Dave Cutler.
Q: What's Cutler's background.
A: Directed VMS at DEC.
Q: On who's watch was this security lapse ported into the Windows NT stream.
A: Presumably Cutler's.
While anything's possible, it's hard to imagine how a security lapse of this magnitude (trusting user-written code) could have made its way into VMS code.
"The point is that Stephen Toulouse's "the security landscape in the early 1990's was very different than today" is, well, self-serving. Only in MS's myoptic view is this the case."
Another comment:
"Now that I think about it, even Mark has to guess at what some coder was thinking when she wrote this, and maybe she did it intentionally. You'll never know will you? Maybe somebody's been watching all of us for years, and it ends up in some massive NSA database."
An