FreeBSD Security Advisories
2005-May-05 20:03 UTC
FreeBSD Security Advisory FreeBSD-SA-05:08.kmem
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
============================================================================FreeBSD-SA-05:08.kmem
Security Advisory
The FreeBSD Project
Topic: Local kernel memory disclosure
Category: core
Module: sys
Announced: 2005-05-06
Credits: Christian S.J. Peron
Affects: All FreeBSD releases prior to 5.4-RELEASE
Corrected: 2005-05-06 02:50:00 UTC (RELENG_5, 5.4-STABLE)
2005-05-06 02:51:10 UTC (RELENG_5_4, 5.4-RELEASE)
2005-05-06 02:50:35 UTC (RELENG_5_3, 5.3-RELEASE-p13)
2005-05-06 02:48:46 UTC (RELENG_4, 4.11-STABLE)
2005-05-06 02:49:35 UTC (RELENG_4_11, 4.11-RELEASE-p7)
2005-05-06 02:49:08 UTC (RELENG_4_10, 4.10-RELEASE-p12)
CVE Name: CAN-2005-1406
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/>.
I. Background
In many parts of the FreeBSD kernel, names (of mount points, devices,
files, etc.) are manipulated as NULL-terminated strings, but are provided
to applications within fixed-length buffers.
II. Problem Description
In several places, variable-length strings were copied into fixed-length
buffers without zeroing the unused portion of the buffer.
III. Impact
The previous contents of part of the fixed-length buffers will be
disclosed to applications. Such memory might contain sensitive
information, such as portions of the file cache or terminal buffers.
This information might be directly useful, or it might be leveraged to
obtain elevated privileges in some way. For example, a terminal buffer
might include a user-entered password.
IV. Workaround
No workaround is available.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 4-STABLE or 5-STABLE, or to the
RELENG_5_3, RELENG_4_11, or RELENG_4_10 security branch dated after
the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 4.10,
4.11, and 5.3 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 4.x]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:08/kmem4.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:08/kmem4.patch.asc
[FreeBSD 5.x]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:08/kmem5.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:08/kmem5.patch.asc
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile 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/kern/vfs_subr.c 1.249.2.32
src/sys/net/if_mib.c 1.8.2.3
src/sys/netinet/ip_divert.c 1.42.2.8
src/sys/netinet/raw_ip.c 1.64.2.20
src/sys/netinet/udp_usrreq.c 1.64.2.20
RELENG_4_11
src/UPDATING 1.72.2.91.2.8
src/sys/conf/newvers.sh 1.44.2.39.2.11
src/sys/kern/vfs_subr.c 1.249.2.31.6.1
src/sys/net/if_mib.c 1.8.2.2.2.1
src/sys/netinet/ip_divert.c 1.42.2.7.2.1
src/sys/netinet/raw_ip.c 1.64.2.19.2.1
src/sys/netinet/udp_usrreq.c 1.64.2.19.6.1
RELENG_4_10
src/UPDATING 1.73.2.90.2.13
src/sys/conf/newvers.sh 1.44.2.34.2.14
src/sys/kern/vfs_subr.c 1.249.2.31.4.1
src/sys/net/if_mib.c 1.8.2.1.16.2
src/sys/netinet/ip_divert.c 1.42.2.6.6.1
src/sys/netinet/raw_ip.c 1.64.2.18.4.1
src/sys/netinet/udp_usrreq.c 1.64.2.19.4.1
RELENG_5
src/sys/kern/subr_bus.c 1.156.2.7
src/sys/kern/vfs_subr.c 1.522.2.5
src/sys/net/if_mib.c 1.13.4.2
src/sys/netinet/ip_divert.c 1.98.2.3
src/sys/netinet/raw_ip.c 1.142.2.5
src/sys/netinet/udp_usrreq.c 1.162.2.8
RELENG_5_4
src/UPDATING 1.342.2.24.2.7
src/sys/kern/subr_bus.c 1.156.2.5.2.1
src/sys/kern/vfs_subr.c 1.522.2.4.2.1
src/sys/net/if_mib.c 1.13.4.1.2.1
src/sys/netinet/ip_divert.c 1.98.2.2.2.1
src/sys/netinet/raw_ip.c 1.142.2.4.2.1
src/sys/netinet/udp_usrreq.c 1.162.2.7.2.1
RELENG_5_3
src/UPDATING 1.342.2.13.2.16
src/sys/conf/newvers.sh 1.62.2.15.2.18
src/sys/kern/subr_bus.c 1.156.2.2.2.1
src/sys/kern/vfs_subr.c 1.522.2.1.2.1
src/sys/net/if_mib.c 1.13.6.1
src/sys/netinet/ip_divert.c 1.98.4.1
src/sys/netinet/raw_ip.c 1.142.2.2.2.1
src/sys/netinet/udp_usrreq.c 1.162.2.3.2.1
- -------------------------------------------------------------------------
The latest revision of this advisory is available at
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:08.kmem.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)
iD8DBQFCet0HFdaIBMps37IRAvxIAJ9iM61VUlJNE8x/yNjjiSJkb3KZ3QCgnbIm
SnJAg6SOw/yfRDHoxiKwRIM=yN6p
-----END PGP SIGNATURE-----
FreeBSD Security Advisories wrote:> [...]> a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > > [FreeBSD 4.x] > # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:08/kmem4.patch > # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:08/kmem4.patch.ascAmong other things 'kmem4.patch' deals with zeroing a "struct xinpcb" variable, allocated on the stack, in div_pcblist(), rip_pcblist() and udp_pcblist(). Identical code in all three cases: inp = inp_list[i]; if (inp->inp_gencnt <= gencnt) { struct xinpcb xi; + bzero(&xi, sizeof(xi)); xi.xi_len = sizeof xi; /* XXX should avoid extra copy */ bcopy(inp, &xi.xi_inp, sizeof *inp); However, isn't there a similar case in tcp_pcblist()? Only that this time a "struct xtcpcb" variable is concerned. It isn't guaranteed to be completely initialized, either. Especially since it has the same kind of explicit alignment padding at the end as "struct xinpcb" which cannot be expected to become initialized in the course of data assignment in any case. Here's the relevant part at line 897 in 'tcp_subr.c' (RELENG_4): inp = inp_list[i]; if (inp->inp_gencnt <= gencnt) { struct xtcpcb xt; caddr_t inp_ppcb; xt.xt_len = sizeof xt; /* XXX should avoid extra copy */ bcopy(inp, &xt.xt_inp, sizeof *inp); I'd think that the appropriate patch would therefore look like this: inp = inp_list[i]; if (inp->inp_gencnt <= gencnt) { struct xtcpcb xt; caddr_t inp_ppcb; + bzero(&xt, sizeof(xt)); xt.xt_len = sizeof xt; /* XXX should avoid extra copy */ bcopy(inp, &xt.xt_inp, sizeof *inp); If my analysis is correct the release of an additional or updated security advisory might be called for. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net