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
