Re: FreeBSD Security Advisory FreeBSD-SA-19:23.midi

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD Security Advisory FreeBSD-SA-19:23.midi

Eugene Grosbein-10
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.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD Security Advisory FreeBSD-SA-19:23.midi

Ian Lepore-3
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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD Security Advisory FreeBSD-SA-19:23.midi

Mark Johnston-2
On Tue, Aug 20, 2019 at 04:01:39PM -0600, Ian Lepore wrote:

> 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.

Yeah, this was an oversight.  The SA text will be amended.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD Security Advisory FreeBSD-SA-19:23.midi

Eugene Grosbein-10
In reply to this post by Eugene Grosbein-10
30.08.2019 11:03, Bruce Evans wrote:

> The patch preserves some historical mistakes and adds some excessive
> verboseness about probe failures.  I'm still waiting for jhb to reply to
> mails on 30 Oct 2015 and 23 Jan 2018 asking for a review of this patch
> or better a complete fix.

Hmm... Maybe additional notification worth it :-)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD Security Advisory FreeBSD-SA-19:23.midi

John Baldwin
On 8/30/19 12:56 AM, Eugene Grosbein wrote:
> 30.08.2019 11:03, Bruce Evans wrote:
>
>> The patch preserves some historical mistakes and adds some excessive
>> verboseness about probe failures.  I'm still waiting for jhb to reply to
>> mails on 30 Oct 2015 and 23 Jan 2018 asking for a review of this patch
>> or better a complete fix.
>
> Hmm... Maybe additional notification worth it :-)

Hmm, I've used 'hint.foo.0.disabled=1' with many devices and it works fine.
devctl enable can "undo" the disable post-boot even.

It doesn't disable probing, only attaching once we know which driver a device
is going to use.  As far as I can tell, the patch makes it disable
DEVICE_PROBE as well, but the vast majority of DEVICE_PROBE routines are
idempotent.  Only a handful of legacy ISA drivers use 'return (0)' to try to
pass state from probe to attach via the softc.  Those drivers could choose to
check the disabled flag in their probe routine and/or be fixed to have
idempotent probe routines.  I think the latter is probably the best path
forward.

--
John Baldwin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD Security Advisory FreeBSD-SA-19:23.midi

Warner Losh
On Fri, Aug 30, 2019 at 10:06 AM John Baldwin <[hidden email]> wrote:

> On 8/30/19 12:56 AM, Eugene Grosbein wrote:
> > 30.08.2019 11:03, Bruce Evans wrote:
> >
> >> The patch preserves some historical mistakes and adds some excessive
> >> verboseness about probe failures.  I'm still waiting for jhb to reply to
> >> mails on 30 Oct 2015 and 23 Jan 2018 asking for a review of this patch
> >> or better a complete fix.
> >
> > Hmm... Maybe additional notification worth it :-)
>
> Hmm, I've used 'hint.foo.0.disabled=1' with many devices and it works fine.
> devctl enable can "undo" the disable post-boot even.
>
> It doesn't disable probing, only attaching once we know which driver a
> device
> is going to use.  As far as I can tell, the patch makes it disable
> DEVICE_PROBE as well, but the vast majority of DEVICE_PROBE routines are
> idempotent.  Only a handful of legacy ISA drivers use 'return (0)' to try
> to
> pass state from probe to attach via the softc.  Those drivers could choose
> to
> check the disabled flag in their probe routine and/or be fixed to have
> idempotent probe routines.  I think the latter is probably the best path
> forward.
>

The problem with disabling before PROBE is that if you have N foo devices,
hint.foo.0.disabled=1 will disable all of them as the probe routines all
return 'not me' and we try foo0 on each new instance... I'm pretty sure
that's why it's not done today and why I didn't do it when I added this
feature because how do you know you have foo0 until probe says 'yup, that's
mine'?

Most of the old ISA routines that returned 0 I think have been deleted.
Maybe all since they were for fussy hardware from before the plug and play
era...

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"