Redmond security guru explains IE vuln miss A Microsoft insider has posted an explanation for the firm's failure to spot a critical flaw in Internet Explorer that obliged the firm to publish an out-of-sequence patch earlier this month. Michael Howard, a principal security program manager with the software giant, explains that the flaw cropped up in a blind-spot …
Another site with the story has fuller details and includes pseudo-code of the bug
int MaxIdx = ArrayOfObjectsFromIE.Size()-1;
for (int i=0; i <= MaxIdx; i++) {
if (!ArrayOfObjectsFromIE[i])
continue;
ArrayOfObjectsFromIE[i]->TransferFromSource();
...
}
http://mobile.securityratty.com/article/622c51159caa8b94b23fe6e180f94f78
Basically, if I understand it correctly, other threads could update the array being used in the loop so that MaxIdx wasn't necessarily valid for the duration of the loop. For all the throwing of acronyms around it still comes down to the programmer(s) not fully understanding the environment they are coding in.
F**K me! One thing you never ever do, is change the variables related to a loop construct whilst it's executing. I learned this when I was 16 years old at school in my computer studies O'level.
And you certainly don't allow threads to interfere with other variables unless you've got some sort of gating mechanisms in place such as semaphores.
This is just p**s poor bad design. Where's the design diagrams and documentation showing how threads interact with each other?
Looks like they haven't properly defined or documented the interfaces between program elements/modules.
Yes, it is a difficult thing to identify with a test tool, but this comes back to poor design and poor design documentation, either that or the developer didn't read the design documentation fully.
I thought Microsoft developers and designers were supposed to be better than this?
Call it what they will, it is still bad practice, and the fault of the developer (out of ignorance, as Tim Brown suggests) not checking the environment properly. Giving it a spiffy sounding name and acronym only legitimizes the practice as a common issue within the environment, when in fact it's just incompentence.
It's like giving a fancy name to, say, forgetting to remove one from the full count of items in an array, when iterating from zero:
for (int i = 0; i <= myArray.Size(); i++)
myArray[i]->foo(); // will point to hell when i = Size
It is not an issue inherent in the platform, language, or framework; it is not something that we must "warn against", as if it were some abstract creeping evil lurking in the shadows of the machine. A competent developer understands the boundaries of the arrays with which he is working, and set his control variables accordingly.
But just for the hell of it, let's give it a cutesy name: Final-Out-Of-Band-Array-Register. Remember kids, watch out for those nasty FOOBAR's, they just sneak up on you like the dickens!
-dZ.
That's "Typical MS Doublespeak Clouded With Useless Acronyms" if you weren't familiar with that one.
Thanks Tim. In their normal style MS managed to turn a nice simple issue into a mess of acronym laden double speak. How many times have you read one of their 5 page KB articles and been scratching your head only to google up a three sentence summary that actually makes sense and tells you how to solve the problem (after a reboot of course). I've learned MS is the last place where you want to seek help on MS products.
The armchair coders are out in force. Wow, you guys must all be really shit-hot.
@Eddie Johnson: Microsoft's KB and MSDN are fantastic, I don't do Windows development any more but I wish the docs for what I do code for now were of the same quality. It definitely beats man-pages anyway
@DZJay and Tim Brown: Developers come and go, chances are this code was written years ago, by a developer who has left, before everybody did fancy UML diagrams (which are largely useless anyway with the exception of sequence diagrams). There is bad code everywhere... I know there is bad code is some frameworks I work with, but it's not that easy to just go fix stuff. Just ask your manager, and product owners and customers.
@Rotacyclic: You've never written software in a commercial environment have you? (and doing web pages doesn't count)
I remember years ago scratching my head over some Data Access Objects code I had written, checked, rechecked that I was using the methods correctly as stated in the documentation, still couldn't get the bloody code to work properly..only one conclusion left..the MS documentation on the objects was wrong...and it was.
That's all I needed, I expected my code to be wrong, I didn't expect the objects not to work properly, and I didn't expect the f***ng documentation for the software developers to be wrong either!
So I concluded that there are two independent teams ( not unreasonably so): the software development teams constructing the objects and the documentation team which are given a requirements document of what the objects should do, the documentation team write their docs and there's no amalgamation of the two at the end to update the documentation to reflect reality.
How the f**k can you get the developer's documentation wrong? That was I think my realisation that Microsoft - despite being the largest software developer in the world - just can't get the basics right.
Then I recalled back to something a former manager of mine had said to me in a previous company, when estimating project timescales, calculate how long you think it should take and then double it because you're dealing with Microsoft. He wasn't wrong.
@James,
Wow, I'd hate to work on the same projects you have if this sort of thing is so commonplace. In my experience, as stated, this is just bad design and poor understanding of the system in which the developer was working.
The possibility that a developer left the company and now everybody else is stuck with a mess of abstruse code, does not excuse it; and in fact it says much about the development and documentation practices of the organization: again, bad design and incompetence.
This may be very common in some places, but trust me when I say that it is definitely not an inherent aspect of software development, and it does not occur everywhere as a rule.
-dZ.
To Tim Brown, RotaCyclic and others - reading the Howard's post, this is not a threading issue.
It is reentrancy bug - the external code called inside the loop (probably one of the TransferFromSource() calls) can update the array, invalidating the local variable.
It is reentrancy on the same thread, not multithreading - so no semaphores (or OS/2 knowledge :)) would help here.
That's their security GURU????
That really explains why MS really know jack about security and their internal testing tools are worth jack too (by their own admission)
@In fairness....
I'd expect a company who has the biggest market share on the desktop out there to have sophisticated test tools - fuzzing and otherwise. Clearly security isn't very high on the Agenda at M$
This is simple to understand - MS doesn't know what it is doing, simple really. This practice is rather common. The underline problem:
1. The design team doesn't fully understand what they want. They gave a fuzzy outline and objectives, without giving all the requirements to the team do the coding.
2. The coders don't know what they are doing. They may do their best based on what they understood of the partial requirement. Plus some of those so called "developers" really cannot code anything there days.
3. There is no/little documentation, and the test team doesn't really test properly.
To "fix" the problem, the design/review team must know what they want and what they look for. This requires the team to understand the technology, environment, and the will to do some work, rather than sit there and saying "I want these, these and that, now write it".
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
