Re: improper use of netfilter MIRROR target can cause DoS

[Harald Welte <laforge () gnumonks org>]

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
> biop0b () web de           mihi () gmx at



-- 
Live long and prosper
- Harald Welte / laforge () gnumonks org                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+(*)