public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: R0b0t1 <r030t1@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Linux USB security holes.
Date: Tue, 7 Nov 2017 23:49:09 -0600	[thread overview]
Message-ID: <CAAD4mYjqpT8CLPSfsvHOOdaRSbacW6aJQc-4Wnde6iV1v45Y4w@mail.gmail.com> (raw)
In-Reply-To: <65c1af14-a224-4c9f-1ca8-eca4ccc71d0f@gmail.com>

On Tue, Nov 7, 2017 at 11:08 PM, Dale <rdalek1967@gmail.com> wrote:
> Howdy,
>
> I ran up on this link.  Is there any truth to it and should any of us
> Gentooers be worried about it?
>
> http://www.theregister.co.uk/2017/11/07/linux_usb_security_bugs/
>
> Isn't Linux supposed to be more secure than this??
>

In theory. There was no comment on the existence of such bugs in the
Windows driver stack, but they likely exist. However, note:

"The impact is quite limited, all the bugs require physical access to
trigger," said Konovalov. "Most of them are denial-of-service, except
for a few that might be potentially exploitable to execute code in the
kernel."

Which is typically what one should expect from bugs discovered by fuzzing.

These are issues which should be fixed, but keep in mind that there
has been (and still is) lots of kernel development that focuses on
isolating the kernel from itself. The reporting of these bugs will
likely be used to make those mechanisms even better.


To compare, here is an "exploit" discovered in a monitor:
https://github.com/RedBalloonShenanigans/MonitorDarkly.

The prerequisites include having debug access to the monitor's
controller. Personally I am surprised this was presented at DefCon as
it does not really seem appropriate. At least the articles covering
the code should be reworded - it's exploiting the monitor almost the
same way you can exploit a car by driving it.

More and more security releases are starting to look like the above,
as the researchers and authors clamor for notability, which is
increasingly hard to find. I think the article you found strikes a
middle ground - the exploits are relevant in practice, but take a lot
of work to use.

Cheers,
     R0b0t1


  parent reply	other threads:[~2017-11-08  5:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-08  5:08 [gentoo-user] Linux USB security holes Dale
2017-11-08  5:48 ` Adam Carter
2017-11-08  5:49 ` R0b0t1 [this message]
2017-11-08 15:40   ` [gentoo-user] " Grant Edwards
2017-11-08  5:53 ` [gentoo-user] " J. Roeleveld
2017-11-08 19:35   ` [gentoo-user] " Ian Zimmerman
2017-11-09  6:10     ` J. Roeleveld
2017-11-08  6:02 ` [gentoo-user] " Dale
2017-11-08  6:10   ` R0b0t1
2017-11-08  6:48     ` R0b0t1
2017-11-08  7:24       ` Dale
2017-11-09 14:07         ` Taiidan
2017-11-08 15:23       ` Martin DiViaio
2017-11-08 21:02 ` Alan McKinnon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAD4mYjqpT8CLPSfsvHOOdaRSbacW6aJQc-4Wnde6iV1v45Y4w@mail.gmail.com \
    --to=r030t1@gmail.com \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox