On Wed, Aug 22, 2001 at 12:02:08AM +0200, Fabian Melzow wrote: As a member of the netfilter core team, I'm writing this statement to present our point of view and hopefully clearify the issue. > An improper use of the experimental netfilter MIRROR target, > can be used to launch a DoS attack against two host, which > mirror the same protocol on min. one port. > > An attacker can spoof packet?s, with this mirrored ports as source and > destination and an high TTL, 255 for example. > > These packet?s are then mirrored on each side, until the TTL reached zero. > In a LAN without a router there packet?s will never expire. > > We tried this attack over the Internet with one packet, where a TTL of 255 > was set, between Germany and Austria, with the result, that these packet was > 30 times wrapped around. So where is this behaviour any different from what you would expect when using the MIRROR target? > Evil minds can use this attack to crash these hosts or eat up all the > bandwidth, just by sending spoofed packets. 1) How can this be used to crash hosts? 2) Of course you can eat up all bandwith, if you have something which arbitrarily mirrors all received packets back. This is obvious. > It?s also documented in the Linux kernel help, but you won?t really think, > that the TTL is not decremented, if you read there, that the source and > destination address of the packets is reversed. If you use the MIRROR target in the FORWARD chain of the filter table (where you usually would place it), the TTL is decremented. Look at the code-flow through the IP stack: net/ipv4/ip_input.c:ip_rcv_finish() net/ipv4/route.c:ip_route_input() net/ipv4/ip_forward.c:ip_forward() - TTL is decremented / checked / packet dropped if TTL == 0 - _afterwards_ the NF_IP_FORWARD hook is called and the FORWARD chain of the filter table traversed > - Don't use the MIRROR target. It is a (quote:) "experimental demonstration target". It is not and was never to be used in production environments. Furthermore, why didn't you contact the netfilter developers with this issue first? Isn't it a matter of politeness to inform the 'vendor' at least at the same time you release information about a possible bug / weakness / ... ? And, regarding your proposed patch: Just iph->ttl-- is not the solution. - What happens if you decrement 0? ( -> 255 again) - You don't drop the packet if the TTL is decremented to 0. - You have to check on the hook. If NF_HOOK == NF_IP_FORWARD, then the TTL has already been decremented by the core stack The netfilter core team will provide a solution for the only remaining case: - Usage of the MIRROR target in INPUT or PREROUTING chain In this case, the current MIRROR target indeed violates the host requirements RFC, because it doesn't decrement the TTL. However, we still don't regard this as a security hole or weakness. If you use experimental code (explicitly marked as "for demonstration only") in production environments, you know that you are doing it at your own risk. As soon as you use the MIRROR target without any bandwith limiting, you will _always_ be in a situation where somebody can eat up your outgoing bandwith. This is a well-known fact, and obvious. > Fabian Melzow Michael Bauer > biop0bat_private mihiat_private -- Live long and prosper - Harald Welte / laforgeat_private http://www.gnumonks.org ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
This archive was generated by hypermail 2b30 : Sun Aug 26 2001 - 01:14:55 PDT