[En-Nut-Discussion] security leak in ARP

Nathan Moore nategoose at gmail.com
Wed Oct 7 19:22:38 CEST 2009


>
>
>
> the function void NutArpInput(NUTDEVICE * dev, NETBUF * nb) in net/arpin.c
> adds an entry into the arp-table when ethernut receives an arp-request.
> this implementation is proposed in rfc 826. this open 2 security leaks:
>
> 1. nut/os will create a new entry when receiving a request, making a
> flood attack possible. nut will use up eventually all the heap-memory
> for faked arp entries.
>

With only a little more work an attacker may do this anyway.  Nut responds
to ICMP echo (ping) and also sends ICMP error messages,
all of which require an ARP entry.  In fact without the pre-population of
the ARP table with an entry Nut will behave even worse because
for many of the ICMP replies the interface's RX thread will be forced to
send an ARP request, then sleep waiting for an ARP reply, and
never get the reply because it is the same thread that is supposed to
be listening for them.  This is a much more serious DOS because
it would only take sending one packet to a NUT box every several seconds to
keep the network interface's RX thread occupied.

There is a slight chance that this may be triggered in current code.  What
comes to mind is if a ping packet comes into the LAN to a
NUT via a router that the NUT doesn't think is the best route back to the
sender.  If what NUT does think is the best route back to the
sender does not have an entry in the ARP cache then the ethernet RX thread
will end up waiting for an ARP reply that it can't get.
There are other ways to trigger this, but I thought this one might be the
most real world example with no misbehaving LAN neighbors.


>
> 2. nut/os will update the mac of existing entries, enabling a
> man-in-the-middle
> attack.
>

This is exactly the same as if someone else on the LAN is replying to ARP
requests.
If someone else on the Ethernet LAN wants to screw you up they can do it.
 You can't stop them.

In the case of LAN neighbors doing bad things it's probably better to try to
deal with non-malicious bad behavior.


Nathan



More information about the En-Nut-Discussion mailing list