D
David W. Hodgins
According to Bruce Schneier, a well known security expert, they can
https://www.schneier.com/blog/archives/2006/06/hacking_compute.html
Regards, Dave Hodgins
BadUSB security flaw (massive undetectible USB reprogramming vulnerability)
According to Bruce Schneier, a well known security expert, they can
https://www.schneier.com/blog/archives/2006/06/hacking_compute.html
Regards, Dave Hodgins
G
Gene E. Bloch
Yes, it probably should have been s/OTP/OTG/g or something
He would have hated that one even more
Somewhere, a secret agent is trying to break our "code"
Paul
BTW, I've realized recently that I don't even remember vi to any extent
:-(
G
Gene E. Bloch
For debugging (and other) reasons I've connected more than one keyboard
to a computer with no ill effects and with no problems using either
keyboard.
G
Gene E. Bloch
Copied from http://dictionary.reference.com/
dub
1 [duhb] Show IPA
verb (used with object), dubbed, dub·bing.
1. to invest with any name, character, dignity, or title; style; name;
call: He was dubbed a hero.
2. to strike lightly with a sword in the ceremony of conferring
knighthood; make, or designate as, a knight: The king dubbed him a
knight.
[...]
P
Paul
David said:
That is Autoruns, and not DMA.
Someone engineered Firewire, on purpose, to do RDMA (remote direct
memory access). I've never heard of such a feature with USB, and
it's unlikely to be present because USB is a host-peripheral
protocol and not a peer to peer protocol like Firewire is.
They make Firewire networking gear, which takes advantage
of the peer to peer capabilities.
(See Security Issues at the bottom of this, for a description...)
http://en.wikipedia.org/wiki/IEEE_1394
*******
Schneier is mentioning the presence of an autorun.inf file on
a USB stick, being used like we used to use autorun.inf on
installer CDs. An installer CD, when you inserted it, the
installer program would start to run and you'd see an
installer program appear magically on your screen. That
feature can be turned off, so that no inserted device can
work.
In fact, there are three levels of autoruns.
1) Autorun disabled on everything. Requires damaging
something so that it won't run. Not really a problem for
a user, as you can manually run "setup.exe" on an installer
CD, if you really need to install something. This automation
is really a crock.
2) The Microsoft recipe, is disable Autorun on USB flash, but
leave it enabled on CD. This notion makes me nervous,
in terms of attack surface. My system is set this way
currently. And I did that just recently, after someone
got Sality malware, and I started reading up on it.
Some USB keys have a CD-like storage section, so this
policy is a bit on the weak side. I think perhaps U3 sticks
can have two storage areas effectively inside. I never
buy anything with U3 branding on it...
3) With no modifications, both your USB flash stick and
your inserted CDs, could be using autorun.inf.
So for someone who takes this attack notion seriously (i.e.
that the CD path could be used), then (1) is the answer.
I did (2) because it was easy to do, and no side effects.
*******
USB is a *polled* protocol, where the polling is
done from the host side. You can't "jam something up
the spout" from the peripheral side, and expect anything
to happen. That means the driver instigates
a poll, and also prepares storage space for a returning
answer. It means the driver is in control of things,
in terms of DMA attack possibilities.
The BadUSB idea, seeks to trick the driver discovery
code, into making an endpoint for something like
a HID that should not be there.
Host
|
---------------------
|
(Bugged Peripheral)
|
Composite Device
| | |
Video Audio HID
In that example, perhaps the HID is not supposed to be
there. But by filling in the config details, the device
could be re-programmed such that the HID connection was
made. The automatic response of the OS, is to set up
the HID as another keyboard or mouse or whatever.
The user might not be watching what is going on.
The OS was not designed to check for inconsistent
sets of hardware, like a USB webcam with a keyboard
apparently inside it.
Paul
P
Paul
pjp said:
When I was reading up on this a while ago, some people were
advocating damaging the CD autorun capability, so it
no longer runs. And yes, you're right, that any device
which sports a CD emulation (such as U3), could be using
this route. There's some change you can make to the
OS, to stop everything from Autorun, but the Microsoft
Fixit does not do that for you. The Microsoft Fixit only
disables the trivial case, USB Mass Storage autorun, not
the CD attack route. Even some things such as a certain
USB video monitor, have used the fake CD route as a means
to auto-install a driver. That's how the USB video monitor
gets its driver into a Windows system, with no user
intervention, and the monitor then "just works".
http://en.wikipedia.org/wiki/U3
"A U3 flash drive presents itself to the host system as
a USB hub with a CD drive and standard USB mass storage
device attached."
That's an example of an attack surface, that the Fixit doesn't cover.
CD Autorun should really be disabled too, because CD is no
longer trustworthy in terms of where it will pop up.
Paul
J
John Hasler
Gene said:
I just meant that the OS should ask permission before connecting to a
second keyboard.
G
Gene E. Bloch
OK. I got it
And I agree.
W
William Unruh
I have often disconnected one keyboard and connected another because of
problems for example, or because my laptop's keyboard is useless and I
wanted to type on something useable.
And if both are already plugged in at boot, which one should it choose?
problems for example, or because my laptop's keyboard is useless and I
wanted to type on something useable.
And if both are already plugged in at boot, which one should it choose?
W
William Unruh
Why? It is just an old form of "named" Why not have various words with
shades of difference (the use of dubbed carries the hint of the old
kingly renaming someone when making them a knight-- Ie a name give to
something in a formal ceremony with a distringly old fashioned air to
it. It is a way of taking the mikey out of whoever is doing the
naming)
R
Richard Kettlewell
J. P. Gilliver (John) said:
Better avoid Shakespeare then...
J
J. P. Gilliver (John)
But it's only valid if the asking of permission prompts for a randomGene E. Bloch said:OK. I got it
And I agree.
character, otherwise the badware (!) could just send whatever's
expected.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf
"Usenet is a way of being annoyed by people you otherwise never would have
met."
- John J. Kinyon
J
J. P. Gilliver (John)
Gene E. Bloch said:
(Not sure what that bit was about. Presumably there's some significance
to the "1" not having a "." after it as below.)
Have you ever heard anyone, other than in print or giving a speech or
something, actually use the word in that way?
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf
"Usenet is a way of being annoyed by people you otherwise never would have
met."
- John J. Kinyon
J
J. P. Gilliver (John)
In message
in the English Literature world that it's quite difficult to do so,
though.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf
"Usenet is a way of being annoyed by people you otherwise never would have
met."
- John J. Kinyon
I do try to, wherever I can; his Mafia held sway for sufficiently long
in the English Literature world that it's quite difficult to do so,
though.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf
"Usenet is a way of being annoyed by people you otherwise never would have
met."
- John J. Kinyon
D
David W. Hodgins
Read it again ...
and the ability of peripherals to use something called direct memory access (DMA). ...
is the result of a design flaw that's likely to be with us for many years to come
If a usb device could not access dma, then usb external hard drives would
be painfully slow, since they would be suck in pio mode.
Regards, Dave Hodgins
J
John Hasler
William said:
You should have to reboot, though I suppose it might be ok if the OS
just detected that you went from one keyboard to none and back to one
and therefor just replaced the keyboard. It should still require you to
log in again.
Neither. The OS should print a message telling you to disconnect the
extra keyboard and reboot.
At the least the OS should not accept any commands from a new or second
keyboard until a user has logged in via that keyboard.
J
John Hasler
J. P. Gilliver said:
The user's password is what should be expected.
J
John Hasler
I said:
When a second keyboard appears the OS should only connect to it after
having been given permission via the already-connected keyboard, of
course. Thus it doesn't matter what characters the second keyboard
attempts to send.
P
Paul
David said:
There is one comment in the Schneier article, asking the same
question I am. Namely, that Firewire has the RDMA capability,
and USB does not. Nobody responded to this.
"Lotharster June 9, 2006 5:34 AM
I'm not sure if USB can actually use DMA. AFAIK, Firewire can
use DMA, but USB cannot. Can anybody confirm this?
"
USB peripherals only respond to queries, or
give acks on a write. There is no RDMA on USB, because
it's not a peer to peer technology. The peripheral cannot
say "give me data from physical address 0x12345678".
The peripheral does not possess the ability to initiate
a transaction. Only when the host polls at regular intervals,
does the peripheral get a chance to talk. The host can send
data to the peripheral, as long as the peripheral completed
it's last transaction and is ready for it. The host side
DMA structure, the addresses used, are controlled by the
host driver, with no reason to modify the DMA structures
on some request from the peripheral ("move your buffer
to 0x12345678").
The article by Simson Garfinkel, gives no references to this
purported USB mechanism, no field examples (known exploits
of USB this way). Firewire, on the other hand, the case for
that one is well known. People were using it for debugging,
before it was considered as a security issue. (And it's
an issue if the perp is standing next to the computer and
a Firewire port is available.)
Paul
J
John Hasler
1) Multiple keyboards at boot:
Connect to the first found, get a login, ask what to do about the
others. Obviously, accept no input from any keyboard but the first
until authorized. Perhaps only permit root to authorize additional
keyboards.
2) Additional keyboard appears after boot:
Ask a logged-in user what to do. Obviously, accept no input from the
new keyboard until authorized. Perhaps only permit root to authorize
additional keyboards.
3) Connected keyboard vanishes, new one appears:
Log the user who was using that keyboard out with an informative
message. Connect the new keyboard and accept a log-in via it.
A message should be printed to the console any time a new USB device is
connected. Certain classes of device should not be connected without
authorization from a logged-in user. Perhaps some should require
permission from root.
Connect to the first found, get a login, ask what to do about the
others. Obviously, accept no input from any keyboard but the first
until authorized. Perhaps only permit root to authorize additional
keyboards.
2) Additional keyboard appears after boot:
Ask a logged-in user what to do. Obviously, accept no input from the
new keyboard until authorized. Perhaps only permit root to authorize
additional keyboards.
3) Connected keyboard vanishes, new one appears:
Log the user who was using that keyboard out with an informative
message. Connect the new keyboard and accept a log-in via it.
A message should be printed to the console any time a new USB device is
connected. Certain classes of device should not be connected without
authorization from a logged-in user. Perhaps some should require
permission from root.