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."
Conspiracy theories don't need reasons backing them up. I still think that microsoft eats babies.
I'm sorry. The number you have reached is imaginary. Please rotate your phone 90 degrees and try again.
Well, googlefight has Russinovich on the ropes, Gibson comes out well on top as far as hits go.
However, Mark has been gaining himself a decent reputation recently.
I know whos opinion and factchecking I trust at the moment.
Mark Russinovich
483,000 results
Steve Gibson
13,700,000 results
liqbase
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.
read topic much?
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
Gibson is an idiot with a talent for self-promotion.
The reason no one stumbled onto the WMF thing until now is because Windows is a f*cking big program and, basically, no one spotted it until now.
And already had a link refuting the claim that an invalid record size is necessary: http://blogs.technet.com/msrc/archive/2006/01/13/4 17431.aspx
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.
Actually, The Third impressions count was a trupe, not a dupe...
First of all, that was extremely wordy article to explain the WMF vulnerability, IMHO. But some important points were made:
...given a choice of believing there was malicious intent or poor design behind this implementation, I'll pick poor design.
if an attacker can get your computer to execute their WMF file through Internet Explorer or Outlook, for example, they can make your system execute arbitrary Windows commands, including downloading malicious applications and launching them.
My belief is that Microsoft developers decided to implement as much as the GDI function-set as possible.
In any case, its not clear that the developers envisioned applications creating on-disk metafiles with abort procedures.
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?
He who knows best knows how little he knows. - Thomas Jefferson
Well, as their name subtlely denotes, backdoors are on the back, hence the difficulty to spot them if not proactively looked for.
That must be the raison d'etre for constructing them in the back.
And, to conclude, if it is built like a backdoor, and squeaks like a backdoor, it must be a...
My other post is a First.
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.
Of course it's not a backdoor, in more exciting news a whale swims up the Thames.
So what? The WINE people implemented it too.
(Oh wait. DON'T reply with this. Sorry)
Don't fight for your country, if your country does not fight for you.
Whenever I hear the words "Steve Gibson" or "GRC has advised that..." the first thing I think about is my old flatmate trying to install Debian PPC onto his Sun Ultra 5, also known as "Clueless n00b!"
"how on earth could it have survived five years under the new security aware, code auditting regime that we supposedly have at Microsoft?"
It takes time to look trough 35 milion (Windows 2000) - 40 milion (Windows XP) lines of code...even for a big company.
Slightly off topic but I was plesantly supprised to see that in Visual Studio 2005 (probably where there already in VS 2003 but I've never used that one) most of the offending runtime functions (memcpy, strcpy etc) have been marked deprecated and replaced with more secure functions checking for buffer overflow.
Many other functions such as to stop hijacking of the stack pointer etc have also been implemented.
http://www.intellipool.se/ - Intellipool Network Monitor
duck?
*ducks*
Anagram("United States of America") == "Dine out, taste a Mac, fries"
The thing is, with all the lines of code in Windows, you don't really think that they looked at all of them ? There are most certainly a bunch of other flaws in Windows. It's just that nobody with the will to share it has found any yet.
--
Krazy Kat
Write boring code, not shiny code!
A good OS is made of much more than a Play-Doh user interface.
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.
>WMF Flaw not a Backdoor
And that's not incense.
You've never had a security flaw in your code? It's an *accident*, the same as when the postman falls over and breaks your parcel. Oh wait, I forget, in America there's always someone to sue.
I am trolling
... when you can just throw a small rock through windows!
Then there's the creepy "Tell Microsoft about the problem" button on the dialog that comes up whenever a GUI application (from any vendor, not just Microsoft) crashes - I bet their marketing folks get lots of good information on what apps people use on a regular basis, how they're being used and what frustrations their users are having. I'll bet that none of the information is passed along by Microsoft to Adobe or Corel or whoever wrote the app. Now that's evil.... Steve Gibson should be writing about that.
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
Some things are accidents. Some things are deliberate. Some things are somewhere in between. It looks to be the popular slam of the day to attack Gibson over this. Just like it's always popular to slam MS and, for a year or two, it was popular to slam the GPL.
Step back off the tinfoilophobery, close your eyes (so you don't get too scared), and just think for a moment... "What if?" I know it may be a frightening experience for you, and you may need to broaden your horizons just a little... but "What if?"
If you go with "What if?" then hiding a backdoor in WMF is a very logical thing to do.
fast as fast can be. you'll never catch me.
The WMF flaw IS a backdoor. It's just not INTENTIONAL.
Perhaps Steve would like to present his findings at the next DunceHats security conference. We could do with people of his caliber.
Tim Brown
Excuse me if i'm wrong but i believe this post was stolen from a previous artical way back when. I know this why? because i sit at home in my mothers basement looking at slashdot all day and have a kick ass memory ... almost as good as ecc ram!
If i wasnt a lazy slashdot junky i would actually go looking for this posting but at the end of the day the GP being the 1st post and being so long at the same time makes obvious sense that it was c&p from somewhere.
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
Steve Gibson gave his final word on this matter in a thisweekintech podcast interview: http://thisweekintech.com/sn23 Briefly, someone at Microsoft had the bright idea that one should be able to run code inside an image, for whatever reason. This left a backdoor, probably unintentional. Mr. Gibson regrets that his use of the term "backdoor" implied malice to some people. This was not his intention.
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.
FTA:
"I've addressed the first two of Steve's observations, but what about his claim that the abort procedure only executes when the SetAbortProc record contains certain invalid record sizes? I've analyzed the control flow of the PlayMetaFile function that executes WMF file records and found that, if an abort procedure is registered, it calls it after executing each record except the last record of the file. That behavior makes sense since there's no need to ask an application if playback should be aborted when the playback is already completed.
Steve's example WMF file contains only one record, the one that specifies SetAbortProc, so under normal circumstances PlayMetaFile will never call his abort procedure. The record sizes that he found trigger its execution cause PlayMetaFile to incorrectly increment its pointer into the WMF file such that it believes that there are more records to process, whereas the values he used that don't trigger the execution land it on data values that indicate there are no more records. So his assertion that only certain magic values open the backdoor is wrong."
To me this looks like Gibson actually stumbled on another bug in the same piece of code.
It was funny seeing how a lot of people were dismissing the "Gibson Bashers" in the original /. thread. Well, guess what? grcsucks.com really was right about the guy. Told ya so. Mmm, vindication. :)
Just take one look at the sensationalist language and snakeoil-salesman design style of Gibson's website (doesn't it remind you of other shady sites) if people need more convincing that Gibson is a fraud.
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?
Windows has a gigantic amount of code. That's one problem. Second problem might be that Microsoft lacked a reviewer who had could see "the big picture". I could code an API call that takes in a few parameters and makes a callback function. The API call itself is 110% well coded, safe, parameter checking and whatnot. But I do not know who uses it and for what reasons. So it can be made entirely unsafe if the upper layer of the system allows unsafe use of it. If someone doesn't see the "big picture", safe functions can be used in an unsafe way and since no one can connect the dots, the WMF flaw was probably reviewed as "safe".
Then again, it could be simply that it has fallen through the cracks. Maybe some reviewer did a sloppy job and said: Well, it's an old unused subsystem that no one uses so it's safe!
christ man, there are many many many..
2 34.shtml
the mailman sues his employers, for putting him in harms way
the manufacturer of his footwear, for it not being slip resistant enough
the manufacturer of his mailbag, for a capacity spec that allowed him to get so top heavy/off center
you, for shipping/recieving dangerous goods that did not break his fall- and gave him a nasty bruise an emotional disturbance.
the people who witnessed the event all sue the above, plus the mailman, for emotional disturbance
the USPS sues all the above, including the people who sued for emotional disturbance for the damage this does to the USPS reputation
then OSHA gets invloved, and fines USPS
and then congress passes laws requring one carrier per piece of mail
then the economy breaks down, and causes the apocolypse.
hmm.. looks like they were right after all
http://science.slashdot.org/science/06/01/16/1240
every day http://en.wikipedia.org/wiki/Special:Random
Absolutely. Last year, someone discovered a security hole in the Linux kernel that had been in every version since 0.9 or something. And this is one of the most widely examined and audited pieces of software in existance. The *nix system has a lot of old software, and probably has a very similar rate of old bugs and design flaws as Windows.
You've been tricked by an old troll. This sort of copy-paste first post crap is hardly "the expression of ideas".
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?
The "security aware" thing is marketing, not technical. It's "we make security updates every other wednesday, no matter if we have a problem or not, and no matter if it should have been fixed last week". Makes you look good to those who don't know anything about IT security (like reporters), without improving real security.
No, the day Microsoft starts caring about real security, we will know it. It will be the day we see KB123456789: Remove support for ActiveX from all versions of IE.
Until then, "it's a feature, not a bug" is still the way they work.
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.
No, it isn't. To believe this is a backdoor, you have to believe that people thought Windows computers were going to be hooked into a giant, international, network back in 1985-1990
I don't believe it's a backdoor, but no, you don't have to believe that the alleged WMF hacker was prescient. The WMF flaw would also have been a useful way to get a user to run malicious code on his computer. If you were an early 90's black hat and you wanted to do something nasty to a particular person's computer (to which you didn't have physical access), you could give them a diskette with an image file that would run arbitrary code chosen by you. If said person didn't trust you, they might not be willing to run a binary you gave them, and they'd probably be very careful not to boot off the floppy you gave them (boot-sector viruses were common then), but they might very well use an image file.
As I said, I don't think this was an intentional backdoor, but if it were it could be exploited without a network.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
We've twice gotten reports from Microsoft, based on those crash logs from users running our applications. In both instances, they included workarounds/explanations for the problems that were causing the crash.
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
revision 1.12
date: 2006-01-06 20:52:46 +0000; author: julliard; state: Exp; lines: +7 -0
Marcus Meissner
gdi: Filter GETSCALINGFACTOR and SETABORTDOC proc in metafile
Escapes.
While Steve Gibson is a bit of a crank, Mark Russinovich is also a Microsoft Apologist. Here are my problems with the explaination: Reading an address: SetAbortProc * fn; read(&fn, sizeof(SetAbortProc), wmf); (fn)(...) vs Reading code: read(code, bytecount, wmf) SetAbortProc * fn; fn = (SetAbortProc) code; (fn)(...); Even Mark was a little confused about this behavior: "The remaining question is why PlayMetaFile expects the abort procedure to be in-lined in the metafile. It's that fact that allows a hacker to transport malicious code within a WMF file. The actual reason is lost with the original developer of the API" He then goes on to make an excuse for the developer being flexable or something. NO developer would see the utility of embedding code in Windows 3.1 or even Win32 as the code fixups are not made in a data source. In Win16 days, you wouldn't have access to your data segment. If this bug was around in real mode days, you couldn't even be sure your program was in memory without a thunk. It is this feature that is the dangerous and of the most dubious utility, and it is this feature that gets a quickest glossing over. I am reminded of the NSA key BS about Microsoft needing a duplicate key in case they lost the original. Give me a break. Now, I respect Mark Russinovich's technical abilities, but he has, most of the time, been a Microsoft apologist, and I don't think that this piece is any different. There is a feature that allows arbitrary code to be executed, there is no real reason for it being there as developing code to use it would require a different tool chain than that used to create applications. As the Windows API went from 16 bit to 32 bit, from a DOS extender to a VMS hack, this functionality has been maintained, and that would require work as the C language and compilers and bit depths have changed over the years. Sorry, I don't trust Microsoft, if its there and has been maintained for some time, it is there for a reason. What is that reason?
I'm looking, just as I looked when he first said it. But Gibson's evidence was completely false, and without it the bug is no different from hundreds of bugs caused by ordinary incompetence all the time.
I am trolling
^Fixed that for ya^
[Fuck Beta]
o0t!
Since I happened to reply to this post a while back, here's your link
5 &cid=13786646
http://science.slashdot.org/comments.pl?sid=16521
Interestingly, as I pointed out before 100% is > 1% it's not like continuing to have > 1% of a market is bad.
ACMD eht detaloiv evah uoy
Mod this guy up!
- It's clearly a back door, it looks and acts like a Back Door, therefore, it is.
- Is it an INTENTIONAL back door?
Hopefully, no.
But, this does bring up the sheer lazyness of the MS group.
New functionality should have gone into a NEW API, with no "Legacy" code inside the function.
Today, that's called ReFactoring. In 1995 that would have just been Good Coding Practice.
All of the legacy code should have been retired when it's functionality was.
There is a clear reason why Microsoft might want to create a backdoor in its operating system. Microsoft was a proponent of UCITA, including its provision allowing "self help", i.e., under certain legal conditions, and in the case of a contract dispute, a licensor could break into a licensee's machine and disable the licensor's software. (The term "self help" is adapted from the legal terminology related to automobile repossession.) UCITA was enacted by two states and the enactment effort, while relatively dormant, is not dead.
If the licensed software is an application program, it is difficult or impossible to break in without being allowed to do so by the operating system. This means that Microsoft would have to be involved in some way in any "self help" effort by a licensor for an application residing on a Microsoft platform. That gives Microsoft reason to create a backdoor, preferably in some operating system function that is likely to be available for entry when the "self help" effort is attempted.
So, you think that M$ can and have put backdoors into your system but you still use it? Now that's dumb. Who needs conspiracies when everyone accepts their reasoning as good business practice? Here's a little refresher on what backdoors are all about.
The reasons for backdoors is so that you and your friends can access the target. There's plenty of circumstantial and other evidence of the US government demanding such access to computers in general. This should not be surprising in light of DOJ and FBI wiretapping demands and a long standing history of domestic spying abuse. There are many well documented cases of security being less than advertised by zero padding and other nonsense like that. I also know of people who claim they got out of business when approached by government representatives who demanded such access to their software. Closed source software conceals such garbage.
The only software you can really trust is the kind you can inspect and build yourself. If it matters, you should not run anything else.
Friends don't help friends install M$ junk.
What else is there to say? It's a bit of legacy code left over from the days when it was safe to assume that any code on a computer had been put their with the owner's knowledge and consent. That assumption has since been invalidated by subsequent events. A backdoor it may be -- but when it was put there, there used to be a fence around the back garden.
And this is just one example of a whole class of things that are really, seriously, terribly wrong with Windows {and for that matter, closed-source software in general}. A lot of benign application software has come to depend on behaviour in the operating system that ought never to have been allowed in the first place -- behaviour that makes the propagation of viruses and worms so much simpler. Now, if Microsoft change the way Windows works so as not to just hand out permission for any process to interfere with any other process, then the worms and viruses that depend on this behaviour will die off -- but so will all those applications that depend on this broken behaviour. Then what used to be a choice between "Stay with Microsoft, and all your old software will still work like it did before" and "Leave Microsoft, and none of your old software will work anymore" becomes one between "Continue to splash out good money after bad to Microsoft, but none of your old software will work anymore" and "Wave goodbye to Microsoft, none of your old software will work anymore but there are better-than-adequate replacements for all of it".
And my prediction? A company that still makes extensive use of an obsolete software product will find themselves -- and their precious data -- orphaned as a consequence of the switch to Vista. They will have to obtain a pirated copy or copies of an earlier Microsoft OS {because there is no way to obtain a legitimate one} just in order to read their own files. This will only be discovered in a Licencing Gestapo bust.
Je fume. Tu fumes. Nous fûmes!
AFAIK, the Wine people probably know about a lot of things in Wine that aren't securely designed. Doing secure software design is hard even for simple software, and when someone else has already done the design and you're worried about trying to make (often broken) code written to their design work under your system, it's not so obvious.
That being said, I'm not saying that I couldn't see them raising it, but it's not as if they were proposing designs and some guy was pointing out security holes in the designs, either.
Any program relying on (nontrivial) preemptive multithreading will be buggy.
How do I get Quake 3 to run on a Mac? OMFG! LOLZ!!!
1)Put in CD
2)Double click on CD that is mounted and appears on Desktop
3)Drag executable from CD to Applications Folder
4)Drink a beer.
I'm glad this has turned out to be an exploitable design flaw (that ignores firewalls and anti-virus protection), rather than a deliberate backdoor.
Such wonderful news has renewed my faith in Microsoft.
cant poor design be a way to code backdoors?
Gibson is a hack - nothing more, nothing less. Remember his famous "raw sockets" tirades. He said the whole Internet would collapse when Microsoft released Windows XP. So much for that. I must say, however, his tirades over BlackICE were some of the funniest. He misused a product and then claimed it to be faulty. When asked to explain his results and tests, he shreeeked how he wouldn't listen to anybody else - he was a scientist. Any scientist who refuses to listen to opposing ideas, is not a scientist.
Also, don't forget, Steve is a MARKETING person first and foremost. He has never had a technical job in his life. He has NO formal training, certifications - nothing. And I have NEVER seen him publish anything to any security group or magazine. This guy is to be ignored.
Steve Gibson thought it was a backdoor because he believed that the flaw really only existed since NT 5.0, when it seemed to him the code was changed. Unless you believe NT 5.x is not network ready then your first paragraph is untrue. This point was not made in the article. The transcript of what Steve actually said. I am not saying I think he was correct but just setting the record straight
Star Trek, there maybe hope.
So who shares responsibility with MS over accidents? No one. There's no one else to blame. As mentioned before, MS is responsible for its code, so it shoulders sole blame for accidents in its code. Not "some" of the blame. All of it.
Having said that, shouldering the sole blame for a bug seems pretty minor. MS releases a fix and that's that.
So it's an ancient, outdated function that's no longer really viable or necessary.
I tend to stick to the KISS principle: If it's outdated, unnecessary and a now proven point of attack, why not remove it?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
This would be true, if you avoid the fact that Steve Gibson take pride in coding his Windows apps in assembler. The normal release-compiled assembler x86 isn't that hard to grok, if you really claim to be a wiz at decoding it yourself. The debug symbols are out there for you to grab, too, so you get it nicely split up into functions.
You may want to read this article next time you fill up your bucket with tar and start stripping the feather dusters. Throwing blame around doesn't help anyone, and only shows your own bias.
Well, forgive me if I don't trust some MS shill posting anonymously on slashdot
YOU DON'T HAVE TO. The point was that Russinovich made the same point, you can look it up in TFA yourself. If you disagree with it, fine, but then let's be clear that you're not only disagreeing with "some MS shill" (what a ridiculously flamebaiting designator), but with Russinovich as well.
MS deserves some blame? Who else should we blame? The wine group? Mark? Steve Gibson? Slashdotters?
Not surprisingly, your semi-autism prevents you from reading that sentence the way any reasonable person would read it. Namely, that MS should be blamed, but that their mistake wasn't as severe as implied. You shouldn't read it to say that someone else deserves the blame they don't get, as if the amount of blame assigned is always some constant amount. "Some blame" obviously refers to "a portion of the blame you're ready to dish out" in this context.
Suggesting they only deserve a portion of the blame shows your bias.
You're such an idiot. I really mean that.
Gibson is a crackpot.
I gave up listening to him when I read his conspiracy theory for S.M.A.R.T. hard drives. Gee, so S.M.A.R.T. makes his software obsolete? Sounds like a marketing tactic.
"No matter where you go, there you are." -- Buckaroo Banzai
I'm not sure I even care if it is a back door, so much as I care if it can be used as a back door. If the answer to the second circumstance is "yes," then it would seem that what we're seeing in this debate is little more than semanting quibbling.
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 disagree. Look at the differences in style between the write-up on Gibson's web site and the article by Russinovich. Mark's article analyzes the technical issues and calmly points out what probably resulted in this vulnerability without making ridiculous claims--Gibson's site, on the other hand, spins all sorts of conspiracy theories and tries to make him look like a hero for "discovering" this evil deed perpetrated on us by Microsoft.
Look at some of the other things Gibson has done over the years and in the responses to it you'll see much more valid criticism than slams.
Source is moot in this argument, as it was not used by either person. Mark does not have source code access - the poster who stated otherwise was incorrect.
http://www.grc.com/sn/SN-023.htm
the word scientificAL?
That's the point. It's "some blame" because there isn't much blame, not because it's only a small point of the blame. Wheras if it were a deliberate back door, MS would deserve a lot of blame.
I am trolling
who is REALLY is responsible for this flaw? I don't think Steve Gibson created this thing and IMO, he thought he was exposing something which looked pretty much like it had to be intentional. And without the code to see how this software REALLY worked, his conclusions were correct based on the data he had.
Now, back to who is really responsible. It's Microsoft period. Even after they claimed to have rewritten there OS's after every other release, a hole the size of Kansas was left in since the early 90's? Come on, they didn't know that allowing executable code in a multimedia file format was a security risk?
IMO, if you trust Microsoft for YOUR computing systems, you should be feeling pretty naked right now.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
The WWF is not flawed! oh, wait, you said WMF.
Another thing this points out is just how much Microsoft resists open standards. As far as I can tell, the chief reason WMF was and is still widely supported in Windows is that it effectively emulates vector graphics. How many opportunities did Microsoft turn down to put in SVG, PDF, or similar support?
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
Conspiracy theories don't need reasons backing them up.
There is no way to disagree with that, if one accepts the anthropomorphism. s/theories/theorists/ would make this a stronger statement.
But whatever... At the time this particular exploit was introduced into Windows, there was definitely a conspiracy within Microsoft that involved at the very least mucking about with the documentation of the Windows API.
One of the reasons that Win30 and Win31 succeeded in capturing the market so quickly was because MS made the Windows API available to application competitors, notably Quattro Pro, then from Borland, and WordPerfect, then from WordPerfect. MS presented Windows as being a Good Thing for the entire software industry and got a lot of needed buy-in on that basis. During the development process for Win31, it was highly significant to the marketplace that Borland, WordPerfect, and other industry leaders of DOS software were writing native Windows versions of their applications, and urging their customers to upgrade from the DOS versions to the Windows versions. (The DOS versions ran better under OS/2 than they did under Windows since OS/2 had preemptive multitasking; moving the market to Windows versions of these products was critical to MS if Windows with its cooperative multitasking was going to survive the OS/2 challenge).
But MS wasn't playing fair: when Win31 came out, Excel and Word danced rings around Quattro Pro and WordPerfect. And when people started to look at how MS was able to get such better performance out of the same API, they found that the MS application coders were not using the same API at all: they were relying on undocumented features and features that were documented in misleading ways.
This and similar shenanigans from MS are matters of historic record, vetted by the courts. There can be no question that MS is a company that has used conspiracy tactics to gain market share. There can be no question that MS was doing this at the time it implemented the WMF structure under Windows.
Where does the WMF vulnerability fit in, in light of this background? Obviously it was not written initially as an internet backdoor.
But consider an MS application that used a trademarked WMF graphic on its splash screen. That graphic could run a small bit of code that would unlock hidden capabilities in the Windows API. For example, it could set DEBUG=TRUE in some low level part of the task scheduler, turning off chunks of code that other applications would have to wade through, and thus making the MS app so much more efficient in a way that would be undetectable even on dissassembling the code. There is no technical reason why the WMF vulnerability could not have been used in this way. There is no question that the MS corporate culture of that time would have celebrated and rewarded this kind of cleverness. In view of this background, and the fact that this vulnerability managed to survive the intense scrutiny of several major code revisions, the only reasonable assumption is that the WMF vulnerability is a deliberate backdoor and has been kept around because MS has thought it would be useful to them.
MS has always been a company that has put more value on cleverness than on ethics.
So the questions now are what has MS used this backdoor for, and what has been their plans for future use? Anyone who has used a Windows machine recently should be wondering what information MS has gathered from them and what MS is doing with that information-- the ability to swap a keyboard logger in and out as different graphics or icons are presented while an application is running is a disturbing thought.
I continue to think that there is cause here to consider a Grand Jury investigation. I don't see any other way in which MS employees could demonstrate that their unethical business practices haven't transgressed over the fine line and become criminal behaviors.
Tinfoil hat time, considering WINE had the same WMF vulnerablility implementing the Windows API, wouldnt it make more sense to design an API with subtle flaws if you didnt want to get caught putting it in deliberately?
What I'm not seeing in these discussions is the fact that what Steve Gibson found was very poor coding which resulted in executing code stored in a media file. A simple check of the illegal header size value should have rejected the media file but instead, it went ahead and adjusted some pointer which resulted in executing code.
There are really two issues here. One is that the WMF spec allows for executing code stored within a WMF file and secondly, the fact that an illegally constructed WMF file( bad length value in WMF header ) also results in code executing from whithin the WMF file.
So while it was already out that the WMF spec was flawed, Mr Gibson found that Microsofts coding tactics and security reviews did not find this 2nd way to get code executing in WMF files.
Regarding WINE, we seem to know that WINE does follow Microsofts spec on how WMF files operate, but did they also code the loading of the WMF file such that an illegal length value causes/triggers the vulnerability? I find it interesting that people seem to be brushing over what Mr Gibson found by describing so much of how the original flaw operates and all but ignoring what he was really exposing. ie. the dumbass way Microsofts coders didn't check for valid data structures in the WMF file.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
Simple. :-P.
The code for winevdm (Win16 layer implementation) traces it's existance back to the days before windows 95 (!)
It implements a function called WOWCallback16Ex which executes 16-bit code passed in an array parameter. Normally you can't do stuff like that in linux, but winevdm uses the special features of 32-bit x86 processors to put the process in vm86 mode where you can do pretty much anything.
This was used to implement a lot of the callbacks in Wine's 16-bit GDI layer... support for 16-bit printer drivers in Wine was top notch
Anyway, the WMF file interpreter, when it finds this SETABORTPROC, (correctly) ends up calling WOWCallback16Ex with stuff fed in from the WMF file when it calls the EndOfPage function.
Three notes:
1) It's difficult to "break out" of winevdm and do stuff outside of the wine 16/32-bit APIs unless you know this WMF is going to be running in wine. Code that would work in windows to break into 32-bit mode in that context and do bad stuff to the system will fail spectactularly (read: Segfault)
2) It doesn't work at all on Opteron/EMT64. There is no vm86, thus no winevdm, thus no 16-bit GDI support.
3) They fixed the bug. Which was to not allow WMF read from the disk to ever contain anything that can eventually be fed to a calback.
Just two seperate bits of code written long ago, following the MS required behavior to the letter, that were never imagined to be joined.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Ok. Carry on then.
This is an excellent post, the best in this entire discussion. Everyone hates microsoft today of course, but their predatory behavior was far, far worse in the early 1990's.
I don't read or respond to AC posts
So, just so that we're all on the same page...
Do we all really beleive that there's no backdoor in Windows XP?
Or just that the WMF "problem" isn't it?
Frankly, I'd be shocked if Microsoft didn't insert a backdoor into Windows somehwere. Apparently, the Chinese were woried enough about this very problem that they set up a program to look things over, and they're still looking into Windows alternatives.
[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.
Sorry for the reply to my own post but I just ran Steve Gibsons test app on an earlier version of WINE( 06/28/2005 ) and it does not have the illegal WMF header structure flaw.
So while the WINE people implemented Microsofts WMF Spec correctly, it appears they did NOT follow Microsofts practice of allowing an invalid WMF file to continue on and implement/execute the SetAbortProc vulnerability.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
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.
.wmf file in a webpage.
One, it took a lot longer to find. Two, it comes with every install of Windows. Three, generally Word document macro vulnerabilities were sent by email, not by simply visiting a website. Four, you're likely to notice a Word document openning, but you can easily hide a
Having said all this, I wouldn't jump to the conclusion it's a conspiracy. Nor is it radically different from the tons of other remote execution IE exploits, for most purposes at least, even though it's the wmf renderer that's responsible. I'd guess the main reasons for the hype is especially point one I mentioned, coupled with the fact that a 3rd party released a patch first.
The truth is, I'd imagine 99.9% of people don't need WMFs--your analogy to Word auto-executed macro viruses is pretty spot on, since their usefulness is about the same, I'd say. So, even without a conspiracy, it's just another sign of MS including junk from the past without the proper security checks--obscurity of the problem doesn't make people who had their machines infected sleep better at night. There's simply a vocal minority who wishes MS would start from scratch with a sound design. If the obscurity of this problem isn't a sign that MS is pretty well lost to protect users while maintaining their quest for backwards compatibility, I don't know what will.
Eurohacker European paranoia, gun rights, and h
You mean, their goal is to make Linux as insecure as Windows?
Seriously, it would surprise the hell out of me if the Wine's team position on this was to favor compatibility over security. If that is indeed their position, then they should be keel hauled over it.
If you need web hosting, you could do worse than here
"To believe this is a backdoor, you have to believe that people thought Windows computers were going to be hooked into a giant, international, network back in 1985-1990 (and that WMF and the 8086/x86 architecture would still be relevent by the time that network came into being.)"
Exactly why I've been arguing against it being an "intentional backdoor":
The internet as a popular medium didn't yet exist, and networking meant Novell, Lantastic, or mainframes, with DOS-only workstations.
Not only that, but WMF was never a widely-used graphics format even in Win16's heyday. Even allowing for "file sharing" via BBSs, AOL, CI$, etc (themselves mainly using DOS-based, textmode interfaces), PCX was much more common, as it was far more compatible with the image-viewing apps of the day. WMFs were only routinely used by a few Win16 page-layout apps... itself a lousy vector back then, as most serious page-layout work was still done on Macs.
As to maliciously hooking into WMF's other functions, such as printing aborts... well, you've still got the problem of getting past that air-gap firewall.
In short, back when WMF was designed, first you couldn't get to the backdoor'd PC, then even if you do get there, hardly anything used WMF anyway. So how was this *useful* as a backdoor, even if it were designed that way?
~REZ~ #43301. Who'd fake being me anyway?
Yes.
If you don't, is that because you are afraid that They have put spyware in it?
That's part one of the many disadvantages of software having owners.
Is your tin-foil hat comfortable?
Yes, much more so than most commercial software. You should try it out sometimes. Here's a distribution that autoconfigures, runs from CD, has a GUI install and comes with some commercial software, like flash and acroread, as a security blanket.
Friends don't help friends install M$ junk.
Considering that WINE, an open source program, had the exact same flaw, I don't see how it would make a difference if the source was open or closed.
Now if somebody saw the flaw in WINE first, maybe you would have an argument.
You have to understand that seeing the source code is great, but not necessary to figure out what the code does. To somebody skilled in the art, a disassembler (particularly like IdaPro) creates source code -- just without all the comments and variable names.
You know all those undocumented calls that MS got in trouble for having a long time ago? Those weren't discovered by somebody with the original source code, they were discovered by somebody looking at a disassembly in a debugger.
dom
...rootkit analizes YOU.
A back door is an intentional means of accessing a computer remotely by the party that installed it. A flaw that can be remotely executed to gain access to a computer is not a backdoor. There have been lots of vulnerabilities in both Windows and UNIX services that have permitted users to execute arbitrary code. They weren't backdoors.
Steve Gibson claimed that Microsoft, or one of its employees, intentionally added this flaw to Windows for the purposes of gaining access to computers at a later point in time. That is a seriously outlandish claim, and refuting it is not semantic quibbling.
cockup:
52,800 results
conspiracy:
41,400,000 results
So it MUST be a conspiracy!
> Yeah, but let's be clear here: this wasn't obvious. If a similar bug went unseen in, say, XFree86/X.org for five years, there'd be no suggestion of a conspiracy.
It's funny that you mention this. There is a serious 0day X bug right now. All unixes and all X implemetations are affected. Must be a massive conspiracy.
Geesh, the problem is not with loading the WMF file but with breaking it into records and "playing" the individual records in the WMF file... I thought was the former and saw tests around that size thinking all was good in WINE land. I was wrong.
With regards to WMF records, it appears WINE does have the same flaw Windows has in that it only checks to see if the record size is not zero before using the invalid size to create an illegal pointer and calling PlayMetaFileRecord...
So it looks like the Wine guys also brushed over WMF structure testing just like Microsoft coders did... Now I wonder what Steve Gibsons KnockKnock.exe tested and why it said WINE didn't have the flaw.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
First, I would like to point out that the article is titled "IT: WMF Flaw not a Backdoor", which is a misnomer. It absolutely can be used as a Backdoor, and giving M$ the benefit of the doubt in its entirety does not change this fact. Did the original programmer intend it to be one? Was it intentional on the part of Bill Gates or some lower level minion? Was the NSA involved? Was the comment of Congressman Weldon in the September 28, 1999 Internet Caucus Panel Discussion related to any of this? What color underwear is Gates wearing on any given day (if any?)
As far as the WINE team duplicating the behaviour, that is their job. They absolutely cannot go around fixing security vulnerabilities in the Windows APIs, since Windows counts on those holes to function "properly." Which brings us to the assertion that they didn't notice it, so it is subtle. This is patently absurd. I suspect if the WINE team spent their time analysing Windows code and reporting potential security holes to bugtrac, they would have time to do little else. Did they notice it? Maybe. If they didn't, does that mean it is excusable that it still exists in the codebase (and was in fact found to be exploitable in Beta Vista code)? Perhaps, so long as we ignore one little aspect of this whole thing: Windows code is insecure, not because a well-intended security conscious from the ground up re-design wasn't completelt successful, but rather because the claim that this was being done was a bold faced lie. It didn't happen. It is never going to happen. Poor security in Windows exists today for the same reason it did in the Windows 3.x days, to wit: The money is in churning out code quickly and selling it to the mass of customers who simply don't know enough about how things work "under the hood" to appreciate the difference between flash and substance. This is the state of things, and will continue to be so for the foreseeable future.
And just to render as useless about half of the posts for this article, I would like to remind everyone that an attack on the character of a man, rather than a rebuttal of the substance his words, is the surest sign that a person has no valid argument or point to be made with regard to the actual issue. Are we really listening to what Gibson has to say? If you think it does, you didn't understand what was said. Does it matter who said it? Certainly, he made some mistakes, and may have been a bit overzealous in his manner and conclusion, but he did bring a lot more people the point where they thought about it enough to consider the important points: It is a Backdoor. We don't know if it was intentional, but it may well have been. If it wasn't intentional, then it is the result of gross negligence on the part of Microsoft.
Read the
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
"What else is there to say? It's a bit of legacy code left over from the days when it was safe to assume that any code on a computer had been put their with the owner's knowledge and consent. That assumption has since been invalidated by subsequent events. A backdoor it may be -- but when it was put there, there used to be a fence around the back garden. "
Great comment, and true. I remember when it was darned hard to get computers to communicate at all, and in general all ends of the link were trusted friends anyway. I'm no MS apologist, but their "features" both good and bad, made me tons of money, provided some great jobs (and good job security), and a lot of just plain fun. I found when folks complained about undocumented stuff that in general they just hadn't looked hard enough in the MSDN stuff that comes with DevStudio -- see ole storage for example for how to build a browser that will read the word format easily -- and just try to intuit that you should be looking for something spelled ShFileop to do fancy copies or moves, when every other file op begins with F. Compared to windows (here come the flames) linux is undocumented -- for the same reasons. Too many words, not enough clear explanation of motivations, too little organization, especially around versions. The MSDN dox go all the way back to the first version of MFC, for example, and are darn dangerous reading if you don't check the applicability to what you are doing. Linux has the same problem set. It's just there, it's not anybody's fault per se, and it will take a lot of very expensive work for anyone to fix up, if that's even possible. Maybe someone still needs the MFC 2.5 docs? Or Redhat 7 for that matter.
The rest of the above comment has validity too. Here, we used an old DOS version of a CAD program that was perfectly adequate for our needs -- we did PCB layout with it. Current replacement cost for Windows? Over $12 grand. Kind of a big deal in a 4 man shop. And win2k sp? broke it (by disallowing dos to do hardware things) to fix a security bug. That was the last windows we ever bought or built a machine for, right there, the end.
Well, except for a few percent of machines we need here to write and test windows apps for paying customers, we are now all linux (about 85% or all but a couple out of about 20) and that cad program runs just great on dosemu. So the desertion from Windows has already begun for just the reasons stated -- in this case there was no need to get a copy of Win9x from a Hamfest, just download ubuntu, run Automatix, and all is sweet again, and one heck of a lot more stable.
DougCoulter, owner
C-Lab
Actually he was one of the first people outside Microsoft to be granted a license to the NT source code.
Now how can MS have claimed to have done an audit, and not noticed code mixed in with a data format, especially since the ability to execute code from fonts was exposed? (nobody audits fonts, which can come in in via a .pdf)
This means other vectors, like volume controls, power save, and toggle video cards, and software eject functions are probably wide open and compromised as we speak - like sending a command or bytestring to get your video card to go into diagnostic mode where it can do raw DMA accesses. Let's hope no-one discovers similar 'oversights' the CPU bridge or the power supply api.
This is bad, and there are still fights if this is a 4 byte vector, or actual code. MS is pouring fogg over the issue. Anything that does a async re-try on error, could be at risk. If a vendor does not notice this, after such a long time, then maybe you should pick a different OS.
None of which explains why this vulnerability is absent in Win95 and ME, but present in Win2k and XP.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
To bring this back on topic, those secure functions would not have helped with this particular case. There was no "program flaw" present, it was instead a "design flaw". And flaw is even too strong a word -- weakness would be better. Given the state of the world in 1992 when it was first designed, there was no thought at all given to "malicious code" other than viruses. With Windows still being three years away from even supporting IP, the only code you executed was code you brought with you. And virus scanners watched those floppy drives like hawks. Even when Windows NT came out, there was still no real thought given to code "security."
Malware didn't reach the big time until about 1997 or 1998 when the first adware started being installed. Microsoft finally focused on security somewhere around 2001. And by then, the WMF code had gained tenure. The AbortProc() API didn't leak memory, it didn't trigger any buffer overrun tests (in isolation, anyway.) It did exactly what it was designed to do, it's just that it was designed in a safer era.
Back off topic: even as late as last year my Microsoft rep has continued to insist that Microsoft "security" comes from Microsoft innovations such as "security blankets" and "access permissions". He continued to spout the corporate line, while completely failing to recognize that Trojan horses are still the #1 vector of disaster on Microsoft boxes. What pissed me off is that he did not seem to want to understand that it wasn't about "bad people doing bad things", it has always been about "authorized people being manipulated into doing bad things." I think their training has been lacking.
John
Did Microsoft Know this BUG was present?
4 17431.aspx
Answer from Microsoft's own statement:
"The potential danger of this type of metafile record was recognized and some applications (Internet Explorer, notably) will not process any metafile record of type META_ESCAPE, the overall type of the SetAbortProc record."
Entire Statement Located here:
http://blogs.technet.com/msrc/archive/2006/01/13/
What does this mean?
It means that at some point in the past Microsoft had full knowledge that Meta-Files were capable of executing custom code when they were being rendered and displayed for "Non-Printer Errors". It took a programing effort to modify Internet Explorer to be "Sand Boxed" from Meta-Files to restrict it from executing the custom code contained in them.
So, Microsoft also knew that just the act of rendering and displaying a Meta-File, would/could execute custom code, and that the same would/could be done while displaying such Meta-Files via Explorer for example when it encountered one of these in a folder ("With or Without") thumbnail view being on.
Now, they also knew that these files could be embedded in Microsoft Office documents, in Microsoft Word, In other 3rd party applictions, viewers and WINE for example.
As They "Sand Boxed" IE from this threat ("Which they left in place") did they warn corporations, users that this BUG still was being allowed to execute custom code and could be delivered using many methods, contained in documents, via email, via downloads, via floppy, CD, DVD?
It is no longer a question that this BUG became a supported FEATURE, the question is why was it allowed to remain?
When your House is flooding, do you build a LEVY ("Sand Box IE") around your house, when you can see very clearly that the water main ("The GDI Libraries") in your front yard is spewing water?
Worse, you already know that you have made a programming effort to "Sand Box" your Browser IE, from this threat ("You Leave in Place") you also PORT it to your new Operating system Vista?
WHY? That answer we will may never know.
One suggestion is they did this to support current clients using this, the questions would be, who were they? Why were they allowed to use unsupported and undocumented features in Meta-Files, and was it worth the exposure of Millions of computers World Wide if this was the case?
Black Gray White Hats Unite to protect http://testing.OnlyTheRightAnswers.com
None of which explains why this vulnerability is absent in Win95 and ME, but present in Win2k and XP.
Let me correct that statement for you.
None of which explains why this vulnerability is absent in Win95 and ME, but present in Win2k and XP and WINE .
Much better. Now, what's the conspiracy you're positing again?
Coming soon - pyrogyra
Nice post. I think what many other posters are missing here is ... nothing is really proved yea or nay. Yeah, I read Mark's post, and I've read Gibson's stuff, and the Microsoft's claims, I'll call it a draw. They have not definitively proved this was not an intentional backdoor, even though I actually leaned this way having first read the transcript from Gibson's talk.
I think we are tripping over details, when the main points of Gibson's talk still hold. With Microsoft's proprietary, closed source code, well we really don't know what it's doing. So many independent security experts like Mark have to analyze the WINE code, not the real Microsoft code, and make their conclusions. In fact, as an aside, I believe I read somewhere that these were *not* the same bugs, as many have concluded, they are in fact similar, but slightly different.
And if you read Mark's post, he even admits he's not sure what the heck the code is there for. And this is what Gibson said - we'll probably never know, original programmer long gone.
Further, I'm real tired of the smear attacks against Gibson, with Rosenbergers lame site of a few scraggly e-mails critical of Gibson, and -- get this -- links to Microsoft. Sure, I bet Bill *hates* this guy. They'd like to throw alot more than a chair at the dude you can bet.
On the other hand, is he helping MSFT get more serious about security? You betcha. The landscape has changed, long time back. Like, wasn't WarGames early 80's? Morris worm 88? Cutler (NT architect) must've been familiar with that having worked at DEC. Puhleez don't give me that lame argument about the landscape has changed.