- From: Matthew Kaufman <matthew@matthew.at>
- Date: Wed, 23 Mar 2011 17:21:31 -0700
On 3/23/2011 3:57 PM, Harald Alvestrand wrote: > > I don't think such an attack is possible; there is no mechanism in ICE > for changing the destination IP address without a new handshake. > > The potential attack we can't avoid is that a hostile webapp, possibly > with the help of a hostile STUN server, can cause an ICE handshake > request to be sent to an UDP IP+port of their choice. The browser can > rate-limit such attacks easily, and may implement a port-number > blocklist if that seems appropriate (not sending to port 53 seems > reasonable). Exactly. The browser prevents media and data traffic from being sent to an address+port unless that address+port has recently answered a STUN connectivity check (which itself requires shared credentials between the sending browser and the target in order to succeed). The browser rate-limits these requests. STUN connectivity check packets are already carefully crafted (with a very long initial magic number) to *not* look like anything else (SNMP queries, DNS queries, etc.) and so sending them at a limited rate to arbitrary addresses should be safe. > > That seems like a risk that's not unreasonable to accept, given that > we've survived having the same problem for HTTP links since day one of > the Web (any web page can dupe a client into launching a TCP session > to any IP:port and sending "GET /<ASCII string of their choice>" to it). Agree, and this is even safer because it doesn't burn up TCP state at the target. Matthew Kaufman
Received on Wednesday, 23 March 2011 17:21:31 UTC