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.
by stupidity.
Why waste time putting in a backdoor? Just ship the OS around the world and enjoy.
With an expensive scaled up consumer operating system - the operating system is the backdoor.
Domestic spying is now "Benign Information Gathering"
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.
"The bottom line is that I'm convinced that this behavior, while intentional, is not a secret backdoor."
So it is intentional and survived how many security reviews, yet isn't a secret backdoor?
Keep drinking the Kool-aid.
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
and that's all Steve Gibson does. If I read one more blurb about how great it is that he can code in assembly...
This guy is way out there
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.
This is more of a hole than a door.
You are not alone. This is not normal. None of this is normal.
I think everyone would agree that Steve Gibson is a technically-gifted person, but we should also agree that the guy is a little wacky, just like we should also all agree that Theo De Raadt is a little hot-headed. Not that this makes Steve or Theo a bad person - quite the contrary! It's just that when they make grand pronouncements, the pronouncements should be viewed skeptically. Anybody remember the controversy over NSAKEY a few years ago? I.e., a flurry of wild allegations over something used for code signing that no one now cares about now that it's named something less offensive (_KEY2 for those playing along at home). It's easy to get all hot-headed and worried and freaked out, but that's the antithesis of what a information security officer is supposed to do. They are supposed to stay calm and rational in times of crisis, never jumping to conclusions (because most of the time, those conclusions are worse than wrong: they are misleading). Well, I'm ranting but you get the picture.
I'm proud of my Northern Tibetian Heritage
Gibson is an idiot with a talent for self-promotion.
Big time. He's the guy who came up with broken SYNcookies and blathered on and on about how they were "Beautiful and Perfect". Gibson is a quack and no serious attention should be paid to his ramblings.
We have more to fear from the bungling of the incompetent than from the machinations of the wicked.
Not to add to the continual Linux vs Windows battle-royal here on /. but this is exactly where being able to look at the source code helps. There would be no conspiracy theory if we could see the code related to WMF files. The most we'd be able to do is say "Damn, why'd they do it that way?". As one of the readers already posted, Mark Russinovich has seen the NT source, and is in the best position to say what is or isn't in the code. The rest of us are left to listen to whatever source seems credible at the time and hope they're right. Hiding things from your customers leads to just this sort of public speculation, and when you're the voted "Most hated monopoly", public speculation isn't really ever going to be in your favor.
He is important on popular media (ZDNet) and he is taken serious by non geek computer users, that is a huge power.
I admit he explains the stuff very easy but especially his continuous realplayer bitching made me anxious. It was "half true", "half right" and MS Windows Media player came with "GUID" ON while Realplayer came with GUID OFF by default.
(not speaking about current sw after even dumbest user learned what spyware is)
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.
But it succeeded in getting people to see the name Steve Gibson on a website again. From the plagarizer of SynCookies, the father of Raw Sockets paranoia, comes a new wild and unfounded allegation, WMF bugs put there intentionally to let Microsoft SPY ON EVERYTHING YOU DO OMGWTF!
I can't believe people on the last thread actually took him seriously without looking at his past media whoring failed attempts at security analasis.
Steve Gibson is the Bob Lazar of the security field, only wackier.
I like music
We're talking here about a file format designed in the late eighties, based upon the original Win16 API, with support for callbacks, designed then, not in 1999, to be written in 80x86 assembly language. You bet implementing that in a modern OS would cause security problems. We can be armchair operating system designers here and say that Microsoft should have adopted something more akin to EPS, complete with sandboxed programming environment, back when it became viable, but it's one thing to say "Microsoft, you suck!", it's another to claim they're Sonying our machines.
If I had to find a paranoid, Microsoft is evil, reason for this, I'd say follow the anti-trust behaviour trail. They continued to support, and encourage the use of, a major file format with a key feature couldn't be fully supported on any operating system that didn't implement a significant part of Win16? I wonder why that would be!
You are not alone. This is not normal. None of this is normal.
I agree his explanation is a bit off, but I still feel this is a mistake, not something intentional.
Where he is wrong is his assertion that MS saw any reason to put the AbortProc into WMF files. The fact that they work at all is entirely by accident, nobody went and typed in any code that is executed only for making AbortProc run from the file.
What happened is they had an interface of a few hundred calls to print and control printers. They wanted three things: for the calls to work, for the same calls to write a WMF file, and for reading the WMF file to do the same thing as the original calls. The only reliable way to make sure the WMF file does the same thing as the original calls is to make sure they call the same code.
To do this, they made up an enumeration for every call. Every call was then recoded to turn it's arguments into a block of data, a length, and the enumeration value, and to call a central function. This function first checked if a WMF file was being written, in which case the enumeration and block of data was written to a file. Otherwise it ran a big case statement or dispatch table to code that took the arguments back out of the block and implemented the function. When reading a WMF file the reader extracted each enumeration and block and called the function as well. This meant that if the direct call worked, you were almost certain that the write and read of the WMF file worked, too.
It is highly likely this central function did a lot of other code before running the dispatch (such as check if the printer actually exists), and the SetAbortProc needed to do that code as well. So somebody implemented SetAbortProc as another enumeration, and stuck the code pointer into the already-available block pointer, and called the central function. I would guess that they left the block length as garbage (somebody needs to find out if you can write a SetAbortProc call to a WMF file using the normal interface to see. I bet it is not possible to create a usable file this way).
Without any planning they now have the backdoor. If you manually put the enumeration for SetAbortProc into the file, the file-reading code blindly calls the dispatch with that enumeration, a pointer into the file, and a length (which will be ignored). The dispatch calls the interpreter, which sticks the pointer into the AbortProc pointer. I expect the dispatch function also calls the AbortProc as the first thing, so the very next record causes the code to be executed.
Two things about this:
First, the code must have contained an obvious cast to a function pointer from a data pointer. This should have been trivial to catch with automated auditing tools. Once detected, it should have been easy to prove that the normal interface could never write a working SetAbortProc to the stream, so there was no reason to interpret it, and rip the function out of the dispatch and recode SetAbortProc to set the pointer directly.
Second, it is a good reason why such designs are trouble-prone. A stream-based interface is better, where the user code constructs the stream in a buffer, and the contents of this buffer, rather than the calls used to fill it, is the definition of the API. In this design they never would have reused the interface for SetAbortProc.
[i]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)[/i]
.rhosts, authorized_keys, .Xsession, etc.) It wasn't even all that long ago that support for those commands was removed from ghostscript and it's decendants (xpdf, etc.). But last I checked, nobody has accused Adobe of trying to backdoor all of our computers.
And lest everyone forget, the PostScript language includes file operation commands (reading and writing). Which of course could be use for all sorts of nastiness by overwriting various important files (.login,
Or a number of standard Unix terminal emulators which have had some pretty iffy functions added to them which can lead to system compromises: TERMINAL EMULATOR SECURITY ISSUES. Has anybody accused Rasterman (or whomever wrote Eterm) of trying to backdoor everybodies computer? Of course not.
What's my point? I don't know. Maybe that, as much fun as it is to kick around Microsoft for dangerous programming choices, they aren't the only ones to design systems and API's that have holes. In hindsight, both the PS and terminal issues I mentioned above are pretty obvious. I mean, slap your forehead obvious that you probably shouldn' do that. But they did.
When did he point that out? Certainly not in this interview where he was adamant that the flaw was a deliberate backdoor. The only thing he equivocated on was who at Microsoft knew, and how old it was.
Si vis pacem, para bellum
The only thing more annoying than a Libertarian is an (un|mis)informed Libertarian