Full Disclosure: Re: Microsoft Windows vulnerability in TCP/IP Could Allow Remote Code Execution (2588516):

Dan Rosenberg wrote
“People seem incredulous that the bug can be triggered by sending traffic to closed ports. Keep in mind that the only way your networking stack knows to reject packets that are directed towards closed ports is to do some preliminary parsing of those packets, namely allocating some control structures, receiving at least the physical/link layer frame, IP header, and transport layer header, and parsing out the port and destination address. There’s plenty of things that can go wrong before the kernel decides “this is for a port that’s not open” and drops it, which appears to be what happened here. Doesn’t make the bug any less terrible, but it’s not quite as surprising as people seem to think”

“While I’d love to see an exploit from a purely academic perspective, it doesn’t appear that this is the type of bug where exploitation is going to be reliable enough to support a worm. The reference counter in question is most likely 32 bits, but even giving the benefit of the doubt and saying it’s a 16-bit refcount, that’s still 2^16 events (probably receiving a certain UDP packet) that need to be triggered precisely in order to cause a refcount overflow and then trigger a remote kernel use-after-free condition, which wouldn’t be trivial to exploit even by itself. On an unreliable network like the Internet, it seems unlikely that the kind of traffic volume required to trigger this bug could be generated without dropping a single packet. Reliable DoS seems more likely though.”


Comments are closed.