Fix the length calculation for the final block of a sendfile(2)

transmission which could be tricked into rounding up to the nearest
page size, leaking up to a page of kernel memory.  [13:11]

In IPv6 and NetATM, stop SIOCSIFADDR, SIOCSIFBRDADDR, SIOCSIFDSTADDR
and SIOCSIFNETMASK at the socket layer rather than pass them on to the
link layer without validation or credential checks.  [SA-13:12]

Prevent cross-mount hardlinks between different nullfs mounts of the
same underlying filesystem.  [SA-13:13]

Security:	CVE-2013-5666
Security:	FreeBSD-SA-13:11.sendfile
Security:	CVE-2013-5691
Security:	FreeBSD-SA-13:12.ifioctl
Security:	CVE-2013-5710
Security:	FreeBSD-SA-13:13.nullfs
Approved by:	so
This commit is contained in:
Dag-Erling Smørgrav 2013-09-10 10:31:23 +00:00
parent e8346ce7d0
commit c4d9a19be3
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=42642
12 changed files with 620 additions and 0 deletions

View file

@ -0,0 +1,126 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-SA-13:11.sendfile Security Advisory
The FreeBSD Project
Topic: Kernel memory disclosure in sendfile(2)
Category: core
Module: sendfile
Announced: 2013-09-10
Credits: Ed Maste
Affects: FreeBSD 9.2-RC1 and 9.2-RC2
Corrected: 2013-09-10 10:07:21 UTC (stable/9, 9.2-STABLE)
2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC1-p2)
2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC2-p2)
CVE Name: CVE-2013-5666
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.
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
On affected systems, if the length passed to sendfile(2) is non-zero
and greater than the length of the file being transmitted, sendfile(2)
will pad the transmission up to the requested length or the next
pagesize boundary, whichever is smaller.
The content of the additional bytes transmitted in this manner depends
on the underlying filesystem, but may potentially include information
useful to an attacker.
III. Impact
An unprivileged user with the ability to run arbitrary code may be
able to obtain arbitrary kernel memory contents.
IV. Workaround
No workaround is available.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date.
2) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 9.2-STABLE]
# fetch http://security.FreeBSD.org/patches/SA-13:11/sendfile-9.2-stable.patch
# fetch http://security.FreeBSD.org/patches/SA-13:11/sendfile-9.2-stable.patch.asc
# gpg --verify sendfile-9.2-stable.patch.asc
[FreeBSD 9.2-RC1 and 9.2-RC2]
# fetch http://security.FreeBSD.org/patches/SA-13:11/sendfile-9.2-rc.patch
# fetch http://security.FreeBSD.org/patches/SA-13:11/sendfile-9.2-rc.patch.asc
# gpg --verify sendfile-9.2-rc.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.
3) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/9/ r255443
releng/9.2/ r255444
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
<URL:http://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
VII. References
<URL:http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5666>
The latest revision of this advisory is available at
<URL:http://security.FreeBSD.org/advisories/FreeBSD-SA-13:11.sendfile.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (FreeBSD)
iEYEARECAAYFAlIu8rIACgkQFdaIBMps37K01ACgmwaW3PZhjDqWSlTHusjIPNVy
A/YAn3DFUAvlX8sH89taM+sedjbD5In8
=gZwu
-----END PGP SIGNATURE-----

View file

@ -0,0 +1,150 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-SA-13:12.ifioctl Security Advisory
The FreeBSD Project
Topic: Insufficient credential checks in network ioctl(2)
Category: core
Module: sys_netinet6 sys_netatm
Announced: 2013-09-10
Credits: Loganaden Velvindron
Gleb Smirnoff
Affects: All supported versions of FreeBSD.
Corrected: 2013-09-10 10:07:21 UTC (stable/9, 9.2-STABLE)
2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC1-p2)
2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC2-p2)
2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC3-p1)
2013-09-10 10:15:33 UTC (releng/9.1, 9.1-RELEASE-p7)
2013-09-10 10:12:09 UTC (stable/8, 8.4-STABLE)
2013-09-10 10:14:19 UTC (releng/8.4, 8.4-RELEASE-p4)
2013-09-10 10:13:14 UTC (releng/8.3, 8.3-RELEASE-p11)
CVE Name: CVE-2013-5691
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.
I. Background
The ioctl(2) system call allows an application to perform device- or
protocol-specific operations through a file or socket descriptor
associated with a specific device or protocol.
The SIOCSIFADDR, SIOCSIFBRDADDR, SIOCSIFDSTADDR and SIOCSIFNETMASK
ioctl requests are used to associate a network address, broadcast
address, destination address (for point-to-point interfaces) or
netmask with an interface. They operate on the assumption that each
interface only has one address per protocol, and are therefore of
limited use for IPv4, where interfaces may have more than one address.
They were never implemented for IPv6, where interfaces nearly always
have at least two, and in many cases three, addresses; nor were they
ever implemented for ATM.
II. Problem Description
As is commonly the case, the IPv6 and ATM network layer ioctl request
handlers are written in such a way that an unrecognized request is
passed on unmodified to the link layer, which will either handle it or
return an error code.
Network interface drivers, however, assume that the SIOCSIFADDR,
SIOCSIFBRDADDR, SIOCSIFDSTADDR and SIOCSIFNETMASK requests have been
handled at the network layer, and therefore do not perform input
validation or verify the caller's credentials. Typical link-layer
actions for these requests may include marking the interface as "up"
and resetting the underlying hardware.
III. Impact
An unprivileged user with the ability to run arbitrary code can cause
any network interface in the system to perform the link layer actions
associated with a SIOCSIFADDR, SIOCSIFBRDADDR, SIOCSIFDSTADDR or
SIOCSIFNETMASK ioctl request; or trigger a kernel panic by passing a
specially crafted address structure which causes a network interface
driver to dereference an invalid pointer.
Although this has not been confirmed, the possibility that an attacker
may be able to execute arbitrary code in kernel context can not be
ruled out.
IV. Workaround
No workaround is available.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date.
2) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/SA-13:12/ifioctl.patch
# fetch http://security.FreeBSD.org/patches/SA-13:12/ifioctl.patch.asc
# gpg --verify ifioctl.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.
3) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/8/ r255445
releng/8.3/ r255446
releng/8.4/ r255447
stable/9/ r255443
releng/9.1/ r255448
releng/9.2/ r255444
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
<URL:http://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
VII. References
<URL:http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5691>
The latest revision of this advisory is available at
<URL:http://security.FreeBSD.org/advisories/FreeBSD-SA-13:12.ifioctl.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (FreeBSD)
iEYEARECAAYFAlIu8rUACgkQFdaIBMps37ImRQCdGUcSBvK6+kAN69aGChHT6fVb
YI4AoJNveN9PSowTG0NnUkPJR9oJimZT
=xb3g
-----END PGP SIGNATURE-----

View file

@ -0,0 +1,139 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-SA-13:13.nullfs Security Advisory
The FreeBSD Project
Topic: Cross-mount links between nullfs(5) mounts
Category: core
Module: nullfs
Announced: 2013-09-10
Credits: Mateusz Guzik
Konstantin Belousov
Affects: All supported versions of FreeBSD.
Corrected: 2013-09-10 10:07:21 UTC (stable/9, 9.2-STABLE)
2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC1-p2)
2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC2-p2)
2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC3-p1)
2013-09-10 10:15:33 UTC (releng/9.1, 9.1-RELEASE-p7)
2013-09-10 10:12:09 UTC (stable/8, 8.4-STABLE)
2013-09-10 10:14:19 UTC (releng/8.4, 8.4-RELEASE-p4)
2013-09-10 10:13:14 UTC (releng/8.3, 8.3-RELEASE-p11)
CVE Name: CVE-2013-5710
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.
I. Background
The nullfs(5) filesystem allows all or a part of an already mounted
filesystem to be made available in a different part of the global
filesystem namespace. It is commonly used to make a set of files
available to multiple chroot(2) or jail(2) environments without
replicating the files in each environment. A common idiom, described
in the FreeBSD Handbook, is to mount one subtree of a filesystem
read-only within a jail's filesystem namespace, and mount a different
subtree of the same filesystem read-write.
II. Problem Description
The nullfs(5) implementation of the VOP_LINK(9) VFS operation does not
check whether the source and target of the link are both in the same
nullfs instance. It is therefore possible to create a hardlink from a
location in one nullfs instance to a file in another, as long as the
underlying (source) filesystem is the same.
III. Impact
If multiple nullfs views into the same filesystem are mounted in
different locations, a user with read access to one of these views and
write access to another will be able to create a hard link from the
latter to a file in the former, even though they are, from the user's
perspective, different filesystems. The user may thereby gain write
access to files which are nominally on a read-only filesystem.
IV. Workaround
No workaround is available, but systems which do not use the nullfs(5)
filesystem, or do not null-mount different subtrees of the same source
filesystem with different permissions, are not vulnerable.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date.
2) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/SA-13:13/nullfs.patch
# fetch http://security.FreeBSD.org/patches/SA-13:13/nullfs.patch.asc
# gpg --verify nullfs.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.
3) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/8/ r255445
releng/8.3/ r255446
releng/8.4/ r255447
stable/9/ r255443
releng/9.1/ r255448
releng/9.2/ r255444
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
<URL:http://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
VII. References
<URL:http://www.freebsd.org/doc/en/books/handbook/jails-application.html>
<URL:http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5710>
The latest revision of this advisory is available at
<URL:http://security.FreeBSD.org/advisories/FreeBSD-SA-13:13.nullfs.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (FreeBSD)
iEYEARECAAYFAlIu8rgACgkQFdaIBMps37KX4QCgn/PjsnAZItGRi7CMbp2jlFvS
IokAniKX2FVr8xXuJPtrLdv+7syjCTQt
=Lj26
-----END PGP SIGNATURE-----

View file

@ -0,0 +1,20 @@
Index: sys/kern/uipc_syscalls.c
===================================================================
--- sys/kern/uipc_syscalls.c (revision 253912)
+++ sys/kern/uipc_syscalls.c (working copy)
@@ -2087,11 +2087,10 @@
* or the passed in nbytes.
*/
pgoff = (vm_offset_t)(off & PAGE_MASK);
- if (uap->nbytes)
- rem = (uap->nbytes - fsbytes - loopbytes);
- else
- rem = va.va_size -
- uap->offset - fsbytes - loopbytes;
+ rem = obj->un_pager.vnp.vnp_size - uap->offset;
+ if (uap->nbytes != 0)
+ rem = omin(rem, uap->nbytes);
+ rem -= fsbytes + loopbytes;
xfsize = omin(PAGE_SIZE - pgoff, rem);
xfsize = omin(space - loopbytes, xfsize);
if (xfsize <= 0) {

View file

@ -0,0 +1,7 @@
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (FreeBSD)
iEYEABECAAYFAlIuF7gACgkQFdaIBMps37LokwCcD0WafThPclpU1qRNCTzNhe61
S04AmwfYZwH8ZsCbTWFw1bZVOhcqim/m
=6DgA
-----END PGP SIGNATURE-----

View file

@ -0,0 +1,20 @@
Index: sys/kern/uipc_syscalls.c
===================================================================
--- sys/kern/uipc_syscalls.c (revision 255414)
+++ sys/kern/uipc_syscalls.c (working copy)
@@ -2126,11 +2126,10 @@
* or the passed in nbytes.
*/
pgoff = (vm_offset_t)(off & PAGE_MASK);
- if (uap->nbytes)
- rem = (uap->nbytes - fsbytes - loopbytes);
- else
- rem = va.va_size -
- uap->offset - fsbytes - loopbytes;
+ rem = va.va_size - uap->offset;
+ if (uap->nbytes != 0)
+ rem = omin(rem, uap->nbytes);
+ rem -= fsbytes + loopbytes;
xfsize = omin(PAGE_SIZE - pgoff, rem);
xfsize = omin(space - loopbytes, xfsize);
if (xfsize <= 0) {

View file

@ -0,0 +1,7 @@
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (FreeBSD)
iEYEABECAAYFAlIuF70ACgkQFdaIBMps37Ir2ACeJiObKBkQvyI/3HTotiQnx+7p
laYAoJZlhgNrqHbAiaDg5qjUbTPZCECa
=GX/T
-----END PGP SIGNATURE-----

View file

@ -0,0 +1,89 @@
Index: sys/net/if.c
===================================================================
--- sys/net/if.c (revision 254941)
+++ sys/net/if.c (working copy)
@@ -2553,11 +2553,23 @@
CURVNET_RESTORE();
return (EOPNOTSUPP);
}
+
+ /*
+ * Pass the request on to the socket control method, and if the
+ * latter returns EOPNOTSUPP, directly to the interface.
+ *
+ * Make an exception for the legacy SIOCSIF* requests. Drivers
+ * trust SIOCSIFADDR et al to come from an already privileged
+ * layer, and do not perform any credentials checks or input
+ * validation.
+ */
#ifndef COMPAT_43
error = ((*so->so_proto->pr_usrreqs->pru_control)(so, cmd,
data,
ifp, td));
- if (error == EOPNOTSUPP && ifp != NULL && ifp->if_ioctl != NULL)
+ if (error == EOPNOTSUPP && ifp != NULL && ifp->if_ioctl != NULL &&
+ cmd != SIOCSIFADDR && cmd != SIOCSIFBRDADDR &&
+ cmd != SIOCSIFDSTADDR && cmd != SIOCSIFNETMASK)
error = (*ifp->if_ioctl)(ifp, cmd, data);
#else
{
@@ -2601,7 +2613,9 @@
data,
ifp, td));
if (error == EOPNOTSUPP && ifp != NULL &&
- ifp->if_ioctl != NULL)
+ ifp->if_ioctl != NULL &&
+ cmd != SIOCSIFADDR && cmd != SIOCSIFBRDADDR &&
+ cmd != SIOCSIFDSTADDR && cmd != SIOCSIFNETMASK)
error = (*ifp->if_ioctl)(ifp, cmd, data);
switch (ocmd) {
Index: sys/netinet6/in6.c
===================================================================
--- sys/netinet6/in6.c (revision 254941)
+++ sys/netinet6/in6.c (working copy)
@@ -431,6 +431,18 @@
case SIOCGIFSTAT_ICMP6:
sa6 = &ifr->ifr_addr;
break;
+ case SIOCSIFADDR:
+ case SIOCSIFBRDADDR:
+ case SIOCSIFDSTADDR:
+ case SIOCSIFNETMASK:
+ /*
+ * Although we should pass any non-INET6 ioctl requests
+ * down to driver, we filter some legacy INET requests.
+ * Drivers trust SIOCSIFADDR et al to come from an already
+ * privileged layer, and do not perform any credentials
+ * checks or input validation.
+ */
+ return (EINVAL);
default:
sa6 = NULL;
break;
Index: sys/netnatm/natm.c
===================================================================
--- sys/netnatm/natm.c (revision 254941)
+++ sys/netnatm/natm.c (working copy)
@@ -339,6 +339,21 @@
npcb = (struct natmpcb *)so->so_pcb;
KASSERT(npcb != NULL, ("natm_usr_control: npcb == NULL"));
+ switch (cmd) {
+ case SIOCSIFADDR:
+ case SIOCSIFBRDADDR:
+ case SIOCSIFDSTADDR:
+ case SIOCSIFNETMASK:
+ /*
+ * Although we should pass any non-ATM ioctl requests
+ * down to driver, we filter some legacy INET requests.
+ * Drivers trust SIOCSIFADDR et al to come from an already
+ * privileged layer, and do not perform any credentials
+ * checks or input validation.
+ */
+ return (EINVAL);
+ }
+
if (ifp == NULL || ifp->if_ioctl == NULL)
return (EOPNOTSUPP);
return ((*ifp->if_ioctl)(ifp, cmd, arg));

View file

@ -0,0 +1,7 @@
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (FreeBSD)
iEYEABECAAYFAlIuF98ACgkQFdaIBMps37KefgCeNtxM4xIH3gYvoj4BbefvRoC8
I8gAnRT1I915xp4nk2lgWK+5HGoDqApO
=W+Ro
-----END PGP SIGNATURE-----

View file

@ -0,0 +1,28 @@
Index: sys/fs/nullfs/null_vnops.c
===================================================================
--- sys/fs/nullfs/null_vnops.c (revision 254941)
+++ sys/fs/nullfs/null_vnops.c (working copy)
@@ -858,6 +858,15 @@
return (error);
}
+static int
+null_link(struct vop_link_args *ap)
+{
+
+ if (ap->a_tdvp->v_mount != ap->a_vp->v_mount)
+ return (EXDEV);
+ return (null_bypass((struct vop_generic_args *)ap));
+}
+
/*
* Global vfs data structures
*/
@@ -871,6 +880,7 @@
.vop_getwritemount = null_getwritemount,
.vop_inactive = null_inactive,
.vop_islocked = vop_stdislocked,
+ .vop_link = null_link,
.vop_lock1 = null_lock,
.vop_lookup = null_lookup,
.vop_open = null_open,

View file

@ -0,0 +1,7 @@
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (FreeBSD)
iEYEABECAAYFAlIuGawACgkQFdaIBMps37J1OgCgm847iabfWVTdyCXAeXVQkK/g
ZR4AoJrz+a812XboghdqiTvVKVHUyD+b
=wGcC
-----END PGP SIGNATURE-----

View file

@ -7,6 +7,26 @@
<year>
<name>2013</name>
<month>
<name>9</name>
<day>
<name>10</name>
<advisory>
<name>FreeBSD-SA-13:13.nullfs</name>
</advisory>
<advisory>
<name>FreeBSD-SA-13:12.ifioctl</name>
</advisory>
<advisory>
<name>FreeBSD-SA-13:11.sendfile</name>
</advisory>
</day>
</month>
<month>
<name>8</name>