Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Aug 2019 16:01:39 -0600
From:      Ian Lepore <ian@freebsd.org>
To:        Eugene Grosbein <eugen@grosbein.net>, freebsd-security@freebsd.org
Cc:        Freebsd hackers list <freebsd-hackers@freebsd.org>
Subject:   Re: FreeBSD Security Advisory FreeBSD-SA-19:23.midi
Message-ID:  <1909279dfc6002f6c21ff8e92ca2925511dca322.camel@freebsd.org>
In-Reply-To: <f19d3f62-940c-7888-b379-f416dfc45cac@grosbein.net>
References:  <20190820201257.7A9D41F8B7@freefall.freebsd.org> <f19d3f62-940c-7888-b379-f416dfc45cac@grosbein.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2019-08-21 at 04:55 +0700, Eugene Grosbein wrote:
> 21.08.2019 3:12, FreeBSD Security Advisories wrote:
> 
> [skip]
> 
> > IV.  Workaround
> > 
> > No workaround is available.  Custom kernels without "device sound"
> > are not vulnerable.
> 
> Is it true that there is no way to disable vulnerable and unneeded
> device driver
> built in GENERIC other that through rebuilding the kernel?
> 
> I remember that pre-4.x versions of FreeBSD had visual VGA-based pre-
> boot configurator
> allowing to disable any compiled-in device driver. Don't
> device.hints(5) or loader(8) have means to do so?
> 
> These days GENERIC have LOTS of drivers and it's convenient but
> unsafe.
> 

"No workaround" just seems to be wrong.  Aside from setting the
disabled hint to turn off the driver (or using devctl to turn it off on
a live system), the exploit also requires opening /dev/midistat, so a
viable workaround is to change its permissions so that users can't open
it.

-- Ian




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1909279dfc6002f6c21ff8e92ca2925511dca322.camel>