On Thu, Jun 23, 2005 at 05:57:05AM -0400, Todd Underwood wrote:
my understanding is that md5 is still checked before the ttl-hack check takes place on cisco (and perhaps most router platforms). new attack vector for less security than you had before. oh well. ras: can you confirm that it is possible to implement ttl-hack and have it check *before* md5 signature checks?
The TTL hack itself (this is the one where your neighbor sets their outbound TTL to 255 and then you can drop the packet if it has a TTL less than 254, in case anyone wasn't paying attention) can be implemented on the data plane in the receive/loopback hardware based filters before any TCP processing happens or the packet ever gets near the management cpu, since it is an IP-specific check. The only thing that the TTL hack guarantees is that the packet hasn't traveled over any routed network to get to you, so for example you could still get hit by directly connected networks (across a public exchange with malicious or compromised participants, for example). This is different from the issue of whether the sequence number is checked before the MD5 signature. Remember the entire point of this attack was that some bright person "realized" that with most people having a default TCP window size of 16384 (btw I'm told that this isn't necessarily the case, and that at least some vendors are lowering their socket buffers on the BGP specific sockets for other unrelated reasons) or 2^14 you only need to try 2^18 combinations per ephemeral port and bgp port pair instead of 2^32, times the number of ephemeral ports you must test, times 2 to handle BGP collision detection which may set the session up in either direction. You still have to throw a couple billion packets at the victim and hope for a match, and only after you get this match do you need to proceed to the next step of validation on the one packet that managed to get through. If you are doing MD5 validation on every packet that comes in before you check the other criteria like sequence number, you are opening yourself up to a very easy DoS by anyone who wants to throw junk MD5 signed packets at you.
the chaos (and crappy quality of the implementations) during the panic demonstrates two other things: rolling out magic code because your vendor tells you to is a bad idea; slapping together a hack on top of a well-designed protocol without careful thought and testing is a terrible idea.
This wasn't the first or last time the vendors have told us we must upgrade immediately to some buggy new code because of some secret reason they can't disclose without killing us afterwards, only to find out it was a dud issue we wouldn't have cared about if we had been given technical details beforehand. While I suppose this is slightly better than them putting out a press release 24 hours after the discovery with everything but some example exploit code that compiles on linux, I think the point that we're all trying to make is that we'd like the vendors to find the happy middle ground between stupidity and paranoia. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)