MS08-067

You should have already heard about this out of band patch ,released by Microsoft. There are many points,failurs,good and bad news about this case . Everyone has his own story about this case worth writing a complete post ,article or analysis report and it`s still on going . I`ll try to sum them all in this post.

At first , we had MS08-067 patch from Microsoft . A critical vulnerability in Server Service that allows remote code-execution on ALL microsoft platforms. great!

The truth is that Microsoft`s patch was not really the begining of this story . This is one of those vulnerabilities microsoft got in wild , being used in targetted attacks against fully patched Windows XP/2003 systems . Unlike what many people have mentioned , detected in-wild use is not really a true worm . Targetted attacks happened through a trojan , which has been armed with an extra module to exploit this vulnerability and spread . Here you can read some details about catched case. That`s how we`ve got the buletin.

Now some details about who`s vulnerable and who`s not . Here comes most of bad news . ALL versions of windows (2000 / XP sp1~3 / 2003 sp0~2 / Vista / 2008) are vulnerable to this. The only difference is about Vista and windows server 2008 . These two platforms are less affected and that`s because vulnerable RPC endpoint is only accessible to authenticated users. In 2000/xp/2003 it`s possible to access and exploit the vector anonymously without any authention required.
On Vista & 2008 /GS and ASLR comes handy and make the situation _harder_ to attacker, for exploiting this bug . Since this is stack-overflow thing and there are many geeks out there already using techniques to bypass these , while Microsoft use "Likely DoS condition" term you shouldn`t have any doubt about possibility of successful code-execution on these platforms.
The authentication limitation on Vista/2008 shouldn`t either fool you. This may prevent mass attacks orginated by worms but if you`ve got a windows domain where your systems are placed in , attackers have already got some passwords to do a clean 'authenticated' compromise.
Finally, we have detault windows firewall rules ahead . Windows XP SP2 have it enabled by default and systems are protected from the interface windows consider it 'public' . BUT windows have file and print sharing EXCLUDED by default for 'Lan' interfaced which means no protection.
This table will give you idea about your current state ,based on your platform and configurations . Here`s related post on Microsoft security response blog about the case .

And if you`re digging for exploits , yes there are already some exploits available thorough some commercial services. Kostya of Immunity seems to be fighting with non-executable pages at the moment :) . With all of those protections around stack , it looks a complex case to solve on latest versions of windows.

Now Let`s look at the case from another point of view:
[Why this vulnerability has not been spotted before ?]

This is the question I was asking myself since the time I understood technical details behind it. Most odd and interesting point was that this bug is on the same service that has already been covered back in 2006 with MS06-040 . As Alex Sotirov mentioned in his blog post here , the vulnerability is even in same code area as ms06-040 ! He has de-compiled vulnerable function and mentioned what caused the overflow to happen . As it`s demistrified , you can see a complex loop for parsing supplied variables , one of them being a path.

This wasn`t enough for me though. After all of past hype on MS-RPC fuzzing and LOTS OF discussions about it in lists, books, fuzzers, conts, etc... in last months of 2008 we still have such a case . My first attempt was asking some of those who`re believed to be masters in this field , but later I came across a post by Michael Hovard, the SDL guy of Microsoft. In his blog post he answered why this bug was under radar all of these times. Not their manual code audits , nor their automated static analysis tools neither their fuzzing methodologies found this !
He has clearly discussed the case and why they faced with this total failur . I recommend you read the 'code analysis and review' section in his post to get most of what you want. While his statements about complexity of code segment and why it`s hard to spot the bug in code-review (manual or automated) I was really disappointed about the fuzzing topic . I think Dave Aitel should have something to say about this :)

Before reading Michael Hovards post , I had three questions about this case . His post answered only one of them, related to SDL . But two remainings are :
*What`s the real story behind MS08-067 ? Is it about lack of effectivenes in current MS-RPC fuzzing techniques (As we`ve read multiple times that MS-RPS has been fuzzed to death!) or it`s the story of effective warez getting leaked one a while ?