Well, actually no, not a decade. Remote execution vulnerability was clearly introduced in Vista, most likely due to the much touted network stack rewrite.
I reallllllllly want to know if the TCP/IP Timestamp Options vulnerability --- the one where they keep a stale function pointer in memory that winds up controlled by an attacker --- refers to the IP Timestamps Option or the TCP Timestamp Option.
The IP Timestamp Option is more likely --- it's crazy complicated (among other things, you can play tricks with IP timestamps to determine whether two IP addresses are virtually hosted on the same machine). The good news about IP Timestamps is your router probably doesn't pass packets that have that option set.
There is a good chance that they just put the pointer itself in a timestamp field, presumably allowing the responder to tweak it to point at something else.
My read of the advisory was that it's a memory lifecycle issue --- having to do, as the advisory said, with not cleaning up state properly. Which, come to think about it, suggests that it's TCP timestamps --- IP timestamps are stateless.
An FYI, if you guys care about more passive attacks that let you deduce the source of NAT'ed packets and other tricks, check out "Silence on the Wire" by Zaelwski. Awesome read.
Good question -- but I have to say "almost certainly not", for two reasons.
First, I haven't had any email from Microsoft about this -- and for all that Microsoft has a reputation for being bad at security and not supporting open source software, they do take their responsibilities seriously when it comes to inter-vendor coordination.
Second, the details I've seen relating to this suggest that it relates to connection hashing -- which is relatively new, and thus is unlikely to involve code from the BSD stack which Microsoft imported so many years ago.
XP is affected by this but XP is not vulnerable in the default configuration because there is no service listening set up with the firewall by default and the firewall is on by default. I am curious to see if this causes problems for Microsoft down the road.
You know, I just don't get it, Microsoft is reputed to hire pretty smart people, but somehow this slips through? This is on the border of professionally negligent. I can see if my foomatic open source project allows someone to run remote code (hell, even IIS or maybe apache for that matter), but the TCPIP stack itself? sheesh....
It's hard to find this sort of thing statically in C code, especially if your static analysis tool is configured to treat C typecasts as necessarily correct because there's no syntax in C for expressing how dangerous a cast you intended, unlike C++. Of course, I don't know whether this code is C or C++.
29 comments
[ 4.0 ms ] story [ 73.3 ms ] threadThe IP Timestamp Option is more likely --- it's crazy complicated (among other things, you can play tricks with IP timestamps to determine whether two IP addresses are virtually hosted on the same machine). The good news about IP Timestamps is your router probably doesn't pass packets that have that option set.
First, I haven't had any email from Microsoft about this -- and for all that Microsoft has a reputation for being bad at security and not supporting open source software, they do take their responsibilities seriously when it comes to inter-vendor coordination.
Second, the details I've seen relating to this suggest that it relates to connection hashing -- which is relatively new, and thus is unlikely to involve code from the BSD stack which Microsoft imported so many years ago.
scrub in all reassemble tcp
http://www.openbsd.org/faq/pf/scrub.html
MS fixed a critical bug. Yay. Why complain? Its better than Apple ignoring security bugs for years :)