Moving at the speed of frozen molasses
Another day, another catastrophic remote exploit of Windows. The vulnerability affects the way Microsoft’s code processes icons. Yes, icons. Never mind, the story of its fix is telling enough:
Microsoft was first alerted to the .ANI vulnerability back in December, but a patch for it didn’t come before exploits began hitting the wild last week.
Ouch, that’s a long lead-time for what, hopefully, is a relatively simple buffer-overflow attack, and therefore one that shouldn’t take 3 months to resolve. Not that other vendors don’t take similarly absurd lengths of time.
Mark Miller, director of the Microsoft Security Response Center, said in an interview Monday with InformationWeek that the company needed the three-plus months to work on building and testing a good patch. Since the exploit hit last week, he said slightly less than 100 Microsoft technicians have been working “around the clock” to ready the patch.
So let’s say they had 99 Microsoft technicians1 working 24×7, which is the meaning of “around the clock” to most people, for one week. That represents 16,632 hours of work… to fix a buffer overflow? Seriously, either this is a total fabrication (a “lie” in general English parlance), or they really are as pathetic as Linux weenies would make them out to be2. The last buffer overflow I had to fix3 took a couple hours to isolate (gdb), write a test to reproduce and fix.
Miller stands behind Microsoft’s response process and said it has taken the company more than three months to come up with a patch for the bug because it’s simply a long, complicated process.
Have they investigated not using this process, and perhaps investigating something that doesn’t suck so completely at delivering results? Then again, Vista was years behind schedule, and ended up delivering effectively nothing that was promised, so I shouldn’t be surprised.
“It just took the time it took to produce this update,” he said. “When you look at the time it takes to review the security issues, create a fix, and then test, it does take some time. ... Where it is in Windows, it is a core area. The time line is longer because you have to deal with this core area.”
Aye matey, thar be monsters in the core!
1 Technicians? Have they tried hiring programmers, rather than cable TV installers to write their code?
2 This is my standard conundrum: “Are you an idiot, or just lying?” I’m not sure which is more troubling.
3 One of the advantages of writing in dynamic languages is that these sorts of bugs are effectively impossible.
This entry was posted at 6:21 pm on 2 April 2007 and is filed under Security. You can follow any responses to this entry through the post-specific RSS 2.0 feed.
Not to defend the long lead time, which I think is way over what is acceptable, but they do have a huge test matrix to cover.
“Are you an idiot, or just lying?†I’m not sure which is more troubling.
How about both? An idiotic liar.
It’s not so much dynamic languages that prevent buffer overflows, but languages that don’t permit unrestricted access to memory and do (gasp!) bounds checking on array accesses.
Tony Hoare on implementing Algol 60 (in 1961)
”(1) The first principle was security: ...
A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array.
Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to – they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous.”
You can leave a response, or trackback from your own site.
[...] Read more… Tags: ani, catastrophic, exploits, microsoft, molasses, remote exploit, vulnerability Posted on Tuesday, April 3rd, 2007 at 4:48 pm and under category News. You can read any responses through the RSS 2.0 feed. You can give a response, or trackback from your site. « Pete Finnigan’s Oracle security weblog – Bunker has released a 0-day Oracle exploit Health Information Privacy and Security Week » [...]