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."
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
Agreed. While it is important to know whether or not this was put in intentionally (IMHO, not intentional), I think what's more important is the fact that it exists, and what can be done to reduce the exposure to this flaw. Educating users is a good start. Maybe more of the mainstream media could cover stories such as this, and include instructions on how to patch / update for those who don't know.
"Teleporting Rodents with D-Cell Battery Displacement" theory -- IgnoramusMaximus (692000)
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.
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
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.
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.