Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Oct 2016 07:53:44 +0100
From:      "Robert N. M. Watson" <rwatson@FreeBSD.org>
To:        Pawel Jakub Dawidek <pjd@FreeBSD.org>
Cc:        Xin LI <delphij@gmail.com>, freebsd-security@freebsd.org
Subject:   Re: FreeBSD Security Advisory FreeBSD-SA-16:15.sysarch [REVISED]
Message-ID:  <0717BEFA-4E65-4990-AC50-FD80681C110C@FreeBSD.org>
In-Reply-To: <20161026061504.GH60006@garage.freebsd.pl>
References:  <20161025173641.BCDFD1911@freefall.freebsd.org> <20161026042748.GG60006@garage.freebsd.pl> <CAGMYy3v8KxuQfou0SmUNikghH-9NWfneoMPP_15F85WkDaUhKg@mail.gmail.com> <20161026061504.GH60006@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Pawel:

In general, my strong recommendation is against issuing advisories for =
local denial-of-service attacks, in part because it suggests we consider =
it a security guarantee of the system that those problems can be =
reliably prevented. At least in current operating-system designs, =
preventing local DoS is a very hard problem (not quite up there with =
covert channels, but certainly not something we can do reliably) =E2=80=94=
 and so I think it would be misleading to suggest to our users that they =
can expect them not to exist at all. If something is being widely =
exploited, then it might be appropriate to issue an errata update, but I =
think if it=E2=80=99s something obscure where a local user to trigger a =
panic (and there really is no escalation path to kernel privilege, for =
example), then I think an advisory would generally be a mistake. =
Otherwise we=E2=80=99d find that a huge number of our ordinary kernel =
bug fixes get reclassified as security patches requiring advisories, if =
nothing else!

(In this case, I=E2=80=99m not passing judgement one way or the other =
=E2=80=94 zeroing of arbitrary kernel memory can have more broad =
implications than a panic =E2=80=94 for example, you can imagine that if =
it were to zero a process credential, a process might start running =
unexpectedly as root. And what were once thought to be innocuous crashes =
due to NULL-pointer dereferences turn out not to be!)

Robert

> On 26 Oct 2016, at 07:15, Pawel Jakub Dawidek <pjd@FreeBSD.org> wrote:
>=20
> I'm pretty sure we didn't for unprivileged local DoS.
>=20
> Robert, can you help me here? Do I recall correctly?
>=20
> I remember one time when Colin did security advisory for unprivileged
> local DoS and we had a discussion back then that this is dangerous
> precedent, as users may start depending on it.
>=20
> On Tue, Oct 25, 2016 at 10:47:44PM -0700, Xin LI wrote:
>> It's unprivileged local DoS (if it's root DoS then we normally =
don't).
>>=20
>> On Tue, Oct 25, 2016 at 9:27 PM, Pawel Jakub Dawidek =
<pjd@freebsd.org> wrote:
>>> Hi guys,
>>>=20
>>> since when do we publish security advisories for local DoSes?
>>>=20
>>> On Tue, Oct 25, 2016 at 05:36:41PM +0000, FreeBSD Security =
Advisories wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA512
>>>>=20
>>>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>>>> FreeBSD-SA-16:15.sysarch [REVISED]                          =
Security Advisory
>>>>                                                          The =
FreeBSD Project
>>>>=20
>>>> Topic:          Incorrect argument validation in sysarch(2)
>>>>=20
>>>> Category:       core
>>>> Module:         kernel
>>>> Announced:      2016-10-25
>>>> Credits:        Core Security, ahaha from Chaitin Tech
>>>> Affects:        All supported versions of FreeBSD.
>>>> Corrected:      2016-10-25 17:14:50 UTC (stable/11, 11.0-STABLE)
>>>>                2016-10-25 17:11:20 UTC (releng/11.0, =
11.0-RELEASE-p2)
>>>>                2016-10-25 17:16:08 UTC (stable/10, 10.3-STABLE)
>>>>                2016-10-25 17:11:15 UTC (releng/10.3, =
10.3-RELEASE-p11)
>>>>                2016-10-25 17:11:11 UTC (releng/10.2, =
10.2-RELEASE-p24)
>>>>                2016-10-25 17:11:07 UTC (releng/10.1, =
10.1-RELEASE-p41)
>>>>                2016-10-25 17:16:58 UTC (stable/9, 9.3-STABLE)
>>>>                2016-10-25 17:11:02 UTC (releng/9.3, =
9.3-RELEASE-p49)
>>>> CVE Name:       CVE-2016-1885
>>>>=20
>>>> For general information regarding FreeBSD Security Advisories,
>>>> including descriptions of the fields above, security branches, and =
the
>>>> following sections, please visit =
<URL:https://security.FreeBSD.org/>.
>>>>=20
>>>> 0.   Revision history
>>>>=20
>>>> v1.0  2016-03-16 Initial release.
>>>> v1.1  2016-10-25 Revised patch to address a problem pointed out by
>>>>                 ahaha from Chaitin Tech.
>>>>=20
>>>> I.   Background
>>>>=20
>>>> The IA-32 architecture allows programs to define segments, which =
provides
>>>> based and size-limited view into the program address space.  The
>>>> memory-resident processor structure, called Local Descriptor Table,
>>>> usually abbreviated LDT, contains definitions of the segments.  =
Since
>>>> incorrect or malicious segments would breach system integrity, =
operating
>>>> systems do not provide processes direct access to the LDT, instead
>>>> they provide system calls which allow controlled installation and =
removal
>>>> of segments.
>>>>=20
>>>> II.  Problem Description
>>>>=20
>>>> A special combination of sysarch(2) arguments, specify a request to
>>>> uninstall a set of descriptors from the LDT.  The start descriptor
>>>> is cleared and the number of descriptors are provided.  Due to lack
>>>> of sufficient bounds checking during argument validity =
verification,
>>>> unbound zero'ing of the process LDT and adjacent memory can be =
initiated
>>>> from usermode.
>>>>=20
>>>> III. Impact
>>>>=20
>>>> This vulnerability could cause the kernel to panic. In addition it =
is
>>>> possible to perform a local Denial of Service against the system by
>>>> unprivileged processes.
>>>>=20
>>>> IV.  Workaround
>>>>=20
>>>> No workaround is available, but only the amd64 architecture is =
affected.
>>>>=20
>>>> V.   Solution
>>>>=20
>>>> Perform one of the following:
>>>>=20
>>>> 1) Upgrade your vulnerable system to a supported FreeBSD stable or
>>>> release / security branch (releng) dated after the correction date.
>>>>=20
>>>> Reboot is required.
>>>>=20
>>>> 2) To update your vulnerable system via a binary patch:
>>>>=20
>>>> Systems running a RELEASE version of FreeBSD platforms can be =
updated
>>>> via the freebsd-update(8) utility:
>>>>=20
>>>> # freebsd-update fetch
>>>> # freebsd-update install
>>>>=20
>>>> Reboot is required.
>>>>=20
>>>> 3) To update your vulnerable system via a source code patch:
>>>>=20
>>>> The following patches have been verified to apply to the applicable
>>>> FreeBSD release branches.
>>>>=20
>>>> [*** v1.1 NOTE ***] If your sources are not yet patched using the =
initially
>>>> published advisory patches, then you need to apply both =
sysarch.patch and
>>>> sysarch-01.patch.  If your sources are already updated, or patched =
with
>>>> patches from the initial advisory, then you need to apply =
sysarch-01.patch
>>>> only.
>>>>=20
>>>> a) Download the relevant patch from the location below, and verify =
the
>>>> detached PGP signature using your PGP utility.
>>>>=20
>>>> [ FreeBSD system not patched with original SA-16:15 patch]
>>>> # fetch https://security.FreeBSD.org/patches/SA-16:15/sysarch.patch
>>>> # fetch =
https://security.FreeBSD.org/patches/SA-16:15/sysarch.patch.asc
>>>> # gpg --verify sysarch.patch.asc
>>>>=20
>>>> [ FreeBSD system that has been patched with original SA-16:15 =
patch]
>>>> # fetch =
https://security.FreeBSD.org/patches/SA-16:15/sysarch-01.patch
>>>> # fetch =
https://security.FreeBSD.org/patches/SA-16:15/sysarch-01.patch.asc
>>>> # gpg --verify sysarch-01.patch.asc
>>>>=20
>>>> b) Apply the patch(es).  Execute the following commands as root for
>>>> every patch file downloaded:
>>>>=20
>>>> # cd /usr/src
>>>> # patch < /path/to/patch
>>>>=20
>>>> c) Recompile your kernel as described in
>>>> <URL:https://www.FreeBSD.org/handbook/kernelconfig.html>; and reboot =
the
>>>> system.
>>>>=20
>>>> VI.  Correction details
>>>>=20
>>>> The following list contains the correction revision numbers for =
each
>>>> affected branch.
>>>>=20
>>>> Branch/path                                                      =
Revision
>>>> - =
-------------------------------------------------------------------------
>>>> stable/9/                                                         =
r307941
>>>> releng/9.3/                                                       =
r307931
>>>> stable/10/                                                        =
r307940
>>>> releng/10.1/                                                      =
r307932
>>>> releng/10.2/                                                      =
r307933
>>>> releng/10.3/                                                      =
r307934
>>>> stable/11/                                                        =
r307938
>>>> releng/11.0/                                                      =
r307935
>>>> - =
-------------------------------------------------------------------------
>>>>=20
>>>> 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:
>>>>=20
>>>> # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
>>>>=20
>>>> Or visit the following URL, replacing NNNNNN with the revision =
number:
>>>>=20
>>>> <URL:https://svnweb.freebsd.org/base?view=3Drevision&revision=3DNNNNN=
N>
>>>>=20
>>>> VII. References
>>>>=20
>>>> <URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2016-1885>;
>>>>=20
>>>> The latest revision of this advisory is available at
>>>> =
<URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-16:15.sysarch.asc>=

>>>> -----BEGIN PGP SIGNATURE-----
>>>>=20
>>>> iQIcBAEBCgAGBQJYD5VZAAoJEO1n7NZdz2rnYT4QAMmnfUBnxiNHfzaEDMe2oU+H
>>>> WIVFzFtU5FTAm3wJ3JORU1euqhusDoB7D8nova30alM2bHHd86epBGgym1Q+hxR2
>>>> qTI+d8QimvQUWelz7DWPh0h3ZNlVfDxY8vKlr5SS0W/HOMjbG/O6U1AIw5p7cPaa
>>>> LkDpqo2IN8xBL6tJFUKNEQS/GzuU2HtfKhQK0/ojT4DW61AkOZn4SZzzYBz3iO4p
>>>> a8Otv4+aHzyNjTZRm/33SrFzdG0RZWyT/WXsEHlv5NiXVMPML+oY918jppqClkoO
>>>> pwjcneWTqgYrE4vvVOADKOlWyNa4jFmPQSW7MmNEaF4RMd8TMcE/cBTKOi41YuOp
>>>> la1JzvtWUnou7oQqy/xKr0S/Wa2x6ZhR4vBg28fkfrQhn55N+qqDicQ3F907dOm5
>>>> A0ERHKgImlWSGM+Sf2CJyrUJUNUye0bVQMhrM4e3psZ7Jr20IXjnhppr1mufCjTH
>>>> H+aEHv43o/1HuoltnjstiBZ/CZpFdIXkBpsHtzteZR2y+pmZFA9bB4uZeeML0mj3
>>>> /cxj8rgPRmcjk6nSsnLWhq2YEFAZBC/lv43wqSrXE9+BBpSh6zM5NCTPb50/dBqf
>>>> V553uuGEvJlHmOAoveXxYyxKcGpgZAcgJjWpAkCpoVxgdrbtLcPY5Z+8cy8fMO3G
>>>> YHOkZydbLPaXOXimZfut
>>>> =3DNWuL
>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> freebsd-security-notifications@freebsd.org mailing list
>>>> =
https://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications
>>>> To unsubscribe, send any mail to =
"freebsd-security-notifications-unsubscribe@freebsd.org"
>>>=20
>>> --
>>> Pawel Jakub Dawidek                       =
http://www.wheelsystems.com
>>> FreeBSD committer                         http://www.FreeBSD.org
>>> Am I Evil? Yes, I Am!                     http://mobter.com
>=20
> --=20
> Pawel Jakub Dawidek                       http://www.wheelsystems.com
> FreeBSD committer                         http://www.FreeBSD.org
> Am I Evil? Yes, I Am!                     http://mobter.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0717BEFA-4E65-4990-AC50-FD80681C110C>