Vulnerability Development: Re: Buggy ARP handling in Windoze

[Michael.Wojcik () MERANT COM (Michael Wojcik)]

This is more suited to VULN-DEV than to BUGTRAQ, since it's not about an
existing exploit.  This stupid MUA won't let me set reply-to, so I'll trust
the goodwill of those who respond (if there are any) to direct their notes
to the right place.

> -----Original Message-----
> From: Steven Alexander [mailto:steve () CELL2000 NET]
> Sent: Thursday, June 29, 2000 5:29 PM
> Paul's post brings up an interesting issue.  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).
Frankly, I've always used static entries for (manual) proxy ARP, not for
security or performance.  Permanence was important only because I didn't
want to have to re-establish the proxy ARP entry every so often due to
timeouts.  The inventors of static ARP may not have had security *or*
performance in mind; they may have just been looking to provide an
administrative feature that would be useful in a variety of unusual
situations.

> 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.
ARP's pretty fast even over a 2 Mb/s LAN.  I'm not convinced static ARP was
ever much of a performance boost.  And your second sentence strikes me as
non sequitur: static ARP doesn't introduce the ARP poisoning problem.  If an
ARP implementation makes static entries immutable, that may help defend
against ARP poisoning, but normal transient ARP entries are just as
vulnerable to poisoning as static ones are.

> 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).  What does everyone
else
> think?
More control is always welcome, but the security advantage of immutable ARP
entries seems fairly slim.  Everything helps, but I wouldn't recommend
treating ARP as safe just because you have an immutable flag.

Michael Wojcik             michael.wojcik () merant com
MERANT
Department of English, Miami University