unfixable usb porthole

Post by Gene Heskett
Is there a move afoot to write a checker utility that determines if the
usb device its pointed at is vulnerable, and can therefore be reliably
blacklisted?

What do you mean by a "vulnerable" USB device?

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Gene Heskett

2014-10-17 00:18:26 UTC

On Thursday 16 October 2014 18:28:16 Greg KH did opine

Post by Gene Heskett
Is there a move afoot to write a checker utility that determines if
the usb device its pointed at is vulnerable, and can therefore be
reliably blacklisted?

What do you mean by a "vulnerable" USB device?

Thanks for the reply, Greg.

There is an exploitable error in the usb hardware/firmware, one that
nearly 100% of the devices have.

No one ever gave security a seconds thought when writing the usb std. As
described it is both hardware and firmware that will need to be addressed
for an effective fix.

See:

<http://www.wired.com/2014/10/code-published-for-unfixable-usb-attack/>

for an explanation much better than I seem to be doing. It went live
yesterday.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Clemens Ladisch

2014-10-17 06:49:05 UTC

Post by Gene Heskett
On Thursday 16 October 2014 18:28:16 Greg KH did opine

Post by Gene Heskett
Is there a move afoot to write a checker utility that determines if
the usb device its pointed at is vulnerable, and can therefore be
reliably blacklisted?

What do you mean by a "vulnerable" USB device?

There is an exploitable error in the usb hardware/firmware, one that
nearly 100% of the devices have.

That "error" is the fact that USB devices have a CPU which can execute
arbitrary code. The "BadUSB" guys have shown that several widely-used
USB sticks allow the PC to change their firmware, but building USB
devices with malicious firmware has _always_ been possible; the only
difference is that the hardware costs have gone down from $40 for
a Rubber Ducky to $10 for an off-the-shelf memory stick.

Post by Gene Heskett
No one ever gave security a seconds thought when writing the usb std. As
described it is both hardware and firmware that will need to be addressed
for an effective fix.

So you want to blacklist every device (USB or any other bus) that can be
connect to a PC? And outlaw general-purpose computers?

Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Gene Heskett

2014-10-17 08:53:57 UTC

On Friday 17 October 2014 02:49:05 Clemens Ladisch did opine

Post by Clemens Ladisch

Post by Gene Heskett
On Thursday 16 October 2014 18:28:16 Greg KH did opine

Post by Gene Heskett
Is there a move afoot to write a checker utility that determines if
the usb device its pointed at is vulnerable, and can therefore be
reliably blacklisted?

What do you mean by a "vulnerable" USB device?

There is an exploitable error in the usb hardware/firmware, one that
nearly 100% of the devices have.

Post by Gene Heskett
No one ever gave security a seconds thought when writing the usb std.
As described it is both hardware and firmware that will need to be
addressed for an effective fix.

So you want to blacklist every device (USB or any other bus) that can
be connect to a PC? And outlaw general-purpose computers?
Regards,
Clemens

I think the point they were trying to make is that the device packager,
who may not be the chip vendor, can put, if there is room in its flashrom,
a short commend that would, on plugging it in, cause the machine to
silently go out on the net and become part of a spam bot, or install a
keylogger, particularly dangerous for those of us who do our banking
online.

To completely ignore it seems like a mistake. Ideally it seems we would
need a new call into the driver, to have it reach in since its usually so
easy, and do a 64 bit crc on the flashrom, and compare that to a secured
copy of that crc. If they don't match, turn on the klaxons. Even that
would be easily defeatable in the real world, so it needs to be more
complex that that.

A users $0.02 Clemens. ATM I need to go get a new usb key and reformat it
in either fat32, or just plain fat with its 8.3 names as thats all a new
digital scope I just bought accepts. It cannot find its update files on a
vfat key. And since it is an Atten, its factory shipped firmware is
"buggier than a ten day old carcass". I have much better firmware for it,
but its apparently married to the older fat filesystem.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Greg KH

2014-10-17 09:24:22 UTC

Post by Gene Heskett
On Friday 17 October 2014 02:49:05 Clemens Ladisch did opine

Post by Clemens Ladisch

Post by Gene Heskett
On Thursday 16 October 2014 18:28:16 Greg KH did opine

Post by Gene Heskett
Is there a move afoot to write a checker utility that determines if
the usb device its pointed at is vulnerable, and can therefore be
reliably blacklisted?

What do you mean by a "vulnerable" USB device?

There is an exploitable error in the usb hardware/firmware, one that
nearly 100% of the devices have.

Post by Gene Heskett
No one ever gave security a seconds thought when writing the usb std.
As described it is both hardware and firmware that will need to be
addressed for an effective fix.

So you want to blacklist every device (USB or any other bus) that can
be connect to a PC? And outlaw general-purpose computers?
Regards,
Clemens

Again, no, a device can not "cause the machine to silently go out on the
net..." That's not possible, and if it is, then it's a bug in the
operating system, that needs to be fixed, and has nothing to do with the
USB specification at all.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Peter Stuge

2014-10-17 09:42:50 UTC

Gene,

Post by Gene Heskett
I think the point they were trying to make is that the device packager,
who may not be the chip vendor, can put, if there is room in its flashrom,
a short commend that would, on plugging it in, cause the machine to
silently go out on the net and become part of a spam bot, or install a
keylogger

Please spend a bit of time studying that 1.1 spec you have, or
actually I would recommend that you download the 2.0 spec instead:

http://www.usb.org/developers/docs/usb_20_070113.zip

Spend most of your time with chapters 5, 8 and 9.

Then spend time studying the EHCI spec. It teaches how the host
controller is programmed by the operating system.

It should become clear that what you describe just isn't possible.

Not everything that is published (on internet or elsewhere) is
actually correct.

Post by Greg KH
What needs to be "fixed"?

The procedure to update that firmware.
if when it is plugged in, it goes out and installs a keylogger, now
that is harming the user

"goes out" is not an established term in USB. I'm afraid you're not
making any sense.

//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Gene Heskett

2014-10-17 15:43:28 UTC

On Friday 17 October 2014 05:42:50 Peter Stuge did opine

Post by Peter Stuge
Gene,

Post by Gene Heskett
I think the point they were trying to make is that the device
packager, who may not be the chip vendor, can put, if there is room
in its flashrom, a short commend that would, on plugging it in,
cause the machine to silently go out on the net and become part of a
spam bot, or install a keylogger

Please spend a bit of time studying that 1.1 spec you have, or
http://www.usb.org/developers/docs/usb_20_070113.zip

Interesting read, I will learn much I think, thank you.

But I haven't finished it yet. Using okular to red what appears to be the
main pdf (650 pages), it died and showed only blank but framed pages at
about 150 pages into it. So I went into its menu's and set it for
aggressive memory use since I have 8Gb, and this 3.16.0 kernel is a 32 bit
PAE enabled build. That enabled it to display about 125 more pages, then
went back to blank pages.

Deciding to quit it and try acroread, it took down every bash shell on the
machine when I quit it!

So I rebooted, but they were not restored on the reboot, so I had to
restart all of my normally used shells by hand. That takes about 20
minutes because update-manager needed a run on all 3 machines that are
live on my local network on a 24/7 basis. jre/icetea & tzdata related
stuff this time.

Post by Peter Stuge
Spend most of your time with chapters 5, 8 and 9.
Then spend time studying the EHCI spec. It teaches how the host
controller is programmed by the operating system.
It should become clear that what you describe just isn't possible.
Not everything that is published (on internet or elsewhere) is
actually correct.

Post by Greg KH
What needs to be "fixed"?

The procedure to update that firmware.
if when it is plugged in, it goes out and installs a keylogger, now
that is harming the user

"goes out" is not an established term in USB. I'm afraid you're not
making any sense.
//Peter

I have bought keys that came with an autoexec.bat that looked like it was
going to install a keylogger already installed. So the threat, at least
to an M$ box, is there. But thats not how this exploit was described.
Maybe this is only a potential problem on an M$ box? At the least, it
needs a YMMV warning.

Thanks for the link Peter, it was appreciated. Now of course, its up to
me to understand it since I have reached that age where short term memory
is not always infallible, 80, so I have the missus make grocery lists on
dead tree sheets. :)

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Greg KH

2014-10-17 07:48:48 UTC

Post by Gene Heskett
On Thursday 16 October 2014 18:28:16 Greg KH did opine

Post by Gene Heskett
Is there a move afoot to write a checker utility that determines if
the usb device its pointed at is vulnerable, and can therefore be
reliably blacklisted?

What do you mean by a "vulnerable" USB device?

Thanks for the reply, Greg.
There is an exploitable error in the usb hardware/firmware, one that
nearly 100% of the devices have.

No there isn't, it's a specific design of the device, we have had
devices like this since the 1990's. This is nothing new at all, and
nothing that is a problem.

Post by Gene Heskett
No one ever gave security a seconds thought when writing the usb std.

As one who helped write a tiny portion of the spec, that's not true at
all. If you have specifics, I would be glad to discuss them.

Post by Gene Heskett
As described it is both hardware and firmware that will need to be
addressed for an effective fix.

What needs to be "fixed"?

Post by Gene Heskett
<http://www.wired.com/2014/10/code-published-for-unfixable-usb-attack/>
for an explanation much better than I seem to be doing. It went live
yesterday.

The only thing that is "new" is the fact that some people thought that
the firmware of a USB device could not be changed to work like something
else. Again, that's never been true, and is nothing that "hurts" the
operating system.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Gene Heskett

2014-10-17 09:01:51 UTC

On Friday 17 October 2014 03:48:48 Greg KH did opine

Post by Gene Heskett
On Thursday 16 October 2014 18:28:16 Greg KH did opine

Post by Gene Heskett
Is there a move afoot to write a checker utility that determines
if the usb device its pointed at is vulnerable, and can
therefore be reliably blacklisted?

What do you mean by a "vulnerable" USB device?

Thanks for the reply, Greg.
There is an exploitable error in the usb hardware/firmware, one that
nearly 100% of the devices have.

No there isn't, it's a specific design of the device, we have had
devices like this since the 1990's. This is nothing new at all, and
nothing that is a problem.

Post by Gene Heskett
No one ever gave security a seconds thought when writing the usb std.

As one who helped write a tiny portion of the spec, that's not true at
all. If you have specifics, I would be glad to discuss them.

I have a copy of the 1.1 specs, before they put it behind a paywall. I am
glad you did have a small hand in it, thanks.

Post by Gene Heskett
As described it is both hardware and firmware that will need to be
addressed for an effective fix.

What needs to be "fixed"?

The procedure to update that firmware.

Post by Gene Heskett
<http://www.wired.com/2014/10/code-published-for-unfixable-usb-attack
/>
for an explanation much better than I seem to be doing. It went live
yesterday.

Agreed, but if when it is plugged in, it goes out and installs a
keylogger, now that is harming the user even if the code to do it is 100%
nicely written legal code.

Post by Greg KH
thanks,
greg k-h

Thank you Greg.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Greg KH

2014-10-17 09:23:10 UTC

Post by Gene Heskett
On Friday 17 October 2014 03:48:48 Greg KH did opine

Post by Gene Heskett
On Thursday 16 October 2014 18:28:16 Greg KH did opine

Post by Gene Heskett
Is there a move afoot to write a checker utility that determines
if the usb device its pointed at is vulnerable, and can
therefore be reliably blacklisted?

What do you mean by a "vulnerable" USB device?

Thanks for the reply, Greg.
There is an exploitable error in the usb hardware/firmware, one that
nearly 100% of the devices have.

No there isn't, it's a specific design of the device, we have had
devices like this since the 1990's. This is nothing new at all, and
nothing that is a problem.

Post by Gene Heskett
No one ever gave security a seconds thought when writing the usb std.

As one who helped write a tiny portion of the spec, that's not true at
all. If you have specifics, I would be glad to discuss them.

I have a copy of the 1.1 specs, before they put it behind a paywall. I am
glad you did have a small hand in it, thanks.

There is no "paywall" for USB specs. All specs are "backwards
compatible", so the latest 3.0 spec has all of the 1.1 stuff in it as
well. It's just more stuff to wade through :)

Post by Gene Heskett
As described it is both hardware and firmware that will need to be
addressed for an effective fix.

What needs to be "fixed"?

The procedure to update that firmware.

That's vendor-specific, and again, isn't a big deal at all. I even
helped create the spec that allows that to happen in a standard way.
Linux supports that quite well.

Post by Gene Heskett
<http://www.wired.com/2014/10/code-published-for-unfixable-usb-attack
/>
for an explanation much better than I seem to be doing. It went live
yesterday.

Agreed, but if when it is plugged in, it goes out and installs a
keylogger,

Wait, how can a USB device "install a keylogger"? If that happens, then
that is a bug in the kernel. And yes, we did have a few bugs in that
area in the past, specifically we fixed them over the past year, but
that's a totally different thing than allowing the firmware of a device
to be changed.

Post by Gene Heskett
now that is harming the user even if the code to do it is 100%
nicely written legal code.

Again, there should never be a way for a USB device to arbitrarily
execute code on your processor. That's not part of the USB spec, and
does not happen on Linux at all. If it does, please let us know and it
will be fixed. So far, none of the "BadUSB" stuff actually does this,
so that is not an issue.

Beware of the press around this issue, it's very confusing, and
incorrect. This has been discussed in detail on the oss-security
mailing list a few months ago if you are interested and want to go read
the archives.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Gene Heskett

2014-10-17 09:35:27 UTC

On Friday 17 October 2014 05:23:10 Greg KH did opine

Post by Gene Heskett
On Friday 17 October 2014 03:48:48 Greg KH did opine

Post by Gene Heskett
On Thursday 16 October 2014 18:28:16 Greg KH did opine

Post by Gene Heskett
Is there a move afoot to write a checker utility that
determines if the usb device its pointed at is vulnerable,
and can therefore be reliably blacklisted?

What do you mean by a "vulnerable" USB device?

Thanks for the reply, Greg.
There is an exploitable error in the usb hardware/firmware, one
that nearly 100% of the devices have.

No there isn't, it's a specific design of the device, we have had
devices like this since the 1990's. This is nothing new at all,
and nothing that is a problem.

Post by Gene Heskett
No one ever gave security a seconds thought when writing the usb std.

As one who helped write a tiny portion of the spec, that's not true
at all. If you have specifics, I would be glad to discuss them.

I have a copy of the 1.1 specs, before they put it behind a paywall.
I am glad you did have a small hand in it, thanks.

There is no "paywall" for USB specs. All specs are "backwards
compatible", so the latest 3.0 spec has all of the 1.1 stuff in it as
well. It's just more stuff to wade through :)

I last looked about a year ago. The only link google could find was
behind a $25,000 paywall because you had to join the consortium to access
it. I was upset. OTOH I am not even the dot at the end of a sentence in
the grand scheme of monetizing something. I'd be grateful for a URL to the
pdf.

Post by Gene Heskett
As described it is both hardware and firmware that will need to
be addressed for an effective fix.

What needs to be "fixed"?

The procedure to update that firmware.

That's vendor-specific, and again, isn't a big deal at all. I even
helped create the spec that allows that to happen in a standard way.
Linux supports that quite well.

Post by Gene Heskett
<http://www.wired.com/2014/10/code-published-for-unfixable-usb-at
tack />
for an explanation much better than I seem to be doing. It went
live yesterday.

Agreed, but if when it is plugged in, it goes out and installs a
keylogger,

Wait, how can a USB device "install a keylogger"? If that happens,
then that is a bug in the kernel. And yes, we did have a few bugs in
that area in the past, specifically we fixed them over the past year,
but that's a totally different thing than allowing the firmware of a
device to be changed.

Good, someone saw the possibilities then. Thanks.

Post by Gene Heskett
now that is harming the user even if the code to do it is 100%
nicely written legal code.

Good.

Post by Greg KH
Beware of the press around this issue, it's very confusing, and
incorrect. This has been discussed in detail on the oss-security
mailing list a few months ago if you are interested and want to go read
the archives.

Not at 05:30 local time, but perhaps later today.

Post by Greg KH
thanks,
greg k-h

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Peter Stuge

2014-10-17 09:48:27 UTC

Post by Greg KH
There is no "paywall" for USB specs.

I last looked about a year ago. The only link google could find

You should look on usb.org under Developer Documentation instead of
on google.com.

//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Alan Stern

2014-10-17 14:58:15 UTC

Post by Gene Heskett
now that is harming the user even if the code to do it is 100%
nicely written legal code.

I don't think the situation is quite so rosy as you guys seem to
believe.

Given the ability to update a USB device's firmware, a black hat can
easily modify the firmware of an innocent-looking USB flash drive. The
new firmware can include an HID interface that presents itself to the
host as a keyboard.

When an unsuspecting user plugs the device into his computer, any data
sent out by the bad firmware over the keyboard interface will appear
(to the host) as if it was typed directly by the user. Therefore the
device would be able to do practically anything the user could.

It wouldn't exactly be "silent", but it could be quite insidious.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Greg KH

2014-10-17 15:38:04 UTC

Post by Alan Stern

Post by Gene Heskett
now that is harming the user even if the code to do it is 100%
nicely written legal code.

I don't think the situation is quite so rosy as you guys seem to
believe.
Given the ability to update a USB device's firmware, a black hat can
easily modify the firmware of an innocent-looking USB flash drive. The
new firmware can include an HID interface that presents itself to the
host as a keyboard.
When an unsuspecting user plugs the device into his computer, any data
sent out by the bad firmware over the keyboard interface will appear
(to the host) as if it was typed directly by the user. Therefore the
device would be able to do practically anything the user could.
It wouldn't exactly be "silent", but it could be quite insidious.

Google 'USB rubber ducky', you can turn that device into a device that
looks like anything else quite easily if you want to, so you have to be
aware of what you plug into your machine.

The only thing new here is that now people know how to turn devices that
were previously not thought to be programmable, now are. So if you have
malware running on a machine, and you plug your USB stick into it, it
could change it to be something else for when you plug that into a
different machine, which can do the 'bad keyboard/mouse' trick.

There isn't anything "exploitable" on the host OS side of this, through
the USB interface directly, or that the USB spec is somehow "totally
insecure" as the original post was asserting.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Alan Stern

2014-10-17 16:01:54 UTC

Post by Alan Stern
Given the ability to update a USB device's firmware, a black hat can
easily modify the firmware of an innocent-looking USB flash drive. The
new firmware can include an HID interface that presents itself to the
host as a keyboard.
When an unsuspecting user plugs the device into his computer, any data
sent out by the bad firmware over the keyboard interface will appear
(to the host) as if it was typed directly by the user. Therefore the
device would be able to do practically anything the user could.
It wouldn't exactly be "silent", but it could be quite insidious.

Google 'USB rubber ducky', you can turn that device into a device that
looks like anything else quite easily if you want to, so you have to be
aware of what you plug into your machine.
The only thing new here is that now people know how to turn devices that
were previously not thought to be programmable, now are. So if you have
malware running on a machine, and you plug your USB stick into it, it
could change it to be something else for when you plug that into a
different machine, which can do the 'bad keyboard/mouse' trick.
There isn't anything "exploitable" on the host OS side of this, through
the USB interface directly, or that the USB spec is somehow "totally
insecure" as the original post was asserting.

The exploitability lies in what you mentioned above: that you have to
be aware of what you plug into your machine, and that devices that were
previously thought not to be corruptible actually are. Taken together,
these two ingredients make up a recipe for a social exploit: reprogram
an innocent-looking device and give it to someone who doesn't realize
how dangerous it could be.

Furthermore, there's no reasonable way to test for this sort of attack.
That is, given a USB device, you can't easily determine whether the
firmware it contains is dangerous without exposing yourself to the
danger. The only effective defense is never to plug in a USB device
unless you know it has never been used by anybody else.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Bjørn Mork

2014-10-17 17:01:05 UTC

The exploitability lies in what you mentioned above: that you have to=

=20

be aware of what you plug into your machine, and that devices that we=

re=20

previously thought not to be corruptible actually are. Taken togethe=

r,=20

these two ingredients make up a recipe for a social exploit: reprogra=

m=20

an innocent-looking device and give it to someone who doesn't realize=

=20

how dangerous it could be.
Furthermore, there's no reasonable way to test for this sort of attac=

k. =20

That is, given a USB device, you can't easily determine whether the
firmware it contains is dangerous without exposing yourself to the
danger. The only effective defense is never to plug in a USB device
unless you know it has never been used by anybody else.

This really isn't any different for any other bus protocol, is it? The
only thing making USB special is that both ports and devices are so
common. But you do have the same issue with Cardbus/ExpressCard
devices, Thunderbolt devices or any other hotpluggable device with
firmware in flash. And non-hotpluggable devices too, really. The PCIe
ethernet card you bought on eBay could be programmed to do more than
just ethernet. There is no way to tell without plugging it in.

Bj=C3=B8rn (feeding the paranoia)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Greg KH

2014-10-18 10:31:10 UTC