Re: BadUSB discussion

[Yves-Alexis Perez <corsac () debian org>]

On ven., 2014-08-08 at 16:35 +0200, Willy Tarreau wrote:
> On Fri, Aug 08, 2014 at 06:36:12AM -0700, Greg KH wrote:
> > On Fri, Aug 08, 2014 at 02:20:21PM +0300, Dan Carpenter wrote:
> > > I'm surprised we haven't had any discussion about the recent BadUSB
> > > articles.
> > >
> > > http://arstechnica.com/security/2014/07/this-thumbdrive-hacks-computers-badusb-exploit-makes-devices-turn-evil/
> > > http://security.stackexchange.com/questions/64524/how-to-prevent-badusb-attacks-on-linux-desktop
> > >
> > > We could put a popup if there is a second keyboard attached to check
> > > that the person controlling the existing keyboard is aware of the second
> > > one.
> >
> > "popup" where?  Multi-seat machines wouldn't like that very much, as
> > would yubikeys (as was pointed out), or a raft of other USB devices that
> > export a keyboard device for the buttons they control (video cameras,
> > external speakers, barcode scanners, etc.)
>
> Also, keyboards are one aspect of the problem. The biggest aspect is not new and
> has been abused for years, which is the main reason why so many large companies
> physically remove (stick or desolder) USB ports : you're connecting a *device*
> to your system and there's no way to make that 100% safe using software only.
> With a bogus driver and a DMA-capable device, you can end up accessing kernel
> locations and causing a lot more discrete harm such as unlocking displays,
> changing UIDs of running processes, etc. And that's much harder to detect,
> especially in closed drivers or with closed systems.

What do you mean by DMA-capable device. Afaict USB devices can't do bus
mastering on the PCI Express bus, they can only request the USB
controller to do that for them. Did someone already managed to
sucessfully control DMA transfers from an USB device?

(it's still safer to have a configured I/OMMU, imho, but I'm pretty
unsure they could be switched on by default…)
>

> One more efficient solution could be to have a sysctl to disable hotplugging
> of USB devices, all of them.

Grsecurity supports that (see GRKERNSEC_DENYUSB, Brad basically checks a
sysctl during hub_port_connect_change()). Or you could use the
authorized_default Greg mentioned.

It also helps to disable module autoloading.

>  Software would then detect the new devices, and
> decide to load the drivers among a whitelist associated to a given port. The
> administrator could add new rules, and it could be the user for personal
> desktop PCs. But even then you still have the risk of the user not understanding
> what's happening and bindly clicking "OK".

As always, what's usually hard is the policy and the default behavior,
since a lot of people have different needs…

Regards,
-- 
Yves-Alexis

Attachment: signature.asc
Description: This is a digitally signed message part