Hm ok, sorry it took me a while to follow up on this, but here goes. Why do I distrust UDP for security-sensitive applications?
- UDP is easily spoofable. It is easier to spoof UDP packets with successful malicious results than to do the same with TCP. As Matthew pointed out, UDP is just a light wrapper of IP. Therefore UDP inherits all of IP's lack of security. Granted, TCP is also vulnerable to a wide range of things, including session hijacking and various forms of denial of service but to successfully exploit these, the attacker has to mess with the TCP state machine which is a bit more complicated than just being able to send spoofed UDP packets. - UDP is unreliable and connectionless This facilitates (in the absence of higher layer logic to deal with it) the presence of idempotent attack attempts. The connectionless nature also leads to an often overlooked need for authorization of specific operations (transactions?) rather than just endpoint/user authentication. - UDP broadcast/multicast capabilities These are often overlooked and provide a one-to-many attack vector if a vulnerability is discovered in the application. Some examples: DCE/RPC over UDP transport, the recent vulnerabilities in Asterisk IAX2 protocol, etc. - Usually, use of UDP makes your application "firewall unfriendly". Most firewalls (all?) implement stateful inspection/filtering these days. For than the firewall can rely on a set of features of TCP itself (the state machine, ACK/seq numbers, etc). Int he case of UDP, a filtering firewall will only have the source and destination port fields data usable to track state (which are easily guessable or brute forceable 16bit values). To make you application firewall-friendly you'll require the firewall to understand and process higher layer protocols. - Lack of reliable, ordered delivery makes implementation of encryption tricky and error-prone. All of the above can be addressed by designing and implementing your overlay protocols carefully, but in general that does not happen and if it does the overhead is such that it makes you think why didn't you start on top of TCP anyway? And that is why I say using UDP should be evaluated carefully to determine how much work is needed to use it securely and how much work are you willing to dedicate to it. Lack of a fixed congestion control mechanisms and a purposeful firewall unfriendliness are usually the real features you end up valuing in lieu of TCP. Application developers usually end up implementing their own overlay layers with states machines, session control, encryption, reliability, order delivery,etc. with poorly designed protocols and shaky foundations or do not do it at all. Some bad examples to look at: DNS, SNMP, ONC RPC, DCE RPC, DHCP, RTP, NTP... -ivan Matthew Kaufman wrote: > Zooko O'Whielacronx: >> Programmers who use UDP almost always implement some subset >> of TCP's features, such as retrying, ordering, fragmentation, >> congestion avoidance, etc.. > > Experience here shows that actually most programmers who use UDP implement > approximately none of the above. See, for instance, RTP for VoIP... Doesn't > even have congestion avoidance, which it really should. > >> This code they write to >> implement these features is likely to contain bugs, and is by >> definition network facing and handling data sent by unknown agents. > > Same with any TCP-using protocol. See the recent "Cseq field has > 24 bytes" > buffer overflow of a popular SIP stack for instance, or all the way back to > the first "fingerd" bugs and sendmail bugs (exploited by the Morris worm, > even). > > Matthew Kaufman > [EMAIL PROTECTED] > http://www.amicima.com > > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > -- --- "Buy the ticket, take the ride" -HST Ivan Arce CTO CORE SECURITY TECHNOLOGIES http://www.coresecurity.com PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
