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.

This is the most detailed description I could find - http://blogs.technet.com/srd/archive/2009/09/08/ms09-048-tcp...

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.

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.

Whenever I see a bug this serious I always wonder if it's been floating around in the wild all this time.

Of course. I doubt they just introduced it, considering it affects operating systems stretching back a decade.

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 wasn't referring to security researchers. I'd be more interested in someone sitting on it as a zero day.

Does the vulnerability stretch back into any of the BSDs it was forked from? :)

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.

Actually unlike the previous TCP/IP stack I believe the Vista/Win7/Serv2008 stack is new from the ground-up.

They rewrote it so carefully that they duplicated the same teardrop bug they created back in windows 3.1/95 and didn't fix for half a decade.

Now that is almost mean.

As FreeBSD Security Officer I don't see anything unreasonable about that question -- it's the first thing which occurred to me, too.

But seriously--if this bug was in BSD, wouldn't we know it already?

Not necessarily. Just a few months ago I fixed a serious vulnerability in FreeBSD which had escaped notice for over 13 years.

Note how XP does not have this particular vulnerability.

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.

I thought that was the title of all Windows hotfixes.

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++.

I wonder if this particular vulnerability can be stopped by a firewall.

If it's IP timestamps, then certainly yes --- your firewall should be blocking this by default.

PF can do it:

scrub in all reassemble tcp

http://www.openbsd.org/faq/pf/scrub.html

So what? MS found a security bug. Lets look on linux forms about all the security exploits fixed here and there.

MS fixed a critical bug. Yay. Why complain? Its better than Apple ignoring security bugs for years :)

Remote code execution vulnerabilities on widely-used systems is generally noteworthy.

who said anything about complaining?

Yes, this is basically "update as usual". The bugs one should be concerned about is the ones that are public, but does not have any patches.