COMMAND

    arp

SYSTEMS AFFECTED

    Windows 98

PROBLEM

    Paul Starzetz discovered a strange  bug in the ARP handling  under
    Windows 98/latest Winsock  patch (IGMP).   Win98 (at almost  Win95
    as far as tested) would  not handle static ARP entries  correctly.
    Setting up an static ARP cache entry like:

        c:\windows\arp.exe -s host_ip host_mac

    do not  immunise against  spoofed ARP  packet, if  someone on  the
    subnet  is  playing  with  ARP  and  regardless  the opcode an ARP
    packet with arp_protocol_address == host_ip arrives, Windose  will
    update  the  'static'  entry  to  the  MAC whatever the ARP packet
    points  to.   So  a  'static'  entry  means, the entry wouldn't be
    deleted and remains  for ever in  the cache.   This is not  really
    the behaviour we want.

    Static ARP entries aren't actually  regulated by RFC 826 (The  ARP
    specification).   Static can  be interpreted  in two  ways in  the
    context of  the ARP  cache.   It can  be seen  as unchangeable vs.
    changeable (for  security), or  it can  be seen  as permanent  vs.
    temporary (for performance).

    Likely, when  ARP was  originally designed  the latter  would have
    been more  desireable.   You might  have a  fileserver on your LAN
    that you would  set static ARP  entries for so  that everybody has
    it in their cache all of the time, a slight performance  increase.
    However, if that fileserver goes  down you may wish to  replace it
    without manually  changing ARP  entries on  every machine  in your
    network.  With gratuitous ARP you are able to bring a new  machine
    up to replace  the downed machine  and everyone will  update their
    ARP cache to reflect the new MAC address.  If the machines on  the
    network do not update the static ARP cache entries you would  have
    to change each one manually (likely to be difficult).

    Unfortunately, network  environments are  much less  friendly than
    when ARP was designed (1982) and  they are also much faster.   The
    performance gain  that results  from static  entries is  miniscule
    compared with the  security risk that  results from being  able to
    poison the ARP cache.  However, there is also the valid point that
    you may wish to bring up a backup server in the event that one  of
    your machines fails and ypu may  not be able to update all  of the
    ARP entries on each machine manually.

    Wojtek Woch added  following.  Testing  on NT 4.0  with SP6a shows
    that it behaves the  same, although the spoofed  machine complains
    in its event log with a Tcpip event #4199 and an application popup
    #26 (IP address conflict).

    It appears  also that  as long  as the  IP address  is in  the ARP
    cache, it's MAC address can be overwritten - even if the entry  is
    flagged as dynamic.  But as Yuri Volobuev noted you would need  to
    inject ARP packets continously in this case.

SOLUTION

    Note  that  Lunix  will  behave  correctly  (tested against 2.2.16
    kernels), so setting  an static ARP  for a host  protects your box
    from ARP spoofing.   Of course, you  may set up  static ARP  table
    and then run a firewall on each machine to filter further ARP....

    This is a 'feature' - at  least so it says in a  preparation guide
    for the  Microsoft TCP/IP  exam that  "a static  entry in  the ARP
    cache  changes  if  an  ARP  broadcast  that indicates a different
    hardware address is received.  In this case, the type of the entry
    changes  to  dynamic,  and  the  newly  received  hardware address
    replaces the current one."

    This is not official  Microsoft-documentation, but it *is*  from a
    "Microsoft approved study guide",  so it's what Microsoft  teaches
    their MCPs and MCSEs.

    It would  probably be  beneficial in  an ARP  implementation to be
    able  to  set  two  seperate  attributes  to  the  ARP cache, both
    permanent   (no   timeout)   and   unchangeable   (without  manual
    intervention anyway).