RSSApparent IP routing vulnerability affects Vista, not XP
By Scott M. Fulton, III | Published November 24, 2008, 1:28 PM
A change in the way the Windows client enables IP routes to be amended manually is the target of a potentially serious exploit for Vista users only, that Microsoft may now have no choice but to address.
Through SecurityFocus.com last Wednesday, a team of researchers at Phion published a proof of concept that demonstrates how Microsoft's Internet Protocol Helper API could be exploited to trigger a stack buffer overflow, potentially leading to the execution of random code. Unusually, this particular exploit can only be recreated, Phion said in its bulletin, on Windows Vista Enterprise and Ultimate versions, in 32- and 64-bit editions.
The Phion bulletin explicitly says that Windows XP, which also utilizes this API library, is not affected by this problem. The library in question has been in existence since Windows NT 4.0 Service Pack 4, and has been a regular component of successive versions since Windows 98.
Windows Vista was the first client operating system from Microsoft to support IPv6 protocol as a standard feature, although IPv6 remains an option for XP and older clients. It's that distinction which leads to the Vista-specificity of this issue. The IP Helper API gives developers more direct access to the functions necessary for a Windows computer to utilize IP. So naturally, one of the functions included enables a program to establish an IP route for the local computer, and the original form of that function was called CreateIpForwardEntry.
Since the introduction of IPv6 as standard issue, the library had to offer an alternative way to phrase the forward route entry, though it had to also leave the earlier version of the function for backward compatibility. Thus the creation of CreateIpForwardEntry2, an API function that is only workable in Vista. An XP or older client would never make use of it, presumably even with IPv6 intentionally installed.
Thus the situation where the route add command, as Phion illustrated, can be gamed in such a way that it triggers a buffer overflow in Vista but not in XP. Evidently the command utilizes the older API function in XP, and the newer one in Vista.
Phion says it reported the vulnerability to Microsoft on October 22. But apparently since it did not provide a fix for it in its last Patch Tuesday round, the security firm decided to release its own hotfix, which it claims replaces the Vista library that contains the newer API function with one of its own. It's unlikely that Phion had any authorization to be releasing code that contains Microsoft property on its own, and thus far, Microsoft has not commented.
No verifiable source has yet produced evidence of an active exploit for this vulnerability in the wild. Phion did say that the exploit only works when the route add command has the appropriate administrative privilege, which in and of itself may require either another exploit or a social engineering trick.
By the time they get to windows 15 in 2025 this all should be fixed with no more problems, ya right... :)
Score: 0
|Mac time?
Score: 0
|Can someone post a link to the patch download?
Score: 0
|You want to patch it incase you have a sudden bout of idiocy?
Score: 0
|i wouldn't patch from a third party, unless something entirely f*cked up was going on... this is one way to screw windows up... like say your next service pack install.
this is why windows gets a bad rap, because of users like yourself.
Score: 0
|Yup, the fundamental flaw allowing the exploit is not Windows' fault, folks!
Its just the fault of the stupid people who use it...
That's almost equivalent to saying that its not Windows' fault for leaving the window (hey, a pun!) open, its the fault of the mean individuals who climb in and exploit the vulnerability...
What a cast: Windows with a flaw, stupid users, and mean people who exploit poor vulnerable Windows.
Next we will be reading that Windows is a victim!
ROFLMAO!
Score: 0
|I wrote an exploit a long time ago for {INSERT OS HERE}, but it required that the user be logged in as root and that they explicitly run it. (Your basic social engineering on an escalated account)
They never fixed that vulnerability. I can only assume the folks behind {INSERT OS HERE} don't want their users to be secure.
Obviously, no OS should allow escalated privileges, nor allow users who can be duped into running applications to access the machine. ;)
Score: 0
|To the author of the above comment... How is that an exploit? Root can do just about anything so how running your harmful executable as root constitutes a pat on the back for writing an exploit is not obvious to me.
Score: 0
|My point exactly.
Now look at what is required to get this "exploit" in the article. Then compare it to mine.
Perhaps it's just easier to see the absurdity of my example because I didn't pad it into a full-page article. ;)
Score: 0
|Yes and no.
Root in UNIX can.
'Root'/Admin in Windows cannot as while there is a superuser named Administrator, it is not an exact equivalent of the Unix root superuser. Administrator does not have all the privileges of root because some superuser privileges are assigned to the Local System and cannot control System processes.
Gotta love Windows...
Score: 0
|A flaw that requires administrator access to exploit... must be a slow news day
Score: 0
|folks are so hard up to find something wrong with vista now they are just making stuff up? lol
Score: 0
|Like some do with their religion??
Score: 0
|"No verifiable source has yet produced evidence of an active exploit for this vulnerability in the wild. Phion did say that the exploit only works when the route add command has the appropriate administrative privilege, which in and of itself may require either another exploit or a social engineering trick."
Riiiiiight.
So that's going to the top of Microsoft's fixing pile then.
/sarcasm
Score: 0
|lol.
Score: 0
|