#Qubes #Xen vs Dragos Ruiu's #badBIOS

6: co.cyb/sec/qubes/Xen vs Dragos Ruiu's #badBIOS:
me to qubes-devel 5:41am:

. reading about the #badBIOS infection,
blog.erratasec.com/2013/10/badbios-features-explained.html
I was surprised to learn that all computing accessories
(mouse, trackpad, hub, keyboard, and of course
 flash drives) could have a software-programmable firmware
and this could be infected with malware that could spread
to your next computer if attached to dom0 .
. I was also concerned that a new flash drive malware
-- Dragos Ruiu's #badBIOS --
could infect a next machine without even being mounted;
is this a new threat that xen has yet to adapt to?
Dragos Ruiu oct 23:
[...] simply plugging in a USB device from an infected system
into a clean one is sufficient to infect.
This was on a BSD system,
so this is definitely not a Windows issue.
- and it's a low level issue,
I didn't even mount the volume and it was infected.
Could this be an overflow in the way bios id's the drive?
Infected systems seem to reprogram the
flash controllers on USB sticks  (and cd drives, [...])
to attack the system (bios?).
There are only like ten different kinds of flash controllers
 used in all the different brands of memory sticks
and all of them are reprogrammable,
so writing a generic attack is totally feasible.
Dragos Ruiu is
 the organizer of the CanSecWest and PacSec conferences,
and the founder of the Pwn2Own hacking competition .

Gynvael Coldwind 6:01 AM 

Generally I would be careful with jumping to any conclusions
based on the badBIOS case
- it seems there are many doubts
and little evidence in this case.

[9.11:26: co.apt: ah yes:
. I'm just too close to the case to be logical;
that's what it is .
some thing like his mac problem just hit my mac
"what was that?: [timid tone:] "nothing!:
there's not much evidence for that" .
]

Also, I don't think most of the USB devices have
 software-reprogrammable firmware
- one exception here would be high-end gaming equipment.
 Well, also maybe external HDDs and some printers.
I guess that's quite a lot in the end anyway :)
And I don't think this is a new attack vector
- I mean, it has been proven in the past
that USB devices that act e.g. as the keyboard
can send keystrokes to the system
that perform certain actions which allow the attacker to
e.g. download (ups, no internet on dom0,
but this can be worked around) & run a backdoor.
If the firmware of your keyboard can be reprogrammed,
it's of course possible to do that as well.
And dom0 trusts your keyboard, so does xen,
so I don't believe there is anything you can do here
(I mean, your keyboard would be a
whitelisted USB device anyway).
So this isn't new.
However the big question here is
the ability of malware which runs in non-dom0 vm
to be able to re-flash a USB device.
I remember there being some discussion here on
USB bus in the past,
and the general outcome was that
dom0 should not use the same USB controller
as is assigned to non-dom0 vm.
If that would be the case, then even if
the devices firmware would be reflashed,
it still wouldn't have access to dom0
(unless you would physically re-connect it
to the other controller of course).
Also...
the support for reflashing different USB devices
is questionable (possible, but unlikely).
Same with a USB device attacking different BIOS versions
 (again, possible, but unlikely).
And there's the question of
how does this all relate to trusted booting.
Well, there are many questions here I guess :)
That said, I'm really interested
what people more familiar with qubes/xen/trusted boot
have to say on this (/me looks at Joanna ;>).

Joanna Rutkowska 6:17 AM 

Regarding attacks coming via USB devices
and how we try to address those in Qubes OS
 -- I already wrote extensively about this
 some time ago: [2011/06/usb-security-challenges]

Generally USB keyboards is something we really don't like,
but luckily most laptops uses PS/2, which is good.
Are there software means to reflash firmware on
PS2 keyboard controller -- theoretically perhaps,
but in practice
I wouldn't waste much sleep about it.
Anyway, I'm surprised and disappointed that
Dragos' rootkit doesn't attempt to
hypnotize the victim using hidden images
displayed on the screen
to the deceitful (ultrasound) music played via the speakers!
I guess that's coming in the next version :)
Oh, and that reminds me how we once discussed at ITL
 a possibility to rent some billboards in the city
and place drawings with JPEG exploits embedded there,
so that when people take photos on the streets
their cameras/phones would get exploited
when compressing the photos :)
(Yeah, now this is much easier with QR codes,
 and not so fancy anymore)

me:

On Wed, Nov 6, 2013 at 6:17 AM, Joanna Rutkowska wrote:
[...]
> Generally USB keyboards is something we really don't like,
but luckily most laptops uses PS/2, which is good.
Are there software means to
reflash firmware on PS2 keyboard controller
-- theoretically perhaps,
but in practice I wouldn't waste much sleep about it.
[...]
>
it sounds like it might be safer to
use the laptop's keyboard only for
dom0, and the trusted vm's;
and then use the usb keyboard only for
untrusted domains .
> http://theinvisiblethings.blogspot.com/2011/06/usb-security-challenges.html
I much appreciated that article, Joanna,
but it didn't leave me with the impression that
I could get infected from my keyboard's controller;
it was about usb netvm pretending to be your keyboard,
or key-logging your usb keyboard .
I fear that usa's enemies are already owning
all computers, including xen and qubes,
and that they are waiting until doomsday
to exploit their back doors.

Joanna Rutkowska 8:37 AM

On 11/06/13 16:26, Ph.T wrote:
> it sounds like it might be safer to use the laptop's keyboard
> only for dom0, and the trusted vm's;
> and then use the usb keyboard only for untrusted domains .
This is not a correct conclusion.
You should be fine and safe using just
one keyboard for all the VMs, preferably PS2 keyboard.
The VMs do not have access to the underlying hardware,
 specifically to the keyboard controller
 (even if it was possible to reflash PS2 controller,
which it is not in practice).
>> http://theinvisiblethings.blogspot.com/2011/06/usb-security-challenges.html
> I much appreciated that article, Joanna,
> but it didn't leave me with the impression
> that I could get infected from my keyboard's controller;
> it was about usb netvm pretending to be your keyboard,
> or key-logging your usb keyboard .
>
> I fear that usa's enemies are already owning all computers,
> including xen and qubes,
> and that they are waiting until doomsday to exploit their back doors.
>
There is no spoon!

my unshared response:
web: "there is no spoon?":
Neo said that .
Do not try to bend the spoon — that's impossible.
Instead, only try to realize the truth:
there is no spoon.
Then you'll see that it is not the spoon that bends,
it is only yourself.

. basically "there is not spoon" means
you're deluded, or that you're
using the wrong approach .

. that reminded me of several things:
don't try to escape enemies owning your computer;
just remember there is no enemy;
there is only a war game dream
trying to recruit you .
. also, if it was true there is
a universal doomsday backdoor,
that sort of thing would be so disruptive
to all aspects of your life,
that it wouldn't matter if you found a secure machine,
because, you'll be preoccupied with sheer survival .

Franz 8:45 AM:

> http://theinvisiblethings.blogspot.com/2011/06/usb-security-challenges.html
This very clear article from Joanna
reports an aspect that I do not get clearly:
"Second, if somebody connects a USB disk
and later delegates it to some domain
(this could easily be done via block-attach mechanism,
supported by the same backend that handles
storage virtualization for domains),
and this domain turns out to be compromised,
it might alter e.g. the stick's partition table
and later attack Dom0 as explained above.
We can eliminate the second problem by
modifying the Dom0's kernel to
not automatically parse the partition table
of any removable devices,
and instead expect some kind of explicit consent
from user to actually do that
(we still must allow to mount USB disks in Dom0
to allow easy backups of all domains at once)."
1. Has Dom0's kernel been actually modified
to not parse the partition table
of any removable devices automatically?
2. Which is the explicit consent from user
to actually do that?  The mount command?
3. Apart from all that, a possible way to
deal with USB sticks and disks
would be to buy adhesive tape coloured in
black, green, yellow and red
and attach the corresponding tape
to each new USB memory
 and use each USB memory only for
Dom0, or  work, or personal, etc.
Would that be safe?
Best

Joanna Rutkowska 8:59 AM

On 11/06/13 16:45, Franz wrote:
> 1. Has Dom0's kernel been actually modified
> to not parse the partition
> table of any removable devices automatically?
>
No, we assume no untrusted stick
 should ever be attached to Dom0.
This can be easily achieved if one creates
a USB helper domain (a usbvm),
to which one assigns all the USB controllers.
When Xen finally gets their USB PV backend fixed,
[ ticket/704, ticket/531 ]
we will be creating such a domain automatically
during installation,
just like we currently do for netvm.
Until this happens,
the user must create it manually.
This, however, requires that
one doesn't have a USB keyboard,
as otherwise it makes not much sense.

[ Joanna Rutkowska 2012.10.3 on usbvm:
> Ive got a USB video camera, would this possibly allow it
 to be used with skype? without sharing the whole usb hub?
>
Yeah, if you got a UsbVM with a working pvusb backend,
then you could just assign one of the USB devices,
such as your camera, to some other AppVM
without moving the whole USB controller.
Which is why the support for pvusb is so desired...
]

> 2. Which is the explicit consent from user
to actually do that? The mount command?
> 3. Apart from all that, a possible way to deal with USB sticks and disks
> would be to buy adhesive tape coloured in black, green, yellow and red and
> attach the corresponding tape to each new USB memory and use each USB
> memory only for Dom0, or  work, or personal, etc.
> Would that be safe?
Depends how you assigned your USB controllers.
 If you have a whole USB controller assigned
to one of your (trusted) AppVMs,
then surely it makes sense not to physically
insert any untrusted USB devices there.
If, on the other hand, you use a usbvm,
then it's somehow less of a problem,
as most of the USB device processing
happens inside the usbvm
(which we assume is untrusted anyway).
In that case one should remember
that the usbvm can see
all the data written/read to/
from the USB device,
so encryption *in the AppVM*
should be used to secure your data.
If this is volume-based LUKS,
then you most likely eliminate also
all the attacks coming through filesystem
from the USB storage to your AppVM,
because, I assume, in that case the filesystem is trusted.

11.7:
Axon Nov 6 to qubes-devel:

So, just to clarify about this last point:
What exactly is the correct procedure
to safely use a USB stick with a trusted AppVM
if one uses a usbvm? Is it as follows?
1. Physically plug the USB stick into the machine.
2. In dom0, use qvm-block to attach the USB stick
(not the USB controller, which is assigned to 'usbvm')
to the trusted AppVM.
3. In the trusted AppVM,
unlock and mount the LUKS volume
which resides on the USB stick.
4. Add/Remove files to the mounted LUKS volume.
5. Unmount the LUKS volume.
6. In dom0, use qvm-block to detach the USB stick
from the trusted AppVM (i.e., re-attach it to usbvm).
7. Physically unplug the USB stick from the machine.
Is your last sentence saying that
even if the USB stick had been plugged into
a compromised machine (which had therefore
infected the USB stick, but in which
the LUKS volume had *not* been opened)
prior to this procedure being performed,
the fact that we use volume-based LUKSstorage
in steps 3-5 mitigates or eliminates
the risk of the trusted AppVM being compromised
by the infected USB stick?

Joanna Rutkowska 2:50 AM

>> Depends how you assigned your USB controllers.
If you have a whole USB controller assigned
to one of your (trusted) AppVMs,
then surely it makes sense not to
physically insert any untrusted USB devices there.
>> If, on the other hand, you use a usbvm,
then it's somehow less of a problem, as most of the USB device processing happens inside the usbvm
>> (which we assume is untrusted anyway). In that case one should remember
>> that the usbvm can see all the data written/read to/from the USB device,
>> so encryption *in the AppVM* should be used to secure your data. If this
>> is volume-based LUKS, then you most likely eliminate also all the
>> attacks coming through filesystem from the USB storage to your AppVM,
>> because, I assume, in that case the filesystem is trusted.
>>
>
> So, just to clarify about this last point: What exactly is the correct
> procedure to safely use a USB stick with a trusted AppVM if one uses a
> usbvm? Is it as follows? [...]
> Is your last sentence saying that even if the USB stick had been plugged
> into a compromised machine (which had therefore infected the USB stick,
> but in which the LUKS volume had *not* been opened) prior to this
> procedure being performed, the fact that we use volume-based LUKS
> storage in steps 3-5 mitigates or eliminates the risk of the trusted
> AppVM being compromised by the infected USB stick?
>
Yes, correct. Of course, theoretically,
the malicious machine could have somehow
malform the LUKS header in a way it might
hypothetically exploit the LUKS header parser
in the target (trusted) AppVM,
but in practice I would assume this to be
rather unlikely (i.e. existence of such a bug
in LUKS parser, as I would assume crypto software
should really be written in defensive way).
At least this is orders of magnitude better
compared to the traditional way
how we might plug the USB stick to the machine
which does all the USB stack processing
and partition table processing all by itself
(like it is on normal OSes,
or like it would be on a AppVM
with fully assigned USB).

Marek Marczykowski-Górecki 3:37 AM

Perhaps the compromised UsbVM could expose
some malicious partition table + filesystem
*instead* of our LUKS-ed device...
Or some other machine could override our LUKS partition
with such data (additional partition table).

Joanna Rutkowska 3:53 AM

Yeah, good point about the
partition table exposed by the usbvm.
Regarding exposing a filesystem instead of LUKS
-- I think this might be equivalent to
an attempt to expose a malformed LUKS header,
because we will try to open
whatever-is-exposed by the usbvm
with luks anyway.
Assuming the AppVM doesn't do
autmounting of the filesystem,
then the LUKS will simply not open this stream of bytes,
that just happens to be a filesystem...
So, perhaps a better approach would be to
use qvm-copy-to-vm for single encrypted files
from usbvm to the target AppVM.
Of course the problem of potentially
malformed crypto header always remains...

Joanna Rutkowska 3:54 AM 

Anyway, the more important question should be
-- why would anybody want to use a USB stick
with a trusted AppVM?
And why would anybody want to
plug it to some untrusted machines?

Joanna Rutkowska 6:35 AM

On 11/07/13 12:43, cprise wrote:
> To do most of the same things people do with USB sticks, only among a
> set of VMs and systems (and other users) that are all trusted.
>
[...]
Note that in Qubes OS
we have secure inter-VM copy mechanism
exactly to solve the problems
we talk about in this threat...
You might not remember,
but in the early days (alpha release of R1)
we implemented inter-VM copy via virtual USB stick,
but soon we changed that to the proper mechanism
which doesn't require any virtual block devices.

cprise 7:27 AM [reasons for using a flash drive:]

1. Sharing files between different
physical (trusted) systems and users,
without having to arrange a networking link.
There are always technical and motivational
reasons to resort to sneakernet,
which is a mainstay of personal computing.
2. Psychological reasons:
A USB stick allows a user to
turn a collection of files into a
physical presence in their desk or pocket.
It fulfils a (sometimes) need to
think about a project in a more tangible way.
3. Privacy and security.
Sometimes a whole computer system
is not the best place to
keep private files from prying hands.
A computer is a big target.
Its also easier to remember to
dismount a drive sticking from the side of the computer
than specially curated/mounted disk volumes
buried in a folder heirarchy...
the USB stick is more likely to be offline
(no key in memory) if one's computer is
snatched while running or sleeping.
As for reasons unique to Qubes
for accommodating USB drives:
A) You can't really differentiate them from
USB hard drives in terms of
either utility or threat,
and Qubes needs secure encrypted external HDs too
(otherwise, backups become an untrusted
and weak aspect of the platform).
Other systems don't set as high an expectation.
B) If the badBIOS/ USB or similar infection is real,
a Qubes appvm/encryption facility could be
an early and large piece of the solution
that helps raise the project's profile.
Also, think about techies and people who manage IT:
You have a long history of
collecting these drives which are suddenly
a nasty threat known even to
TV personalities and imbeciles...
and they're *everywhere* (the drives, that is)...
in every shape and size down to a pinky nail,
laying around just waiting to get picked up
and plugged in.
If Qubes had a usbvm or similar solution,
and I could choose which VMs were
forbidden from mounting unencrypted volumes,
it would look like the greatest thing since sliced bread.
The alternative would be disabling USB
and forming a new 'cloud' only ethic,
and I don't know about you but
the very thought of that makes me gag. :)

Franz 7:59 AM 

Yes, these UBS keys are ubiquitous for some reason.
If I need to give a large amount of
photos or videos to some other people,
this is by far the more practical way to do it.
Yes, I understand Axom's list of
steps to use these things securily.
But for untrusted files,
it seems safe to simply
assign a USB controller to an untrusted VM
and use these USB keys only with that untrusted VM
without worrying much more.
Correct?
Best

30:
Axon Nov 8

What I don't know is whether
the files on a USB stick should be untrusted
because of the USB stick itself.
So, for example,
let's say someone I trust ...
gives me a USB stick with some
important and/or confidential files on it.
I want to store those files on my Qubes machine.
But I don't know whether the machine(s) which the USB stick
has been plugged into were clean or not.
Does this mean that any files I transfer off the USB stick
should automatically go into a "red" domain?
Whereas if I had downloaded those files
over HTTPS or something,
they could go into a "green" domain?
In other words, are the files untrusted
simply because of the medium (USB stick)? 

joanna Nov 8

The files (e.g. PDFs, or Power point presentations)
might very well be untrusted because
they might be maliciously malformed
and will attempt to exploit hypothetical bugs
in the app you use to open them
(PDF reader, Open Office, etc).
And they might be malformed because
the person who gave them to you is malicious.
Or because his or her computer was compromised.
So, I would not really attempt to
distinguish between the files and the USB stick
-- both can be malicious.
Do you need to copy them to "red"
insecure domain used for all the bad things?
Not necessarily.
Imagine you were one of those people who got
files from Snowden -- in that case
I would just create a domain: "snowdengate"
and put everything there (not necessarily red-labeled,
I would e.g. label it black).
[nothing is done with this vm except
read files to another vm as needed ]
If the files were indeed malicious
and indeed tried to exploit this VM... well no problem.
joanna.