freebsd security - Oct 2014 - BadUSB - On Accessories that Turn Evil, by Karsten Nohl + Jakob Lell

Hi freebsd-usb at freebsd.org, 		(I suggest replies to usb@)
cc: freebsd-security at freebsd.org	FYI

Ref. article on BadUSB pan OS (non FreeBSD specific) security loophole
	http://www.bbc.com/news/technology-29475566
Dated  6 October 2014 Last updated at 15:29 GMT 

I found https://github.com/search?utf8=%E2%9C%93&q=BadUSB

Then viewed https://www.youtube.com/watch?v=nuruzFqMgIw
	( Which BTW plays nicely inc. sound on FreeBSD-9.2-RELEASE
	+ firefox without any flash installed (certainly no
	ports/graphics/gnash)

A fascinating video by Lecturers Karsten Nohl & Jacob Lell at Black Hat 
USA 2014, Run time 44:30 ) 
  (PS for non native English spekers on this global list, dont worry if 
  you find Jacob's accent hard, Karsten resumes for last 3rd, listen on :-)

It seems USB controllers (8041 or so based) can first masquerade
one device, then pause & masquerade another device type.  This is
an OS independent security list. Lecturers includes both demo of
an MS to Linux contamination, & consideration of other scenarios.
A predominant USB controller manufacturer in Taipei was not happy.

The lecturers didn't discuss MS or Linux or Android smart phone
protection schemes (except to allude to the danger of someone saying
"Can I plug in my smart phone to your PC to charge it ?".

It can't be ignored as a smart phone exploit: the demo wasn't with a
smart phone but a `dumb' stick. 

One can't get some protection by checking for sernum connecting, as devd
shows:
- my USB to PS2 adapter (vendor=0x04b4 product=0x8081) emits sernum=""
- my real USB "Havit" keyboard (vendor=0x1241 product=0x1203) emits
sernum=""

For FreeBSD,
  I guess for serious security, every new device that is connected
  & recognised by /sbin/devd should in future be personaly authorised
  by a human !  One can no longer trust what reports itself to be
  eg a keyboard to actually Be a keyboard, etc.

  /usr/src/etc/devd/*.conf & my own .conf do Not meet that awkward
  security requirement... yet. I guess we'll need a couple of hooks
  that support Yes/No, one from cli & one for within X11.

There's no security warning section in
	http://en.wikipedia.org/wiki/Flash_memory

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix'78 C Sys Eng Consultant Munich
http://berklix.com
 Indent previous with "> ".  Interleave reply paragraphs like a
play script.
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.
		ShellShock - http://www.berklix.com/~jhs/bash/

fwd to HardenedBSD Developers

On 10/6/14, Julian H. Stacey <jhs at berklix.com>
wrote:
> Hi freebsd-usb at freebsd.org, 		(I suggest replies to usb@)
> cc: freebsd-security at freebsd.org	FYI
>
> Ref. article on BadUSB pan OS (non FreeBSD specific) security loophole
> 	http://www.bbc.com/news/technology-29475566
> Dated  6 October 2014 Last updated at 15:29 GMT
>
> I found https://github.com/search?utf8=%E2%9C%93&q=BadUSB
>
> Then viewed https://www.youtube.com/watch?v=nuruzFqMgIw
> 	( Which BTW plays nicely inc. sound on FreeBSD-9.2-RELEASE
> 	+ firefox without any flash installed (certainly no
> 	ports/graphics/gnash)
>
> A fascinating video by Lecturers Karsten Nohl & Jacob Lell at Black Hat
> USA 2014, Run time 44:30 )
>   (PS for non native English spekers on this global list, dont worry if
>   you find Jacob's accent hard, Karsten resumes for last 3rd, listen on
:-)
>
> It seems USB controllers (8041 or so based) can first masquerade
> one device, then pause & masquerade another device type.  This is
> an OS independent security list. Lecturers includes both demo of
> an MS to Linux contamination, & consideration of other scenarios.
> A predominant USB controller manufacturer in Taipei was not happy.
>
> The lecturers didn't discuss MS or Linux or Android smart phone
> protection schemes (except to allude to the danger of someone saying
> "Can I plug in my smart phone to your PC to charge it ?".
>
> It can't be ignored as a smart phone exploit: the demo wasn't with
a
> smart phone but a `dumb' stick.
>
> One can't get some protection by checking for sernum connecting, as
devd
> shows:
> - my USB to PS2 adapter (vendor=0x04b4 product=0x8081) emits
sernum=""
> - my real USB "Havit" keyboard (vendor=0x1241 product=0x1203)
emits
> sernum=""
>
> For FreeBSD,
>   I guess for serious security, every new device that is connected
>   & recognised by /sbin/devd should in future be personaly authorised
>   by a human !  One can no longer trust what reports itself to be
>   eg a keyboard to actually Be a keyboard, etc.
>
>   /usr/src/etc/devd/*.conf & my own .conf do Not meet that awkward
>   security requirement... yet. I guess we'll need a couple of hooks
>   that support Yes/No, one from cli & one for within X11.
>
> There's no security warning section in
> 	http://en.wikipedia.org/wiki/Flash_memory
>
> Cheers,
> Julian
> --
> Julian Stacey, BSD Linux Unix'78 C Sys Eng Consultant Munich
> http://berklix.com
>  Indent previous with "> ".  Interleave reply paragraphs like
a play
> script.
>  Send plain text, not quoted-printable, HTML, base64, or
> multipart/alternative.
> 		ShellShock - http://www.berklix.com/~jhs/bash/
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at
freebsd.org"
>

--------
In message <201410061956.s96Ju8S3089675 at fire.js.berklix.net>,
"Julian H. Stacey
" writes:
>For FreeBSD,
>  I guess for serious security, every new device that is connected
>  & recognised by /sbin/devd should in future be personaly authorised
>  by a human !  One can no longer trust what reports itself to be
>  eg a keyboard to actually Be a keyboard, etc.
"no longer" ?

When you could you *ever* trust a USB device about anything ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.