FreeBSD Security Advisories
2005-Apr-04 17:09 UTC
FreeBSD Security Advisory FreeBSD-SA-05:02.sendfile
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
============================================================================FreeBSD-SA-05:02.sendfile
Security Advisory
The FreeBSD Project
Topic: sendfile kernel memory disclosure
Category: core
Module: sys_kern
Announced: 2005-04-04
Credits: Sven Berkvens <sven@berkvens.net>
Marc Olzheim <zlo@zlo.nu>
Affects: All FreeBSD 4.x releases
All FreeBSD 5.x releases prior to 5.4-RELEASE
Corrected: 2005-04-04 23:52:02 UTC (RELENG_5, 5.4-STABLE)
2005-04-04 23:52:35 UTC (RELENG_5_4, 5.4-RELEASE)
2005-04-04 23:53:24 UTC (RELENG_5_3, 5.3-RELEASE-p7)
2005-04-04 23:53:36 UTC (RELENG_4, 4.11-STABLE)
2005-04-04 23:53:56 UTC (RELENG_4_11, 4.11-RELEASE-p2)
2005-04-04 23:54:13 UTC (RELENG_4_10, 4.10-RELEASE-p7)
2005-04-04 23:54:33 UTC (RELENG_4_8, 4.8-RELEASE-p29)
CVE Name: CAN-2005-0708
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
The sendfile(2) system call allows a server application (such as an HTTP
or FTP server) to transmit the contents of a file over a network
connection without first copying it to application memory. High
performance servers such as Apache and ftpd use sendfile.
II. Problem Description
If the file being transmitted is truncated after the transfer has
started but before it completes, sendfile(2) will transfer the contents
of more or less random portions of kernel memory in lieu of the
missing part of the file.
III. Impact
A local user could create a large file and truncate it while
transferring it to himself, thus obtaining a copy of portions of system
memory to which he would normally not have access. 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 known workaround.
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, RELENG_4_10, or RELENG_4_8 security branch
dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 4.8, 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:02/sendfile_4.patch
# fetch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:02/sendfile_4.patch.asc
[FreeBSD 5.3]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:02/sendfile_5.patch
# fetch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:02/sendfile_5.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/ufs/ffs/ffs_inode.c 1.56.2.6
RELENG_4_11
src/UPDATING 1.73.2.91.2.3
src/sys/conf/newvers.sh 1.44.2.39.2.6
src/sys/ufs/ffs/ffs_inode.c 1.56.2.5.12.1
RELENG_4_10
src/UPDATING 1.73.2.90.2.8
src/sys/conf/newvers.sh 1.44.2.34.2.8
src/sys/ufs/ffs/ffs_inode.c 1.56.2.5.10.1
RELENG_4_8
src/UPDATING 1.73.2.80.2.33
src/sys/conf/newvers.sh 1.44.2.29.2.29
src/sys/ufs/ffs/ffs_inode.c 1.56.2.5.6.1
RELENG_5
src/sys/ufs/ffs/ffs_inode.c 1.93.2.2
RELENG_5_4
src/UPDATING 1.342.2.24.2.1
src/sys/ufs/ffs/ffs_inode.c 1.93.2.1.2.1
RELENG_5_3
src/UPDATING 1.342.2.13.2.10
src/sys/conf/newvers.sh 1.62.2.15.2.12
src/sys/ufs/ffs/ffs_inode.c 1.93.4.1
- -------------------------------------------------------------------------
The latest revision of this advisory is available at
ftp://ftp.freebsd.org/pub/CERT/advisories/FreeBSD-SA-05:02.sendfile.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFCUdSBFdaIBMps37IRAkJQAJ9jiw22zHygE8ui8ksl3T5jo12L6gCgkq5i
CYhVGcVxiWOU9Yu1Muwi1Xw=83NE
-----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:02/sendfile_4.patch > # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:02/sendfile_4.patch.asc > [...]The patch file (and CVS, too) contains this: --------------------- cut here ---------------------- --- sys/ufs/ffs/ffs_inode.c 5 Feb 2002 18:35:03 -0000 1.56.2.5 +++ sys/ufs/ffs/ffs_inode.c 11 Mar 2005 14:29:19 -0000 @@ -197,6 +197,7 @@ #endif softdep_setup_freeblocks(oip, length); vinvalbuf(ovp, 0, cred, p, 0, 0); + vnode_pager_setsize(vp, 0); oip->i_flag |= IN_CHANGE | IN_UPDATE; return (ffs_update(ovp, 0)); } --------------------- cut here ---------------------- I wonder, isn't the variable 'vp' actually supposed to be 'ovp' in the added line? Technically they are identical. 'ovp' is assigned from 'vp' once in the variable definition section at the start of the function. However, using 'vp' when calling vnode_pager_setsize() looks a little odd given that anywhere else in this function, including another call to vnode_pager_setsize(), the variable 'ovp' is used instead of 'vp'. I can't tell why 'ovp' was introduced in the first place. Might have historical reasons. But that's how the code currently works. In the MAIN branch as well, according to CVS. So I'd suggest to replace 'vp' with 'ovp' in the patch above, for the sake of clarity and consistency. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net
Seemingly Similar Threads
- FreeBSD Security Advisory FreeBSD-SA-05:02.sendfile
- panic possibly related to soft updates? (4.8-STABLE, Jun 12 2003)
- 4.9 RC1 (i386) mplayer induced panic
- win 10 client on linux pdc, join domain ok, logon script fails to run
- FreeBSD Security Advisory FreeBSD-SA-02:35.ffs