(In reply to Samy Kamkar from comment #5)
- Please note the SIP overloading the MTU is just one example but there are other ALGs that do not require multiple packets and can be a single line in the middle of a packet with arbitrary data on either end, IRC DCC is an example of this.
Just to be extra clear here: if I'm not mistaken the attacks can work with any protocol which opens additional network ports, correct?
So we are talking about SIP, H323, PPTP, RTSP, IRC. Blocking the default destination ports for these protocols for TURN makes sense as the TURN username and password allow the JS to set the outgoing content.
- I'd suggest doing it for UDP for any protocols that specifically support UDP such as DNS (UDP 53) and SIP (UDP 5060/5061).
I don't fully agree here. Yes blocking the SIP ports for TURN makes sense. Blocking DNS does not make much sense to me as I'm not aware of the DNS protocol containing any other port number, which would result in ALGs opening ports on their public side.
- Ben and Greg may have more thoughts. It seems unlikely to be an issue due to the avalanche effect of modern ciphers, but I would suggest blocking the ports if possible regardless as it's a small number of ports and avoids this potentially being revisited, especially if an attacker in the future can control other portions of the cryptographic headers. Another unlikely but potential future attack would be if there's ever a mechanism for the client to recover the AES/symmetric key used or to explicitly set the key, in the case of something like AES-ECB being used, the attacker could align the username portion of the packet to block size boundary, prepare and "decrypt" their ALG attack data (which will really just produce encrypted data), then include that encrypted data at the boundary. The TURNS/STUNS would then "encrypt" the data, in reality reversing the encryption and leaving the decrypted data in the packet while the rest is encrypted and triggering the vulnerability. Again, unlikely, but it's those unlikely things that are the most fun to investigate :)
I agree with Byron here that blocking encrypted protocols doesn't make that much sense to me. But maybe we should talk to our crypto expert about this.
- I would highly suggest blocking known ALG ports (for their relevant protocol of TCP or UDP) for all outbound socket mechanisms unless explicitly required, for example allowing TCP 21 for ftp:// URIs, while blocking it everywhere else.
In my opinion that whole approach of blocking ports is very limited on one hand and a little bit dangerous on the other.
At least most of the modern service also can be executed on non-default ports. And if the ALGs try to be/become smart about these as well there isn't much we can do about it.
Similarly if there are ALGs which simply look for pieces of known protocols in any packet they pass along there isn't anything we can do about that either.
The reason why I'm not in favor of blocking every outgoing connection is that I'm not aware of any way for the JS to control the content of outgoing STUN packets (binding requests etc) if they are not TURN. JS can control the destination of these requests via the ICE candidates, but not the content as out implementation chooses username and password.
So if I'm not mistaken long term credentials also only apply to the usage of TURN.