Date: Wed, 26 Oct 2016 11:15:42 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "Robert N. M. Watson" <rwatson@FreeBSD.org>, freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:15.sysarch [REVISED] Message-ID: <20161026091541.GI60006@garage.freebsd.pl> In-Reply-To: <20161026081835.GR54029@kib.kiev.ua> References: <20161025173641.BCDFD1911@freefall.freebsd.org> <20161026042748.GG60006@garage.freebsd.pl> <CAGMYy3v8KxuQfou0SmUNikghH-9NWfneoMPP_15F85WkDaUhKg@mail.gmail.com> <20161026061504.GH60006@garage.freebsd.pl> <0717BEFA-4E65-4990-AC50-FD80681C110C@FreeBSD.org> <20161026081835.GR54029@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--sLx0z+5FKKtIVDwd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 26, 2016 at 11:18:35AM +0300, Konstantin Belousov wrote: > On Wed, Oct 26, 2016 at 07:53:44AM +0100, Robert N. M. Watson wrote: > > Hi Pawel: > >=20 > > 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 pre= vented. At least in current operating-system designs, preventing local DoS = is a very hard problem (not quite up there with covert channels, but certai= nly not something we can do reliably) ??? and so I think it would be mislea= ding 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 is= sue 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 mist= ake. Otherwise we???d find that a huge number of our ordinary kernel bug fi= xes get reclassified as security patches requiring advisories, if nothing e= lse! > >=20 > > (In this case, I???m not passing judgement one way or the other ??? zer= oing of arbitrary kernel memory can have more broad implications than a pan= ic ??? for example, you can imagine that if it were to zero a process crede= ntial, a process might start running unexpectedly as root. And what were on= ce thought to be innocuous crashes due to NULL-pointer dereferences turn ou= t not to be!) >=20 > It is not quite arbitrary kernel memory, memory is adjanced to the > region allocated with kmem_malloc(kernel_arena), which puts the > allocated chunk aside from the typical kernel allocations. In fact, most > likely the allocated chunk is followed by an unmapped page, which means > that attempt to zero past the end of legit chunk traps. In other words, > I consider the escalation of the issue unlikely or, at least, hard. >=20 > FWIW, I asked the same question as Pawel when initial SA was created. > The answer was not technical but satisfactory. I'd definiately prefer to have strict rules in this area that we always follow. "Sometimes" publishing SAs for local DoS sends wrong message to the users who may start to depend on them and to the people who report those kind of bugs, who can accuse us of trying to lower number of SAs on purpose. Note that the latter already happend in the past, AFAIR, where we were committing fixes and later publish SAs - the time between commit and SA publication gave a room to people to make those kind of accusations. This is the reason we now try to commit fix and publish SA at the same time, isn't it? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --sLx0z+5FKKtIVDwd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJYEHQ9AAoJEJVLhSuxKFt14S8QAK8+T1qmGBBBLUdN9oyk0Dd3 It3cT74xqLPZxAyOBTuKRMRozX6VF+GTS51C955Kmp/lS5dKrOgBnyRYzvEdwZ/I o5QmnKC5uOd6beJqMbgJ5cEvTpGd/HKqIffvKjRliYOJ9UwSbKtvmv4ViDa9ziQ1 JPru4wP4aySD1WrOLo9InKgGyBOONYWi2oQa7zvEPuBVuJxMy53irC7sqRhqNwMv AgqACB0r2DmmK521PI/FktDXPr+W3aQNhz8IeOukX//u4PZDzO8RcTR6hbRi5lcZ vvwT9YsGUqP06E+jr9fO4QlBHpf5B2d4hBfSPVJ7MhYytQu7Av622gDRTKucsUjz rf9Rf3ezQiS7fqoA2IfQhwOd/0lCh4G7yl9+5M5ZOYAdzVeFyUfGQmGYepH9hirH 1ijobaY801NRB1o0pPyMZZtNIBXyupcAI2vELyPDKTefGDoJaGHquLGqXN8YTfuv zOqUSg+UdmO6CII1/2WUJR2JpqA3vroS/lVCdLPeYl0r5zTY00MzcBiUx23C0f1u 6y0OAmQ8hPeOL3cDANF0uPproiUijhY+71Z1Lk//IteVIC2DdXiEhRxzoHW382lv Rrn3nrA9hmj6kTASLTKJ9hc+lAff30HuxC+rkZr/RyZtQXjf83Qq4/De3+jRh6Ht CDM9dzxIysk5s3auROVl =LAPy -----END PGP SIGNATURE----- --sLx0z+5FKKtIVDwd--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161026091541.GI60006>