COMMAND

    ARP table

SYSTEMS AFFECTED

    NetBSD-1.3*

PROBLEM

    Following is based on NetBSD Security Advisory. The implementation
    of ARP packet reception is vulnerable two attacks:

        - on multihomed hosts, ARP packets from cable A can  overwrite
          ARP entries for cable B.
        - for all hosts, ARP packets can overwrite ARP entries  marked
          as static.

    ARP is a  protocol used to  dynamically obtain IPv4  to Link level
    address  translation,  used  for  Ethernet,  FDDI, Token ring, and
    ARCnet cables, described in RFC  826.  The first vulnerability  is
    specific to hosts with more than one ARP capable network attached.
    The address information of incoming ARP packets is not checked  to
    ensure  that  it  corresponds  to  one  of  the  addresses  of the
    interface on which the packet arrived.  Thus, it would be able  to
    suppress or redirect traffic from the attacked host to a different
    destination.   The second  vulnerability is  related to  so-called
    "static" arp entries.  The original NetBSD ARP implementation  (as
    that of  most other  vendors) allows  the creation  of "static" or
    "permanent" ARP entries.  They are typically used for two reasons:

        - as  a  security  measure,  to  disallow  the redirection  of
          traffic addressed to priviledged hosts by rogue hosts on the
          cable to themselves or elsewhere,

        - as  a  cheap  routing  protocol  ("proxy ARP"), mostly  when
          connecting single hosts  through point to  point links.   To
          the  outside,  they  occur  as  if  they where on the (e.g.)
          Ethernet, but traffic destined for them is redirected by the
          ARP mechanism to the routing host.

    The  2nd  usage   doesn't  create  specific   denial  of   service
    possibilities as the ARP protocol is insecure in itself.  However,
    if static  ARP entries  are used  to prevent  D.O.S. attacks, they
    need to be protected from overwriting.

    Both vulnerabilities  were reported  by Olaf  "Rhialto" Seibert in
    NetBSD PR 7489 and PR 7490.   A fix was provided by Zdenek  Salvet
    in PR 7497, and integrated into NetBSD by Ignatios Souvatzis.

SOLUTION

    NetBSD-1.4, and  NetBSD-1.4_BETA after  1999-05-05, are  fixed.  A
    patch is available for NetBSD 1.3.3 to fix this problem.  You  may
    find this patch on the NetBSD ftp server:

        ftp://ftp.NetBSD.ORG/pub/NetBSD/misc/security/patches/19990505-arp

    NetBSD-current  since  19990506  is  not  vulnerable.   Users   of
    NetBSD-current  should  upgrade  to  a  source  tree  later   than
    19990506.