“BadUSB” exploit

[7v5w7go9ub0o]

<http://arstechnica.com/security/2014/07/this-thumbdrive-hacks-computers-badusb-exploit-makes-devices-turn-evil/>

[Marek Marczykowski-Górecki]

On 31.07.2014 23:56, 7v5w7go9ub0o wrote:
> <http://arstechnica.com/security/2014/07/this-thumbdrive-hacks-computers-badusb-exploit-makes-devices-turn-evil/>
>

Nothing really new:
http://theinvisiblethings.blogspot.com/2011/06/usb-security-challenges.html
Hmm, perhaps besides the idea of "infecting" the device which was clean in the
first place. But still, you shouldn't trust (="connect to more trusted
domain/machine") the device, which was used in less trusted environment.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[7v5w7go9ub0o]

On 07/31/14 18:23, Marek Marczykowski-Górecki wrote:
> On 31.07.2014 23:56, 7v5w7go9ub0o wrote:
>> <http://arstechnica.com/security/2014/07/this-thumbdrive-hacks-computers-badusb-exploit-makes-devices-turn-evil/>
>>
>
>>
>>
> Nothing really new:
> http://theinvisiblethings.blogspot.com/2011/06/usb-security-challenges.html
>
>
>
Hmm, perhaps besides the idea of "infecting" the device which was clean
in the
> first place. But still, you shouldn't trust (="connect to more
> trusted domain/machine") the device, which was used in less trusted
> environment.
>

Nothing new to you, Joanna, and those on these Qubes lists. "It" is one
of the (many) strong arguments for Qubes.

Sigh...... but ISTM this splashy demonstration will "mainstream" this
heretofore relatively obscure TLA technique.

It therefore ups the poignancy re: recent discussions on locking out USB.

(Perhaps re-energizes the idea of making backups of one's USB firmware,
and re-energizes the eternal question, how do I know if I've been
compromised.)

[Axon]

7v5w7go9ub0o:

Summary:
Regular computer users suddenly realize that USB is fundamentally
insecure, proceed to freak out.

Meanwhile, the Qubes project shrugs and says, "That's why we've been
trying to tell you about this 'usbvm' thing for years now..."

Better late than never, I suppose.

Here's more people freaking out about it all over the web:

https://www.schneier.com/blog/archives/2014/07/the_fundamental.html
https://news.ycombinator.com/item?id=8112942
http://www.wired.com/2014/07/usb-security/
http://gizmodo.com/usb-has-a-fundamental-security-flaw-that-you-cant-detec-1613833339
http://www.extremetech.com/computing/187279-undetectable-indefensible-security-flaw-found-in-usb-its-time-to-get-your-ps2-keyboard-out-of-the-cupboard
http://www.techspot.com/news/57591-researchers-uncover-fundamental-usb-security-flaw-no-fix-in-sight.html
http://www.techradar.com/news/computing-components/peripherals/uh-oh-the-humble-usb-has-a-serious-security-problem-1259796
http://www.theverge.com/2014/7/31/5955151/usb-drives-are-a-security-nightmare
http://www.businessinsider.com/r-hackers-can-tap-usb-devices-in-new-attacks-researcher-warns-2014-31
http://www.macrumors.com/2014/07/31/usb-security-threat/
http://www.cultofmac.com/289523/usb-security-fundamentally-broken-claim-security-experts/
http://9to5mac.com/2014/07/31/security-researchers-say-usb-security-broken-can-take-over-macs-or-pcs/

[HW42]

Am Thu, 31 Jul 2014 23:22:13 +0000
schrieb Axon <ax...@openmailbox.org>:

Yes it's funny how suddenly many people realize that USB-controller are
software and probably not very secure (the only really new is that
someone hacked a specific controller and published that).

But you should be aware off that Qubes doesn't really solve the problem
(but it improves the situation). For example what do you do when you
want to connect a camera for taking photos which should kept secret.
You first need an new usbvm since your "normal" should be considered
potentially compromised. But then you connect your PCIe-USB-controller
which are soldered on your mainboard to this VM. And why should the
software of the PCIe-USB-controller be that much safer than those from
the USB-drives (I haven't verified that the common PCIe-USB-Controller
are implemented in software but due to the complexity of the
USB-protocol I expect that).

And when you take step back away from USB you find a lot more of µCs in
your PC. For example your Wifi-Card runs a lot of "firmware"-code and
constantly talks to networks. During the normal operation of Qubes it
is isolated via VT-d/IOMMU. But during the boot it can talk to your
BIOS/Xen/dom0.

It's get even worser when you for what ever reason boot another not that
trusted system on your PC (of course after disconnecting your HDD). They
can talk freely to µCs which normally would be never connected to some
untrusted VM. For example your keyboard-controller.

I better not think about BIOS security ;[ (which should guarantee secure
boot and similar features.)

Please don't miss understand me. I don't want to say "hey Qubes is
insecure". I just want to point out that there are still many problem
which Qubes doesn't solve. Sadly many of those can't be fixed without
fundamental changes to your PC-architecture and will therefore not
fixable in middle-term future.

HW42

[cprise]

I haven't a clue how to back up USB firmware (I presume this means USB
client devices?).

Joanna once commented that persistent infection of USB host controller
(e.g. on a PC motherboard) is very unlikely. That at least is some
comfort. But it also suggests usbvm should be used whenever possible.

I have one other (perhaps small, perhaps not) mitigation and I'm going
to make the change right now, before I finish this paragraph:
Disable "Run Command" shortcuts...
1. Go to System Settings - Shortcuts and Gestures
2. Click on 'Global...' on the left pane, and for the component select
'Run Command Interface'
3. Nullify any 'Run Command...' shortcuts such as Alt-F2 and
Alt-Shift-F2 by selecting Custom and leaving the value at 'None'.

It may also help to make sure you are using the older-style Launcher
menu, instead of the newer one based on text search. (I think this is
the Qubes default now?)

[cprise]

On 07/31/14 21:20, cprise wrote:
>
> Disable "Run Command" shortcuts...
> 1. Go to System Settings - Shortcuts and Gestures
> 2. Click on 'Global...' on the left pane, and for the component select
> 'Run Command Interface'
> 3. Nullify any 'Run Command...' shortcuts such as Alt-F2 and
> Alt-Shift-F2 by selecting Custom and leaving the value at 'None'.

4. Click 'Apply'

:P

[Rafał Wojdyła]

On the topic of hardware security, just three presentations from a
recent CCC Congress:
- The Exploration and Exploitation of an SD Memory Card [1]
- Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware [2]
- Hardware Attacks, Advanced ARM Exploitation, and Android Hacking [3]

[1] https://www.youtube.com/watch?v=Tj-zI8Tl218
[2] https://www.youtube.com/watch?v=Ck8bIjAUJgE
[3] https://www.youtube.com/watch?v=frUvlhO8o8A

;)

--
Rafał

[Joanna Rutkowska]

Offensive security research always gets more splendor and often also
more/easier money than security building. It's a result of: 1) being
more exciting to most (weak minded) people, 2) being
feasible-to-demonstrate-in-practice (in contrast to security which
usually cannot be demonstrated).

To be fair, ITL also got lots of media attention (and earned decent
money) in the past, when we were on the other side of The Force.

Also, usually, the less trivial research, the more media attention one
gets -- compare e.g. coverage of our Evil Maid attack (trivial) vs. one
of our late attacks against Intel VT-d or TXT (highly non-trivial).

Perhaps I was wrong claiming Qubes doesn't need so much of mainstream
media attention. Even though R2 might not be mass market-ready, it still
deserves more attention IMHO than some
yet-another-exploit-against-known-for-years-security-problem that
ordinary users cannot really do much about besides panicking on twitter...

joanna.

[inf...@gmail.com]

So the containment of these risks is what the USBVM concept is for, right?

Without making any claims that are unjustified, if I was a Qubes-OS'
marketing person, I would see a fantastic opportunity to explain that
unless people want to superglue the USB ports of their sleek shiny new
laptops, they better check out Qubes-OS

Sentiment about the severity of this problem may change once attack code
is circulating, so maybe this argues greater prioritisation (and usable
preconfig) of USBVM ?

CB

[J.M. Porup]

A good PR person would advise you to make a lot of noise right now about the
Qubes defense against such usb attacks.

JMP

[Joanna Rutkowska]

There are several approaches how to use a USB stick in Qubes, depending
on the specific of your situation. E.g. you might export a block device
from (assumed to be compromised) usbvm via qvm-block to another VM,
where you can run block device decryptor (e.g. LUKS). Sure, your exposed
block device might still be malformed and trying to exploit a
hypothetical bug in LUKS, but you just shrinked at attack surface orders
of magnitude.

There are no solutions that could guarantee 100% safety (even so called
"formally verified" code doesn't do that in practice[1]). Qubes allows
you to partition your otherwise one-bug-to-break-it-all system into
something more reasonably secure (perhaps: significantly more secure).

> But then you connect your PCIe-USB-controller
> which are soldered on your mainboard to this VM. And why should the
> software of the PCIe-USB-controller be that much safer than those from
> the USB-drives (I haven't verified that the common PCIe-USB-Controller
> are implemented in software but due to the complexity of the
> USB-protocol I expect that).
>
> And when you take step back away from USB you find a lot more of µCs in
> your PC. For example your Wifi-Card runs a lot of "firmware"-code and
> constantly talks to networks. During the normal operation of Qubes it
> is isolated via VT-d/IOMMU. But during the boot it can talk to your
> BIOS/Xen/dom0.
>

In my opinion it is Very Hard to subvert Intel chipset's firmware. Much
harder than subvert 3rd party USB devices', BIOSes', NICs' or GPUs'
firmware. (Besides TXT) Intel designs and makes pretty secure stuff, at
least this was our conclusion after some years of trying to break it.
Sure, we have broke some other things besides TXT, but the attack were
really Sophisticated(TM).

> It's get even worser when you for what ever reason boot another not that
> trusted system on your PC (of course after disconnecting your HDD). They
> can talk freely to µCs which normally would be never connected to some
> untrusted VM. For example your keyboard-controller.
>

You should not be doing that -> buy another laptop, dual boot is wrong
(and inconvenient).

> I better not think about BIOS security ;[ (which should guarantee secure
> boot and similar features.)
>
> Please don't miss understand me. I don't want to say "hey Qubes is
> insecure". I just want to point out that there are still many problem
> which Qubes doesn't solve. Sadly many of those can't be fixed without
> fundamental changes to your PC-architecture and will therefore not
> fixable in middle-term future.
>

Many problems cannot be generically fixed (without sacrificing some
convenience at last), no matter what (i.e. not even with the change of
PC architecture). Specifically this includes problems related to data
exchange between differently trusted domains (e.g. your camera and your
trusted VM). Some attempts are possible [2], but not generic.

joanna.
[1]
http://theinvisiblethings.blogspot.com/2010/05/on-formally-verified-microkernels-and.html
[2]
http://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html

[Pedro Martins]

On 01-08-2014 12:59, Joanna Rutkowska wrote:
> ...

> There are no solutions that could guarantee 100% safety (even so called
> "formally verified" code doesn't do that in practice[1]). Qubes allows
> you to partition your otherwise one-bug-to-break-it-all system into
> something more reasonably secure (perhaps: significantly more secure).
>

A couple of days ago this was announced, proving once more your point:

"The world's first operating-system kernel with an end-to-end proof of
implementation correctness and security enforcement is now open source."

http://sel4.systems/FAQ/

"Is seL4 proven secure?

This depends on what you mean by secure. In the interpretation of
classic operating system security, the answer is yes. In particular,
seL4 has been proved to enforce specific security properties, namely
integrity and confidentiality, under certain assumptions. These proofs
are very strong evidence about seL4's utility for building secure systems.

Some of the proof assumptions may appear restrictive, for instance use
of DMA is excluded, or only allowed for trusted drivers that have to be
formally verified by the user. While these restrictions are common for
high-assurance systems, we are working to reduce them, for instance
through the use of IOMMUs on x86 or System MMUs on ARM."


Code here:
https://github.com/seL4/seL4

Some discussion on this:
The seL4 microkernel | Hacker News
https://news.ycombinator.com/item?id=8100983

--
Pedro Martins

[IX4 SVS]

+1

@ITL - while I understand the theoretical protection that domain segregation gives me with Qubes, I have managed to be a Qubes user for more than a year now without even knowing how to setup a USBvm - and without actually using one. I'm not protected against this class of attacks just because I'm using Qubes.

It might just be documentation or secure defaults that are missing here, but I'm sure not all users are benefiting from Qubes' abilities when it comes to isolating USB.

Even a wiki page explaining how such a USBvm would be created and used in practice (taking into consideration that many people who work on their laptops all the time use external USB keyboards/mice/headsets) would be great.

Alex

[7v5w7go9ub0o]

On 07/31/14 21:20, cprise wrote:
>

> On 07/31/14 18:39, 7v5w7go9ub0o wrote:
>> On 07/31/14 18:23, Marek Marczykowski-Górecki wrote:
>>> On 31.07.2014 23:56, 7v5w7go9ub0o wrote:
>>>> <http://arstechnica.com/security/2014/07/this-thumbdrive-hacks-computers-badusb-exploit-makes-devices-turn-evil/>
>>>>
>>>>
>>>>
>>> Nothing really new:
>>> http://theinvisiblethings.blogspot.com/2011/06/usb-security-challenges.html
>>>
>>>
>>>
>>>
>> Hmm, perhaps besides the idea of "infecting" the device which was clean
>> in the
>>> first place. But still, you shouldn't trust (="connect to more
>>> trusted domain/machine") the device, which was used in less trusted
>>> environment.
>>>
>> Nothing new to you, Joanna, and those on these Qubes lists. "It" is one
>> of the (many) strong arguments for Qubes.
>>
>> Sigh...... but ISTM this splashy demonstration will "mainstream" this
>> heretofore relatively obscure TLA technique.
>>
>> It therefore ups the poignancy re: recent discussions on locking out USB.
>>
>> (Perhaps re-energizes the idea of making backups of one's USB firmware,
>> and re-energizes the eternal question, how do I know if I've been
>> compromised.)
>
> I haven't a clue how to back up USB firmware (I presume this means USB
> client devices?).

This harkens back to earlier discussions about backing up firmware in
general, not USB alone; thread of Oleg Artemiev, started Feb 16; "Are
there any details how Qubes prevents attacks from BIOS EFI modules?"

(FWIW, I personally do not use USB for anything)

> Joanna once commented that persistent infection of USB host controller
> (e.g. on a PC motherboard) is very unlikely. That at least is some
> comfort. But it also suggests usbvm should be used whenever possible.

Heh.... obviously, she proved quite prescient.

As mentioned earlier, the cognoscenti are now alarmed - momentarily -
but will remain largely complacent. When this thing goes wild -
especially web-borne OS malware infecting firmware - the interest in
Qubes will become quite high.

Best to lock down and eliminate USB now.

[Axon]

IX4 SVS:

https://qubes-os.org/wiki/SecurityGuidelines

[Axon]

HW42:

I think this rests on a mistaken assumption. There is probably no such
thing as a "secure USB camera" for the same reason that there is no such
thing as secure USB scanning. (See the prior discussion about this on
this list.)

> You first need an new usbvm since your "normal" should be considered
> potentially compromised. But then you connect your PCIe-USB-controller
> which are soldered on your mainboard to this VM. And why should the
> software of the PCIe-USB-controller be that much safer than those from
> the USB-drives (I haven't verified that the common PCIe-USB-Controller
> are implemented in software but due to the complexity of the
> USB-protocol I expect that).
>

Good point. In that case, everyone who uses USB devices (even Qubes
usbvm users) are vulnerable. I suppose physical destruction is the only
answer there.

> And when you take step back away from USB you find a lot more of µCs in
> your PC. For example your Wifi-Card runs a lot of "firmware"-code and
> constantly talks to networks. During the normal operation of Qubes it
> is isolated via VT-d/IOMMU. But during the boot it can talk to your
> BIOS/Xen/dom0.
>

Yes, another good point. The same applies even to USB *devices*. If you
leave them plugged in across a host reboot, they talk to dom0 before
your usbvm has a chance to start. Suggesting that desktop/server users
physically unplug every USB device before a host reboot is impractical
(e.g., if dozens of USB devices are plugged in) and in some cases
impossible (e.g., if the backside of the PC case is not physically
accessible), not to mention easily forgettable ("Oops, I left a USB
device plugged in while rebooting; now I have to throw away my PC.").
So, you're absolutely right: the protection provided by usbvms is
currently rather limited compared to the protection they could
theoretically provide. Good to be honest about that.

> It's get even worser when you for what ever reason boot another not that
> trusted system on your PC (of course after disconnecting your HDD). They
> can talk freely to µCs which normally would be never connected to some
> untrusted VM. For example your keyboard-controller.
>

Use AEM or don't dual-boot on the same hardware.

[Pedro Martins]

On 01-08-2014 12:59, Joanna Rutkowska wrote:

> On 08/01/14 03:07, HW42 wrote:
>> Am Thu, 31 Jul 2014 23:22:13 +0000 schrieb Axon
>> <ax...@openmailbox.org>:
>>

>> ... Yes it's funny how suddenly many people realize that

>> 湣s in your PC. For example your Wifi-Card runs a lot of

>> "firmware"-code and constantly talks to networks. During the normal
>> operation of Qubes it is isolated via VT-d/IOMMU. But during the
>> boot it can talk to your BIOS/Xen/dom0.
>>
>
> In my opinion it is Very Hard to subvert Intel chipset's firmware.
> Much harder than subvert 3rd party USB devices', BIOSes', NICs' or
> GPUs' firmware. (Besides TXT) Intel designs and makes pretty secure
> stuff, at least this was our conclusion after some years of trying to
> break it. Sure, we have broke some other things besides TXT, but the
> attack were really Sophisticated(TM).
>
>> It's get even worser when you for what ever reason boot another not
>> that trusted system on your PC (of course after disconnecting your

>> HDD). They can talk freely to 湣s which normally would be never

>> connected to some untrusted VM. For example your
>> keyboard-controller.
>>
>
> You should not be doing that -> buy another laptop, dual boot is
> wrong (and inconvenient).
>
>> I better not think about BIOS security ;[ (which should guarantee
>> secure boot and similar features.)
>>
>> Please don't miss understand me. I don't want to say "hey Qubes is
>> insecure". I just want to point out that there are still many
>> problem which Qubes doesn't solve. Sadly many of those can't be
>> fixed without fundamental changes to your PC-architecture and will
>> therefore not fixable in middle-term future.
>>
>
> Many problems cannot be generically fixed (without sacrificing some
> convenience at last), no matter what (i.e. not even with the change
> of PC architecture). Specifically this includes problems related to
> data exchange between differently trusted domains (e.g. your camera
> and your trusted VM). Some attempts are possible [2], but not
> generic.
>

This got me thinking what hardware support would be nice to have, which
allows one to put security before convenience.

Some wishful thinking follows.


** Minor hardware changes to improve security **


1) some way to lock laptop lid when closed:

even those luggage combination locks might be better than nothing.


2) hardware switches to power on and off ports/devices:

real ones, not software driven - when it's off it remains off until I
flip it on; for ethernet, wireless stuff, camera, mic, display, usb
controllers/ports, memory cards, keyboard, internal stuff like sata
ports (dangerous), etc;

even if vm exploited, without power, no game: would no longer need to
tape over my camera and mic; could boot computer with as little devices
powered as possible, enable only as needed; as bonus, could disable all
ports not needed to save power; added bonus, would end up with as many
switches as pdp 11 ;-P


3) an usb controller for each usb port:

would allow to reserve ports according to domain trust level. Snooping
can still happen but now only within the same domain trust level. usbvm
used to park usb controllers. Unfortunately it doesn't prevent me from
inserting untrusted device in trusted port/domain - mistakes happen.


4) an high-quality random number generator:

as previously discussed on the list; can be bought today as usb device;
to be used in addition to cpu existing one, if any.


** Not so minor hardware changes to improve security **


5) proper support for TPM, TXT, VT-x, VT-d and upcoming SGX [3][4]:

something is always missing because cost outranks security every time.
also assuming owner will be in total control.


6) some sort of usb virtualization support by the usb controller:

each usb device inserted would have own isolated environment, virtual
port assigned; usbvm could work as a sort of firewallvm/netvm to assign
virtual usb ports to domains. Unfortunately it still doesn't prevent me
from assigning untrusted device to trusted domain - mistakes happen.

nice to have for usb ports, additional hardware switch to enable or
disable data pins, allowing safe charge of usb devices - aka 'usb condom'.


7) only minimal firmware needed to configure & boot the system and no
firmware stored on devices/controllers for network, display, storage,
usb, etc:

coreboot [5] all the way. all drivers from source; unconstrained and
freely available hardware interfacing specs; this will probably never
happen, unless hardware OEMs totally committed to support open
source/free software friendly components in their designs.


8) the ability to power on or off cpu/chipset "features", like vPro &
co; ditto for gpu:

yeah, as if ever! BIOS support only for enabling or disabling some of
these features, but not all that can be supported by given cpu/chipset;
something disabled might still be used/usable.


9) virtualization support by/for the gpu(s):

with so many cores available nowadays, makes sense and would allow
better utilization of resources. even something crude like reserving
some coarse groups of cores as virtual gpus would be nice to have.


10) generic hardware support for software defined radio [6]:

not ever! legal nightmare expected; licensing & testing requirements for
each and every country/state regulations.


So, that's it. 1) to 5) are not that big deal IMO, could be made
available on some brand 'professional' line of computers.

Or, we could follow Canonical example and crowd-fund our own computer
for $32 million [7] ;-) Nice 15" 4K non-glare screen, thinkpad-like
keyboard, 512 Gib SSD, etc; fully supported by QubesOS R3!

--
Pedro Martins

[3]
http://theinvisiblethings.blogspot.pt/2013/08/thoughts-on-intels-upcoming-software.html
[4]
http://theinvisiblethings.blogspot.pt/2013/09/thoughts-on-intels-upcoming-software.html
[5] http://www.coreboot.org/Welcome_to_coreboot
[6] http://gnuradio.org/redmine/projects/gnuradio/wiki
[7] https://www.indiegogo.com/projects/ubuntu-edge

[Franz]

hahahaha :))

You are right. We are humans not computer, we are in hurry, we forget things.

Also it seems very difficult to communicate this sort of concern-education to new users of Qubes. It seems to me that the only way to be able to use Qubes properly is to follow this ML with al the time it requires. But may one expect that a normal user has all this time to devote to an operative system? Normal users have an hard time spending time learning programs, not even OSs.

It may be worth to prepare an educational video with the basic stuff for security and consider that the only thing the user will study is just this video.

Best

Fran

[7v5w7go9ub0o]

Presuming that "BadUSB" will soon become a serious consideration,
perhaps an initial screen pause during boot up asking, "Have you removed
all USB devices? Enter Y or N"

[Axon]

7v5w7go9ub0o:

This would solve the forgetfulness problem but neither the
impracticality nor impossibility problems. :)

(There's also the question of whether Qubes could insert such a prompt
early enough in the boot process to assuage everyone's concerns about
what malicious USB devices might do at any given point in that process.)

[cprise]

On 08/02/14 21:50, Axon wrote:
> 7v5w7go9ub0o:

>> Presuming that "BadUSB" will soon become a serious consideration,
>> perhaps an initial screen pause during boot up asking, "Have you
>> removed all USB devices? Enter Y or N"
> This would solve the forgetfulness problem but neither the
> impracticality nor impossibility problems. :)
>
> (There's also the question of whether Qubes could insert such a prompt
> early enough in the boot process to assuage everyone's concerns about
> what malicious USB devices might do at any given point in that process.)
>

Before we start wishing we were all cyborgs with secure computers in our
heads, are these USB exploits even feasible without first dismantling a
USB device?

[cprise]

On 08/02/14 13:39, Pedro Martins wrote:
>
> This got me thinking what hardware support would be nice to have, which
> allows one to put security before convenience.
>
> Some wishful thinking follows.
>
>
> ** Minor hardware changes to improve security **
>
>
> 1) some way to lock laptop lid when closed:
>
> even those luggage combination locks might be better than nothing.
>

Maybe like "Kensignton lock, Level-2"... it would at least make some
scenarios messy for the attacker.

Since laptop makers (even Lenovo) have banished the lid latch, it would
be pretty funny to see them do a U-turn and then some.

>
> 2) hardware switches to power on and off ports/devices:
>
> real ones, not software driven - when it's off it remains off until I
> flip it on; for ethernet, wireless stuff, camera, mic, display, usb
> controllers/ports, memory cards, keyboard, internal stuff like sata
> ports (dangerous), etc;
>
> even if vm exploited, without power, no game: would no longer need to
> tape over my camera and mic; could boot computer with as little
> devices powered as possible, enable only as needed; as bonus, could
> disable all ports not needed to save power; added bonus, would end up
> with as many switches as pdp 11 ;-P
>

Yeah, but the most important IMHO is the battery. Never trust a machine
from which you cannot quickly yank the power source. BTW, how does an
"Airplane mode" switch on a typical business laptop rate? I assumed the
wireless switch on my Lenovo was hardware, but maybe that's wishful
thinking.

>
> 3) an usb controller for each usb port:
>
> would allow to reserve ports according to domain trust level. Snooping
> can still happen but now only within the same domain trust level.
> usbvm used to park usb controllers. Unfortunately it doesn't prevent
> me from inserting untrusted device in trusted port/domain - mistakes
> happen.
>

My T430s appears to have that: One controller per port.

>
> 4) an high-quality random number generator:
>
> as previously discussed on the list; can be bought today as usb
> device; to be used in addition to cpu existing one, if any.
>
>
> ** Not so minor hardware changes to improve security **
>

Well, if you're not willing to trust Intel/AMD's integrated HWRNG, then who?

>
> 5) proper support for TPM, TXT, VT-x, VT-d and upcoming SGX [3][4]:
>
> something is always missing because cost outranks security every time.
> also assuming owner will be in total control.
>

Industry imperatives appear to rank as high as cost, it seems. I recall
one of Joanna's blog posts describing how a feature (can't remember
which) did not live up to its potential to protect the user because it
was primarily intended to address Hollywood's interests.

>
> 6) some sort of usb virtualization support by the usb controller:
>
> each usb device inserted would have own isolated environment, virtual
> port assigned; usbvm could work as a sort of firewallvm/netvm to
> assign virtual usb ports to domains. Unfortunately it still doesn't
> prevent me from assigning untrusted device to trusted domain -
> mistakes happen.
>
> nice to have for usb ports, additional hardware switch to enable or
> disable data pins, allowing safe charge of usb devices - aka 'usb
> condom'.
>

Assuming some Qubes-of-the-future or spiritual successor to Qubes,
perhaps a USB *VIS*ualization to go along with the isolation
capabilities provided by some future hardware platform.

>
> 7) only minimal firmware needed to configure & boot the system and no
> firmware stored on devices/controllers for network, display, storage,
> usb, etc:
>
> coreboot [5] all the way. all drivers from source; unconstrained and
> freely available hardware interfacing specs; this will probably never
> happen, unless hardware OEMs totally committed to support open
> source/free software friendly components in their designs.
>

Don't give up hope. Open source hardware appears to be advancing, even
WRT security features:
http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

>
> 8) the ability to power on or off cpu/chipset "features", like vPro &
> co; ditto for gpu:
>
> yeah, as if ever! BIOS support only for enabling or disabling some of
> these features, but not all that can be supported by given
> cpu/chipset; something disabled might still be used/usable.
>

I don't think we can live without GPUs on the desktop at this point.
They are not inherently insecure, although current implementations may
be particularly lacking in that area.

>
> 9) virtualization support by/for the gpu(s):
>
> with so many cores available nowadays, makes sense and would allow
> better utilization of resources. even something crude like reserving
> some coarse groups of cores as virtual gpus would be nice to have.
>

GPU virtualization is becoming a reality, even with current hardware.
Intel has a driver that can virtualize a Haswell integrated GPU, for
instance.

>
> 10) generic hardware support for software defined radio [6]:
>
> not ever! legal nightmare expected; licensing & testing requirements
> for each and every country/state regulations.
>
>
> So, that's it. 1) to 5) are not that big deal IMO, could be made
> available on some brand 'professional' line of computers.
>
> Or, we could follow Canonical example and crowd-fund our own computer
> for $32 million [7] ;-) Nice 15" 4K non-glare screen, thinkpad-like
> keyboard, 512 Gib SSD, etc; fully supported by QubesOS R3!
>

11) Hardwired status lights for things like microphones and cameras.
This should be even on smartphones.

12) Peripherals that can be given individualized keys by the user, to
authenticate them with the CPU, so that any attempt at replacement would
be noticed and/or rejected. It doesn't matter what type of peripheral:
SATA, USB, SD card, etc. I think this could contribute toward a solution
to #BadUSB.

[Axon]

cprise:

The more I learn about computer (in)security, the less I want one inside
my head. :)

Good question, though. I suppose we'll just have to wait for the Black
Hat talk in Vegas this week!

[HW42]

Am Sun, 03 Aug 2014 05:19:05 +0000
schrieb Axon <ax...@openmailbox.org>:

According to this [0] article (in German. Sorry but I haven't quickly
found an that detailed article in English) the "new" thing of the attack
is that the researcher actually analysed the firmware of a common
USB-controller and created a malicious one. It can be easily uploaded
via USB so no need to dismantle anything.


[0]: http://www.heise.de/newsticker/meldung/BadUSB-Wenn-USB-Geraete-boese-werden-2281098.html

[Axon]

HW42:

Oh, yes, I remember now; thank you. Part of the point of the attack was
that the infection can go both ways: The USB device can infect the PC,
and the PC can infect other USB devices which are subsequently plugged
into it (which obviously doesn't require any disassembly.)

[Alex Dubois]

Alex

Anybody came across a good article on how to verify control code?
- I would suspect dismantlement to be required here
- verification to only be feasible vs another code base that would have to be assumed OK unless you want to spend the time reverse enginering it...

[Pedro Martins]

On 03-08-2014 06:10, cprise wrote:
>
> On 08/02/14 13:39, Pedro Martins wrote:
>>
>> This got me thinking what hardware support would be nice to have, which
>> allows one to put security before convenience.
>>
>> Some wishful thinking follows.
>>
>>
>> ** Minor hardware changes to improve security **
>>
>>
>> 1) some way to lock laptop lid when closed:
>>
>> even those luggage combination locks might be better than nothing.
>>
>
> Maybe like "Kensignton lock, Level-2"... it would at least make some
> scenarios messy for the attacker.
>
> Since laptop makers (even Lenovo) have banished the lid latch, it would
> be pretty funny to see them do a U-turn and then some.
>

Yes, that's the problem of putting convenience before security. There's
no room for lid latch on thinner/lighter laptops, which is a nice
selling point but at the cost of trivial security measures. The same for
soldered cpu, memory, or your battery example below, which can't be
upgraded or replaced.

>>
>> 2) hardware switches to power on and off ports/devices:
>>
>> real ones, not software driven - when it's off it remains off until I
>> flip it on; for ethernet, wireless stuff, camera, mic, display, usb
>> controllers/ports, memory cards, keyboard, internal stuff like sata
>> ports (dangerous), etc;
>>
>> even if vm exploited, without power, no game: would no longer need to
>> tape over my camera and mic; could boot computer with as little
>> devices powered as possible, enable only as needed; as bonus, could
>> disable all ports not needed to save power; added bonus, would end up
>> with as many switches as pdp 11 ;-P
>>
>
> Yeah, but the most important IMHO is the battery. Never trust a machine
> from which you cannot quickly yank the power source. BTW, how does an
> "Airplane mode" switch on a typical business laptop rate? I assumed the
> wireless switch on my Lenovo was hardware, but maybe that's wishful
> thinking.
>

Spot on on the battery, missed that (not customer of Apple ;-), so:

1a) removable battery

About the wireless switch, I think it is safe to assume that if when
it's off one can't turn wireless on again via software then it's
hardware (assuming everything properly configured and in working order
when the hardware switch is on).

>>
>> 3) an usb controller for each usb port:
>>
>> would allow to reserve ports according to domain trust level. Snooping
>> can still happen but now only within the same domain trust level.
>> usbvm used to park usb controllers. Unfortunately it doesn't prevent
>> me from inserting untrusted device in trusted port/domain - mistakes
>> happen.
>>
>
> My T430s appears to have that: One controller per port.
>
>>
>> 4) an high-quality random number generator:
>>
>> as previously discussed on the list; can be bought today as usb
>> device; to be used in addition to cpu existing one, if any.
>>
>>
>> ** Not so minor hardware changes to improve security **
>>
>
> Well, if you're not willing to trust Intel/AMD's integrated HWRNG, then
> who?
>

No one? ;-) We have to trust intel/amd some, but not put all our trust
on intel/amd. I was considering buying from these guys but they're sold
out currently:

http://www.entropykey.co.uk/

>>
>> 5) proper support for TPM, TXT, VT-x, VT-d and upcoming SGX [3][4]:
>>
>> something is always missing because cost outranks security every time.
>> also assuming owner will be in total control.
>>
>
> Industry imperatives appear to rank as high as cost, it seems. I recall
> one of Joanna's blog posts describing how a feature (can't remember
> which) did not live up to its potential to protect the user because it
> was primarily intended to address Hollywood's interests.
>

You're right, IIRC it was related to Intel LaGrande; but TPM, TXT and
the forthcoming SGX still can be used that way. On ARM you have
equivalent in TrustZone, which is now being used by AMD in hybrid cpus.

>>
>> 6) some sort of usb virtualization support by the usb controller:
>>
>> each usb device inserted would have own isolated environment, virtual
>> port assigned; usbvm could work as a sort of firewallvm/netvm to
>> assign virtual usb ports to domains. Unfortunately it still doesn't
>> prevent me from assigning untrusted device to trusted domain -
>> mistakes happen.
>>
>> nice to have for usb ports, additional hardware switch to enable or
>> disable data pins, allowing safe charge of usb devices - aka 'usb
>> condom'.
>>
>
> Assuming some Qubes-of-the-future or spiritual successor to Qubes,
> perhaps a USB *VIS*ualization to go along with the isolation
> capabilities provided by some future hardware platform.
>
>>
>> 7) only minimal firmware needed to configure & boot the system and no
>> firmware stored on devices/controllers for network, display, storage,
>> usb, etc:
>>
>> coreboot [5] all the way. all drivers from source; unconstrained and
>> freely available hardware interfacing specs; this will probably never
>> happen, unless hardware OEMs totally committed to support open
>> source/free software friendly components in their designs.
>>
>
> Don't give up hope. Open source hardware appears to be advancing, even
> WRT security features:
> http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
>

Good news indeed. There was already OpenRISC from OpenCores project;
RaspberryPi (not completely open); Novena laptop crowd-funded; it seems
there's increasing awareness and willingness for open systems. If
security is emphasized the better.

http://opencores.org/
https://www.crowdsupply.com/kosagi/novena-open-laptop

>>
>> 8) the ability to power on or off cpu/chipset "features", like vPro &
>> co; ditto for gpu:
>>
>> yeah, as if ever! BIOS support only for enabling or disabling some of
>> these features, but not all that can be supported by given
>> cpu/chipset; something disabled might still be used/usable.
>>
>
> I don't think we can live without GPUs on the desktop at this point.
> They are not inherently insecure, although current implementations may
> be particularly lacking in that area.
>

The idea was to be able to disable gpus if having problems booting the
system, or powering only when needed. On the cpu side, to kill ability
for phone home or remote connection.

>>
>> 9) virtualization support by/for the gpu(s):
>>
>> with so many cores available nowadays, makes sense and would allow
>> better utilization of resources. even something crude like reserving
>> some coarse groups of cores as virtual gpus would be nice to have.
>>
>
> GPU virtualization is becoming a reality, even with current hardware.
> Intel has a driver that can virtualize a Haswell integrated GPU, for
> instance.
>

Hoping it becomes mainstream... and adopted by Xen.

>>
>> 10) generic hardware support for software defined radio [6]:
>>
>> not ever! legal nightmare expected; licensing & testing requirements
>> for each and every country/state regulations.
>>
>>
>> So, that's it. 1) to 5) are not that big deal IMO, could be made
>> available on some brand 'professional' line of computers.
>>
>> Or, we could follow Canonical example and crowd-fund our own computer
>> for $32 million [7] ;-) Nice 15" 4K non-glare screen, thinkpad-like
>> keyboard, 512 Gib SSD, etc; fully supported by QubesOS R3!
>>
>
> 11) Hardwired status lights for things like microphones and cameras.
> This should be even on smartphones.
>

Good point, not only on the hardware switches but also on the devices.

> 12) Peripherals that can be given individualized keys by the user, to
> authenticate them with the CPU, so that any attempt at replacement would
> be noticed and/or rejected. It doesn't matter what type of peripheral:
> SATA, USB, SD card, etc. I think this could contribute toward a solution
> to #BadUSB.
>

Yes, but that would mean changes are also required to peripherals so
they work that way; otherwise they might be easily spoofed/duplicated.

What would be a trusted usb memory key/drive?

One without stored firmware, with hardware means to disable writing to
storage, providing only hardwired uuid of sorts when inserted (from rom?
dip switches? both?). Based on this uuid, unknown 1st time, cripto
material and firmware (assuming hardware specs available) would be
configured, firmware uploaded, storage configured & encrypted. This
could be done on separate device. Only encrypted data stored on usb key,
no encryption done on the usb key.

How to deal with untrusted (legacy) usb memory key?

In a manner similar to untrusted pdfs; always on separate device (booted
from read-only trusted usb memory key, no firmware to infect), dump
contents of legacy usb memory key, parse dump using trusted program to
extract files; parse individual files using trusted programs according
to file type (so .doc/.xls to .pdf to .png). Copy trusted file to
trusted usb key. Lots of trusted programs to be written... but feasible.
Not very convenient though!

--
Pedro Martins