FreeBSD Security Advisories
2003-Sep-25 07:07 UTC
FreeBSD Security Advisory FreeBSD-SA-03:14.arp [REVISED]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
============================================================================FreeBSD-SA-03:14.arp
Security Advisory
The FreeBSD Project
Topic: denial of service due to ARP resource starvation
Category: core
Module: sys
Announced: 2003-09-25
Credits: Apple Product Security <product-security@apple.com>
Affects: All releases of FreeBSD
FreeBSD 4-STABLE prior to the correction date
Corrected: 2003-09-24 21:48:00 UTC (RELENG_4, 4.9-PRERELEASE)
2003-09-25 13:33:01 UTC (RELENG_5_1, 5.1-RELEASE-p8)
2003-09-25 13:33:29 UTC (RELENG_5_0, 5.0-RELEASE-p16)
2003-09-25 13:34:14 UTC (RELENG_4_8, 4.8-RELEASE-p10)
2003-09-25 13:34:31 UTC (RELENG_4_7, 4.7-RELEASE-p20)
2003-09-25 13:34:52 UTC (RELENG_4_6, 4.6-RELEASE-p23)
2003-09-25 13:35:18 UTC (RELENG_4_5, 4.5-RELEASE-p34)
2003-09-25 13:35:33 UTC (RELENG_4_4, 4.4-RELEASE-p44)
2003-09-25 13:35:48 UTC (RELENG_4_3, 4.3-RELEASE-p40)
FreeBSD only: NO
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
<URL:http://www.freebsd.org/security/>.
0. Revision History
v1.0 2003-09-23 Initial release.
v1.1 2003-09-25 Initial patch was incorrect.
I. Background
The Address Resolution Protocol (ARP) is fundamental to the operation
of IP with a variety of network technologies, such as Ethernet and
WLAN. It is used to map IP addresses to MAC addresses, which enables
hosts on a local network segment to communicate with each other
directly. These mappings are stored in the system's ARP cache.
FreeBSD's ARP cache is implemented within the kernel routing table as
a set of routes for the address family in use that have the LLINFO
flag set. This is most commonly often AF_INET (for IPv4). Normally,
when a FreeBSD system receives an ARP request for a network address
configured on one of its interfaces from a system on a local network,
it adds a reciprocal ARP entry to the cache for the system from where
the request originated. Expiry timers are used to purge unused
entries from the ARP cache. A reference count is maintained for each
ARP entry. If the reciprocal ARP entry is not in use by an upper
layer protocol, the reference count will be zero.
II. Problem Description
Under certain circumstances, it is possible for an attacker to flood a
FreeBSD system with spoofed ARP requests, causing resource starvation
which eventually results in a system panic. (The critical condition
is that a route exists for the apparent source of the ARP request.
This is always the case if the system has a default route configured
for that protocol family.)
If a large number of ARP requests with different network protocol
addresses are sent in a small space of time, resource starvation can
result, as the arplookup() function does not delete unnecessary ARP
entries cached as the result of responding to an ARP request.
NOTE WELL: Other BSD-derived systems may also be affected, as the
affected code dates well back to the CSRG branches.
III. Impact
An attacker on the local network may be able to cause the system to
hang or crash. The attacker must have physical access to the shared
network medium. In the case of a wireless network obtaining this
access may be trivial. Networks where proxy ARP is used to direct
traffic between LANs may be particularly vulnerable to the attack,
as the spoofed ARP requests could be bounced through to the target
via routers implementing proxy ARP.
Because the attack operates at Layer 2, the use of strong encryption
technologies such as IPsec cannot protect a system against the attack.
IV. Workaround
There is no known workaround at this time.
V. Solution
Do one of the following:
1) Upgrade your vulnerable system to 4-STABLE; or to the RELENG_5_1,
RELENG_5_0, RELENG_4_8, or RELENG_4_7 security branch dated after the
correction date.
2) To patch your present system:
The following patch has been verified to apply to FreeBSD 5-CURRENT,
4.9-PRERELEASE, and 4.8 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:14/arp.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:14/arp.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Rebuild your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html>
and reboot the system.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_4
src/sys/netinet/if_ether.c 1.64.2.26
RELENG_5_1
src/UPDATING 1.251.2.10
src/sys/conf/newvers.sh 1.50.2.10
src/sys/netinet/if_ether.c 1.104.2.2
RELENG_5_0
src/UPDATING 1.229.2.22
src/sys/conf/newvers.sh 1.48.2.17
src/sys/netinet/if_ether.c 1.96.2.2
RELENG_4_8
src/UPDATING 1.73.2.80.2.12
src/sys/conf/newvers.sh 1.44.2.29.2.11
src/sys/netinet/if_ether.c 1.64.2.22.2.2
RELENG_4_7
src/UPDATING 1.73.2.74.2.23
src/sys/conf/newvers.sh 1.44.2.26.2.22
src/sys/netinet/if_ether.c 1.64.2.19.2.2
RELENG_4_6
src/UPDATING 1.73.2.68.2.52
src/sys/conf/newvers.sh 1.44.2.23.2.40
src/sys/netinet/if_ether.c 1.64.2.18.2.2
RELENG_4_5
src/UPDATING 1.73.2.50.2.51
src/sys/conf/newvers.sh 1.44.2.20.2.35
src/sys/netinet/if_ether.c 1.64.2.15.2.2
RELENG_4_4
src/UPDATING 1.73.2.43.2.52
src/sys/conf/newvers.sh 1.44.2.17.2.43
src/sys/netinet/if_ether.c 1.64.2.11.2.2
RELENG_4_3
src/UPDATING 1.73.2.28.2.39
src/sys/conf/newvers.sh 1.44.2.14.2.29
src/sys/netinet/if_ether.c 1.64.2.10.2.2
- -------------------------------------------------------------------------
VII. References
<URL:http://docs.info.apple.com/article.html?artnum=61798>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQE/cvNNFdaIBMps37IRAlIsAJ9Kj0u+ZUEOUcpqjl6hISvrALwGQgCfaG5m
jpFBTK86xjFNz4t43ZQtcOU=cfvr
-----END PGP SIGNATURE-----
Derek Ragona
2003-Sep-26 06:06 UTC
FreeBSD Security Advisory FreeBSD-SA-03:14.arp [REVISED]
I have two servers one is:
5.1-RELEASE-p6
the other is:
5.1-RELEASE-p7
cvsup'd them both, neither will complete a buildworld, they both error
trying to compile.
Anyone got this to work on RELENG_5_1?
-Derek
At 07:07 AM 9/25/2003 -0700, FreeBSD Security Advisories
wrote:>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>============================================================================>FreeBSD-SA-03:14.arp
Security Advisory
> The FreeBSD
Project
>
>Topic: denial of service due to ARP resource starvation
>
>Category: core
>Module: sys
>Announced: 2003-09-25
>Credits: Apple Product Security <product-security@apple.com>
>Affects: All releases of FreeBSD
> FreeBSD 4-STABLE prior to the correction date
>Corrected: 2003-09-24 21:48:00 UTC (RELENG_4, 4.9-PRERELEASE)
> 2003-09-25 13:33:01 UTC (RELENG_5_1, 5.1-RELEASE-p8)
> 2003-09-25 13:33:29 UTC (RELENG_5_0, 5.0-RELEASE-p16)
> 2003-09-25 13:34:14 UTC (RELENG_4_8, 4.8-RELEASE-p10)
> 2003-09-25 13:34:31 UTC (RELENG_4_7, 4.7-RELEASE-p20)
> 2003-09-25 13:34:52 UTC (RELENG_4_6, 4.6-RELEASE-p23)
> 2003-09-25 13:35:18 UTC (RELENG_4_5, 4.5-RELEASE-p34)
> 2003-09-25 13:35:33 UTC (RELENG_4_4, 4.4-RELEASE-p44)
> 2003-09-25 13:35:48 UTC (RELENG_4_3, 4.3-RELEASE-p40)
>FreeBSD only: NO
>
>For general information regarding FreeBSD Security Advisories,
>including descriptions of the fields above, security branches, and the
>following sections, please visit
><URL:http://www.freebsd.org/security/>.
>
>0. Revision History
>
>v1.0 2003-09-23 Initial release.
>v1.1 2003-09-25 Initial patch was incorrect.
>
>I. Background
>
>The Address Resolution Protocol (ARP) is fundamental to the operation
>of IP with a variety of network technologies, such as Ethernet and
>WLAN. It is used to map IP addresses to MAC addresses, which enables
>hosts on a local network segment to communicate with each other
>directly. These mappings are stored in the system's ARP cache.
>
>FreeBSD's ARP cache is implemented within the kernel routing table as
>a set of routes for the address family in use that have the LLINFO
>flag set. This is most commonly often AF_INET (for IPv4). Normally,
>when a FreeBSD system receives an ARP request for a network address
>configured on one of its interfaces from a system on a local network,
>it adds a reciprocal ARP entry to the cache for the system from where
>the request originated. Expiry timers are used to purge unused
>entries from the ARP cache. A reference count is maintained for each
>ARP entry. If the reciprocal ARP entry is not in use by an upper
>layer protocol, the reference count will be zero.
>
>II. Problem Description
>
>Under certain circumstances, it is possible for an attacker to flood a
>FreeBSD system with spoofed ARP requests, causing resource starvation
>which eventually results in a system panic. (The critical condition
>is that a route exists for the apparent source of the ARP request.
>This is always the case if the system has a default route configured
>for that protocol family.)
>
>If a large number of ARP requests with different network protocol
>addresses are sent in a small space of time, resource starvation can
>result, as the arplookup() function does not delete unnecessary ARP
>entries cached as the result of responding to an ARP request.
>
>NOTE WELL: Other BSD-derived systems may also be affected, as the
>affected code dates well back to the CSRG branches.
>
>III. Impact
>
>An attacker on the local network may be able to cause the system to
>hang or crash. The attacker must have physical access to the shared
>network medium. In the case of a wireless network obtaining this
>access may be trivial. Networks where proxy ARP is used to direct
>traffic between LANs may be particularly vulnerable to the attack,
>as the spoofed ARP requests could be bounced through to the target
>via routers implementing proxy ARP.
>
>Because the attack operates at Layer 2, the use of strong encryption
>technologies such as IPsec cannot protect a system against the attack.
>
>IV. Workaround
>
>There is no known workaround at this time.
>
>V. Solution
>
>Do one of the following:
>
>1) Upgrade your vulnerable system to 4-STABLE; or to the RELENG_5_1,
>RELENG_5_0, RELENG_4_8, or RELENG_4_7 security branch dated after the
>correction date.
>
>2) To patch your present system:
>
>The following patch has been verified to apply to FreeBSD 5-CURRENT,
>4.9-PRERELEASE, and 4.8 systems.
>
>a) Download the relevant patch from the location below, and verify the
>detached PGP signature using your PGP utility.
>
>ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:14/arp.patch
>ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:14/arp.patch.asc
>
>b) Execute the following commands as root:
>
># cd /usr/src
># patch < /path/to/patch
>
>c) Rebuild your kernel as described in
><URL:http://www.freebsd.org/handbook/kernelconfig.html>
>and reboot the system.
>
>VI. Correction details
>
>The following list contains the revision numbers of each file that was
>corrected in FreeBSD.
>
>Branch Revision
> Path
>- -------------------------------------------------------------------------
>RELENG_4
> src/sys/netinet/if_ether.c 1.64.2.26
>RELENG_5_1
> src/UPDATING 1.251.2.10
> src/sys/conf/newvers.sh 1.50.2.10
> src/sys/netinet/if_ether.c 1.104.2.2
>RELENG_5_0
> src/UPDATING 1.229.2.22
> src/sys/conf/newvers.sh 1.48.2.17
> src/sys/netinet/if_ether.c 1.96.2.2
>RELENG_4_8
> src/UPDATING 1.73.2.80.2.12
> src/sys/conf/newvers.sh 1.44.2.29.2.11
> src/sys/netinet/if_ether.c 1.64.2.22.2.2
>RELENG_4_7
> src/UPDATING 1.73.2.74.2.23
> src/sys/conf/newvers.sh 1.44.2.26.2.22
> src/sys/netinet/if_ether.c 1.64.2.19.2.2
>RELENG_4_6
> src/UPDATING 1.73.2.68.2.52
> src/sys/conf/newvers.sh 1.44.2.23.2.40
> src/sys/netinet/if_ether.c 1.64.2.18.2.2
>RELENG_4_5
> src/UPDATING 1.73.2.50.2.51
> src/sys/conf/newvers.sh 1.44.2.20.2.35
> src/sys/netinet/if_ether.c 1.64.2.15.2.2
>RELENG_4_4
> src/UPDATING 1.73.2.43.2.52
> src/sys/conf/newvers.sh 1.44.2.17.2.43
> src/sys/netinet/if_ether.c 1.64.2.11.2.2
>RELENG_4_3
> src/UPDATING 1.73.2.28.2.39
> src/sys/conf/newvers.sh 1.44.2.14.2.29
> src/sys/netinet/if_ether.c 1.64.2.10.2.2
>- -------------------------------------------------------------------------
>
>VII. References
>
><URL:http://docs.info.apple.com/article.html?artnum=61798>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.3 (FreeBSD)
>
>iD8DBQE/cvNNFdaIBMps37IRAlIsAJ9Kj0u+ZUEOUcpqjl6hISvrALwGQgCfaG5m
>jpFBTK86xjFNz4t43ZQtcOU>=cfvr
>-----END PGP SIGNATURE-----
>_______________________________________________
>freebsd-security-notifications@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications
>To unsubscribe, send any mail to
>"freebsd-security-notifications-unsubscribe@freebsd.org"
Reasonably Related Threads
- FreeBSD Security Advisory FreeBSD-SA-03:14.arp
- FreeBSD Security Advisory FreeBSD-SA-03:14.arp
- FreeBSD Security Advisory FreeBSD-SA-03:14.arp [REVISED]
- FreeBSD Security Advisory FreeBSD-SA-03:12.openssh [REVISED]
- FreeBSD Security Advisory FreeBSD-SA-03:12.openssh [REVISED]