Title Says it all,
Stephen Toulouse writing in a Microsoft security blog has now confirmed that
the Microsoft has known about the WMF flaw for many years
Take a look
1. The Blog
2. Bugtraq Post
3. WMF Flaw Delibrate Backdoor ?
Printable View
Title Says it all,
Stephen Toulouse writing in a Microsoft security blog has now confirmed that
the Microsoft has known about the WMF flaw for many years
Take a look
1. The Blog
2. Bugtraq Post
3. WMF Flaw Delibrate Backdoor ?
Hey Hey,
Is this a joke?? Should I move it to Tech Humour?
I'm looking at your sources and you've got nothing.... The only legit source that you've quoted is Stephen Toulouse and no where in his blog does he say microsoft openly new about the flaw and left it... As he says in his blog and here (a follow up on stepto.com)
I love how this has been nothing but a constant attack on Microsoft... they responded fairly quickly (considering the testing that must go into a patch) and got a fix out...Quote:
WMF and RTS games on Xbox360
Wow thanks for all the great feedback on the MSRC blog entry. I'm glad people liked the detail and history on the issue. Again special thanks to the SWI guys, as well as Raymend Chen, and Larry Osterman for the historical context and nitty gritty technical detail.
WMF is a different issue than the normal "coding flaw". And I think that's what people are latching onto, it's a software feature being used in an unintended way, giving rise to the attack vector. This happens from time to time and it's much harder to catch than code that uses unsafe functions or trusts that no one will try to abuse an input buffer. In a way, it reminds me of the user:password issue we ran into with Internet Explorer, where people were exploiting that functionality to fool web users into visiting malicious sites. There, as we have before, we deprecated unsafe functionality.
And because I think, of the breadth of the code base (where we're looking at Windows 9x which is one set of code, and Windows NT/2000/XP, which is actually three sets of code, but all four intermingle code) each OS handles it in different ways. You get oddities like 9x not processing the SetAbortProc record and not having an application by default that opens a path to the vuln.
Believe me if we could go back in time and prevent the vulnerability from occuring, we would have. But of course, that's true of any vulnerability, whether it's based off of functionality that we didn't see could be misused or based off of a coding flaw. In this case it was just old design. With 20/20 hindsight, it was bad design. People may say "this shouldn't have been missed! It's unbelievable to me that this was missed!" My reply back to that is "You're right. Nothing should ever be missed, ever. But software authors are human." It's not the perfect world we would like it to be. Hindsight is 20/20 as I already mentioned, and we have moved to correct the problem.
So how then did this get missed? Well again a lot of our focus has been on restricting the use of unsafe functions and making sure coding flaws or unsafe practices don't creep into the code, and addressing areas where it already exists. There's been a ton of progress there. But we do have our SDL process. And that process is an ever evolving one. So we're making changes to it to try and catch these instances. We do a root cause analysis on all vulnerabilities to understand the problem, learn from it, and correct it.
Anyways, again I appreciate the feedback on the post.
Did you even read Stephen's blog??? or did you just take the random posting of someone on BugTraq that he confirmed it... because it definately wasn't confirmed.
He stated that yes they knew there were some problems with running it
However there's potential danger in everything that goes on with computers... People want everything to work and to work nicely... Which is why you run into things like Administrator accounts being used daily, and so on...Quote:
The vulnerability was introduced when all that GDI functionality was allowed to be called from metafiles. 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.
Consider how many lines of code are involved in any Operating System.. it's impossible to find every little problem... If you spent that long the OS would be out dated and something new would have to be developed... People are innovative.. they'll find ways to abuse trusts, and purposely break things if they want to... no matter how much code auditing you do...
I don't think Microsoft knew the specifics of what would happen with the metafile records... and no one has come up with something before now.. and considering how long it's existed it's odd that no one has found a way to previously use this... unless... it wasn't obvious.. which is my opinion...
You didn't even start a discussion here.. you quoted a random post, Steve Gibson (who isn't worth the **** he leaves in the toilet bowl every morning) and a blog posting that I suspect you either didn't read or didn't fully understand...
It wasn't a critical vuln on 98/ME...It's just the movement of old code forward... sometimes people get sloppy and reuse stuff that has previously been without problem.... Well with newer functionality in the rest of the code... 1 + 1 = broken... that's what happened here.. it was the incorporation of metafile records with the ability to natively process them that caused it to be exploited in this manor..
Peace,
HT
Hey HTRegz is it my fault that microsoft code has bugs ?
From Blog
Shouldn't microsoft have fixed it but no their policy is hey it compiles ship it!.Quote:
This was a different time in the security landscape and these metafile records were all completely trusted by the OS.
Its high time they became a little (at least a lilttle) more concious about their OS security.
Also your reaction was very rude, i know you are some great *windows* guru so it does
not mean you bull**** others.