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) — 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’s 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’d 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’m not passing judgement one way or the other — zeroing of arbitrary kernel memory can have more broad implications than a panic — 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 <p...@freebsd.org> wrote: > > I'm pretty sure we didn't for unprivileged local DoS. > > Robert, can you help me here? Do I recall correctly? > > 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. > > 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). >> >> On Tue, Oct 25, 2016 at 9:27 PM, Pawel Jakub Dawidek <p...@freebsd.org> >> wrote: >>> Hi guys, >>> >>> since when do we publish security advisories for local DoSes? >>> >>> On Tue, Oct 25, 2016 at 05:36:41PM +0000, FreeBSD Security Advisories wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA512 >>>> >>>> ============================================================================= >>>> FreeBSD-SA-16:15.sysarch [REVISED] Security >>>> Advisory >>>> The FreeBSD >>>> Project >>>> >>>> Topic: Incorrect argument validation in sysarch(2) >>>> >>>> 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 >>>> >>>> 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/>. >>>> >>>> 0. Revision history >>>> >>>> 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. >>>> >>>> I. Background >>>> >>>> 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. >>>> >>>> II. Problem Description >>>> >>>> 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. >>>> >>>> III. Impact >>>> >>>> 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. >>>> >>>> IV. Workaround >>>> >>>> No workaround is available, but only the amd64 architecture is affected. >>>> >>>> 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. >>>> >>>> Reboot is required. >>>> >>>> 2) To update your vulnerable system via a binary patch: >>>> >>>> Systems running a RELEASE version of FreeBSD platforms can be updated >>>> via the freebsd-update(8) utility: >>>> >>>> # freebsd-update fetch >>>> # freebsd-update install >>>> >>>> Reboot is required. >>>> >>>> 3) To update your vulnerable system via a source code patch: >>>> >>>> The following patches have been verified to apply to the applicable >>>> FreeBSD release branches. >>>> >>>> [*** 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. >>>> >>>> a) Download the relevant patch from the location below, and verify the >>>> detached PGP signature using your PGP utility. >>>> >>>> [ 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 >>>> >>>> [ 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 >>>> >>>> b) Apply the patch(es). Execute the following commands as root for >>>> every patch file downloaded: >>>> >>>> # cd /usr/src >>>> # patch < /path/to/patch >>>> >>>> c) Recompile your kernel as described in >>>> <URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the >>>> system. >>>> >>>> VI. Correction details >>>> >>>> The following list contains the correction revision numbers for each >>>> affected branch. >>>> >>>> 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 >>>> - ------------------------------------------------------------------------- >>>> >>>> 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:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN> >>>> >>>> VII. References >>>> >>>> <URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1885> >>>> >>>> The latest revision of this advisory is available at >>>> <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-16:15.sysarch.asc> >>>> -----BEGIN PGP SIGNATURE----- >>>> >>>> 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 >>>> =NWuL >>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> freebsd-security-notificati...@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications >>>> To unsubscribe, send any mail to >>>> "freebsd-security-notifications-unsubscr...@freebsd.org" >>> >>> -- >>> Pawel Jakub Dawidek http://www.wheelsystems.com >>> FreeBSD committer http://www.FreeBSD.org >>> Am I Evil? Yes, I Am! http://mobter.com > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://mobter.com _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
