>Number: 148463 >Category: misc >Synopsis: ARP cache can be poisoned or polluted with ease. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jul 09 06:20:03 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Paul-Andrew Joseph Miseiko >Release: 8.1-PRERELEASE >Organization: >Environment: FreeBSD teardrop.ca 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #1: Wed Jul 7 22:18:16 EDT 2010 esote...@teardrop.ca:/usr/obj/usr/src/sys/TEARDROP i386 >Description: FreeBSD will add to the kernel ARP cache the source hardware address associated with the source protocol address when an ARP request packet or ARP reply packet is received and the target protocol address is the same as the interface protocol address.
A malicious user could use this behavior to alter the hardware address associated with a particular protocol address. FreeBSD will accept the new hardware address associated with a particular protocol address that is known in the ARP cache. A malicious user could use this behavior to perform a denial of service against the kernel ARP cache when a FreeBSD device is bound to a large network. FreeBSD will create a kernel ARP cache entry for each ARP request packet and ARP reply packet received. >How-To-Repeat: Send an ARP request packet or ARP response packet to the physical broadcast address (or physical interface address) with the target protocol address set to a FreeBSD device and the source hardware address and source protocol address set to the desired protocol address to poison in the FreeBSD device kernel ARP cache or populate the FreeBSD kernel ARP cache with excessive entries. >Fix: #1. FreeBSD should not permit alteration of a kernel ARP cache entry if it has not made an explicit ARP request for the protocol address associated with the kernel ARP cache entry. The time-to-live for a kernel ARP cache entry might need to be shortened for this to work well in heterogeneous environments. Some of the risk involved with malicious intent to redirect a protocol address to a specific hardware address will be mitigated through this change. To perform a malicious action with this constraint would result in a race condition for when a FreeBSD device has made an ARP request to be the first to produce the expected ARP reply. In theory a malicious user might send several ARP replies in anticipation of an ARP request. The FreeBSD device could detect such behavior and log a message, remove the kernel ARP cache entry due to the suspicious circumstance, or accept the least frequency ARP reply. #2. FreeBSD should not create a kernel ARP cache entry for a protocol address it has not made an ARP request for. The risk of a remote malicious user triggering a potential denial of service against the kernel ARP cache would be eliminated through this change. Note. The suggested solution(s) above could have a sysctl option to enable them. A FreeBSD device on a trusted network would not require protection from malicious intent through the ARP protocol. >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
