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