epoxy on ram to prevent cold boot attacks?

[pixel fairy]

poured some epoxy over where the ram connects to the motherboard, and where the clips are that you would use to take it out. the chips themselves dont have any, just the surrounding pcb.

this was couple days ago. so far its survived 2 reinstalls of test qubes releases, and is doing one of rc3.

i have this feeling im about to find out theres some simple way around this and its not really a protection against cold boot attacks. i know some laptops have easy bios resets, so thats one way.

[grzegorz....@gmail.com]

An actual protection would be some kind of a chemical that would destroy the ram chips if they ever reach certain (lower than room) temperature.

[pixel fairy]

On Wednesday, August 31, 2016 at 10:40:23 AM UTC-7, grzegorz....@gmail.com wrote:

> An actual protection would be some kind of a chemical that would destroy the ram chips if they ever reach certain (lower than room) temperature.

the epoxy is likely to damage them in most means of removal.

i know of things that can do their damage when they reach a certain temperature or higher. never heard of one set off by going below a certain temp.

erasing on power loss would be good too, esp if the attacker doesnt know about it.

[johny...@sigaint.org]

> Lately, I've been leaving it on, but with an alternative OS
> (another Linux) whose sole purpose is to know if somebody's been mucking
> around. My actual useful drive, data, passwords, go with me.

My keyboard also goes with me, which is the main inconvenience currently.

I think most common keyloggers require someone to pick up the payload in
person while you're out (with some magical password combination that gets
the keyboard to spew what it's been seeing). If the keyboard's with me,
they will never get the chance.

Unless that sucker is broadcasting... Which, ummm, I guess they all kind
of are in a SIGINT kind of way:
https://www.sigmobile.org/mobicom/2015/papers/p90-aliA.pdf

I'm sure there are fake/trojan keyboards that actively broadcast on
wifi/bluetooth without your knowledge. RF detection/quieting can help
with that risk.

One of my current side-projects is a strongly encrypted keyboard. Just
uses a PS/2 connector, but encrypts the channel with xxtea to a small
driver/xinput stub/decoder on the Linux side. So even SIGINT style
monitoring wouldn't pick up anything useful.

(The sound/vibration methods of decoding typing can be mitigated a bit
with damping feet/neoprene base, and some other quieting techniques.)

A shorter-term personal project is to hack the existing keyboard's
controller to be socketed or on a daughter board. Taking that with me
would be easier than the entire keyboard, and just leave some useless (and
stateless) contact switches and wire behind. :) Plus a clear (or
missing) top case to spot any other unauthorized changes.

I'm curious to some mentions-in-passing about Andrew's hate for USB
keyboards. USB-anything isn't good for security, but what in particular
so much worse about USB? Both USB and PS/2 can keylog, or play predefined
scripts to try and exploit the system. One of the dangers of rogue USB
devices is that they can suddenly pretend to be a keyboard (which Linux
will accept without confirmation, something I'm not thrilled about).

But a keyboard is already a keyboard, it doesn't need to pretend. :)

Is it that USB devices can spy on the whole bus? (Is that true? I think
I read it somewhere.)

(I do personally prefer PS/2, as it's simpler, less hackable, and
something I can more easily interface with for my own encrypted keyboard
project.)

Related, I don't think mouse tracking can be turned into anything useful
nor exploitable, as long as the mouse stays a mouse and doesn't go rogue
and suddenly show up as a keyboard and start typing an exploit.

And I'll digress one step further: it might be worth "hardening" the xfce4
GUI so that no dom0 window or menu can be fired up (by default) from the
keyboard. That way, if a keyboard did go rogue in the GUI, and I don't
keep existing dom0 windows about, it can't open a dom0 window.

(I know, I know; if the keyboard/GUI is compromised, you can probably say
good-bye to dom0 and your computer overall, regardless. Some a bit of
extra protection wouldn't hurt.)

Enough rambling.

JJ

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Aug 31, 2016 at 10:05:59PM -0000, johny...@sigaint.org wrote:
> I'm curious to some mentions-in-passing about Andrew's hate for USB
> keyboards. USB-anything isn't good for security, but what in particular
> so much worse about USB? Both USB and PS/2 can keylog, or play predefined
> scripts to try and exploit the system. One of the dangers of rogue USB
> devices is that they can suddenly pretend to be a keyboard (which Linux
> will accept without confirmation, something I'm not thrilled about).

It is mostly not about the keyboard itself, but other devices on the
same bus. Anything that can control the bus to which keyboard is
connected, can control the keyboard / pretend to be a keyboard.
In addition, USB is quite complex and as with all complex code there are
bugs.
If you (or someone else) plug a malicious USB device that will exploit
some bug in one of million USB device drivers, it can do whatever it
want with the other USB devices on the same bus. And if that USB
controller live in dom0, it's game over even without injecting malicious
keystrokes.
PS/2 is much better, because you can't connect anything else than input
devices there, and attack surface is much smaller.

Some mitigation would be to use separate USB controller for USB
keyboard/mouse and have it in dedicated VM (separate form all-purposes
sys-usb).
This will guard you from potentially malicious devices *you* plug into
the system, but not from someone else plugging it instead of keyboard
(so into that keyboard-only USB controller). To plug that hole, that
USB-keyboard VM should be configured to reject any non-keyboard device
before allowing any driver to talk to it. This will still left you
vulnerable for bug in USB stack itself, but the attack surface is much,
much smaller than all the USB devices drivers (some unmanaged for
years).

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXx5GcAAoJENuP0xzK19cstXgH/2+qnvTd7y00TSaUuAqjgUUI
waSjgeZnXfuGn8WMIRaGn4sIAqG4VgL1JP8sStWGHzAktOnqU/BHmaMAgipVvDpy
60a0SumEE1kZ8RUbIzINuTlZVmXw/7Dt1NCA0FOJbkjn4UeiuRvCkKceedJXrV9a
m3HoCGTu1qgZB9B4m+TvPtgeqUrUj/bvsLkgPJbVKiOWevIJ7M57cabDk/6P3p0q
QMHT6yPqcEXrA3SKAay/LDTvwP6C67jXjkCsvQYPX1TNrCZzEkvYyA3P4ycblBlM
Pq3MmSlPTLkiHorupOERDZi7mON2lss23aaj0AXvClgO03V8ArPjDnnmxHEWW9A=
=za1M
-----END PGP SIGNATURE-----

[johny...@sigaint.org]

> On Wed, Aug 31, 2016 at 10:05:59PM -0000, johny...@sigaint.org wrote:
>> I'm curious to some mentions-in-passing about Andrew's hate for USB
>> keyboards. USB-anything isn't good for security, but what in particular
>> so much worse about USB? Both USB and PS/2 can keylog, or play
>> predefined
>> scripts to try and exploit the system. One of the dangers of rogue USB
>> devices is that they can suddenly pretend to be a keyboard (which Linux
>> will accept without confirmation, something I'm not thrilled about).
>
> It is mostly not about the keyboard itself, but other devices on the
> same bus. Anything that can control the bus to which keyboard is
> connected, can control the keyboard / pretend to be a keyboard.

I can understand pretending to be the keyboard, but seeing the keyboard's
traffic, controlling the keyboard is really possible from another device
on the bus? If so, what a fatal flaw in the design of USB.

> In addition, USB is quite complex and as with all complex code there are
> bugs.

I hear you. I've bit-banged PS/2 protocols myself, and it's not that
hard. VUSB has achieved the same with USB, but its a *huge* project (and
can barely achieve HID use).

> If you (or someone else) plug a malicious USB device that will exploit
> some bug in one of million USB device drivers, it can do whatever it
> want with the other USB devices on the same bus. And if that USB
> controller live in dom0, it's game over even without injecting malicious
> keystrokes.

Yikes. USB really needs to get out of dom0 all together, just as
networking has. I'd also like to see the sound card in its own VM. With
Pulse's networkability, it shouldn't be that hard. One could use the
Pulse network ability instead of virtualization of the sound card.

That might also be the best route to getting sound working in Windows
HVM's, although some work is needed on Windows Pulse clients:

https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3

When I assign a single USB drive to a VM, is dom0 still really in charge
of the USB bus, and just shuffling stuff back and forth to the VM(s)?

> PS/2 is much better, because you can't connect anything else than input
> devices there, and attack surface is much smaller.

Agreed. It's all I use for mouse/keyboard.

> Some mitigation would be to use separate USB controller for USB
> keyboard/mouse and have it in dedicated VM (separate form all-purposes
> sys-usb).

Another possibility is some built-in Qubes support for building udev rules
(similar to how the firewall makes iptables rules), or perhaps adding
USBGuard to dom0 (or any USB Qube). A good comparison of the two options
is here:

https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev

Seems like a great idea for Qubes in mitigating USB dangers, since in
practice it is so hard to avoid USB all together. And that problem is
only getting worse.

One dodgy USB device from the dollar store, and your pwned. Or an
NSA/syndicate-implanted commercial hard drive with alternate identities
lurking.

I'm always tempted, but ultimately avoid, unusually low-priced USB
devices, lol.

I've been passed USB keys from some rather suspect individuals in the
past; I've quarantined them, and should (carefully, on a non-critical
system) take a more detailed peek someday, lol.

Some discussions online argue that USB white-listing isn't helpful, since
a BADUSB could just emulate your actual keyboard. Well, it would have to
know the device ID's first.

Even if it gloms my keyboard's USB vendor/device ID's and tires to imitate
it, the system could spot the fact that there's a second similar device
but on another USB port, no? Or is USB so stupid that the system couldn't
differentiate the two (or the fact that there is two)?

While the USBGuard project looks admirable, I'm guessing the more
attractive option would be for Qubes to add support for creating custom
udev whitelists, as the less software in dom0, the better.

Although USBGuard isn't a huge project (the tarball is <1M) and if you're
going to otherwise have to write the code yourself, it might be better to
just audit USBGuard and include it in some form. If someone else has
already put in much of the required thought and effort . . .

Even a pop-up notification when a new HID device is added could be useful.
The fact that keyboard/mice are silently accepted is a bit scary. I
might add some scripts to watch dmesg for such events, and more actively
warn me.

All just food for thought.

I'll be adding udev whitelist rules to dom0 very shortly.

Another idea I saw was restricting HID devices to *one* keyboard and *one*
mouse, so if a BADUSB comes along trying to be another keyboard, it
doesn't work. Or even better, alarm bells go off.

I was thinking earlier that some form of a "USB Firewall" hardware device
might be cool to create; one that goes into each USB port in between each
device and the PC, and only passes a specific device, or only a HID device
(and doesn't permit a drive to add another HID identity). Yet another
side project for winter. :) There may be existing products.

> This will guard you from potentially malicious devices *you* plug into
> the system, but not from someone else plugging it instead of keyboard
> (so into that keyboard-only USB controller).

This is scary:

https://hakshop.myshopify.com/collections/usb-rubber-ducky/products/usb-rubber-ducky-deluxe?variant=353378649

> To plug that hole, that
> USB-keyboard VM should be configured to reject any non-keyboard device
> before allowing any driver to talk to it. This will still left you
> vulnerable for bug in USB stack itself, but the attack surface is much,
> much smaller than all the USB devices drivers (some unmanaged for
> years).

Very interesting. Where dom0 is currently in charge of the
keyboard/mouse, and I assume won't be separated out (even by 4.0?), I
think some udev rules or USBGuard might be called for.

JJ

[johny...@sigaint.org]

> This is scary:
>
> https://hakshop.myshopify.com/collections/usb-rubber-ducky/products/usb-rubber-ducky-deluxe?variant=353378649

Related, and (disturbingly) informative:

https://github.com/brandonlw/Psychson

JJ

[johny...@sigaint.org]

I wrote:
> Another possibility is some built-in Qubes support for building udev rules
> (similar to how the firewall makes iptables rules), or perhaps adding
> USBGuard to dom0 (or any USB Qube). A good comparison of the two options
> is here:
>
> https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev

After reading this comparison:

https://dkopecek.github.io/usbguard//blog/2015/USBGuard-vs-UDev

I though the huge difference in simplicity of rules that USBGuard brings,
it was worth trying out. Not wanting to just grab a binary of a project I
had just learned about, I thought I'd grab the sources and compile:

https://dkopecek.github.io/usbguard/documentation/compilation.html

Sounded simple enough, but wow, I delved into dependency hell, a lot due
to the Qt applet (which sounds cool) that brings in Qt5 and a bunch of
other things. I gave up after hunting down dependencies for an hour or
two, after failing to find a few "dbus modules" that were required.

It brings in way too many dependencies, and is way to hard to build, for
my comfort level, especially for a dom0 app. Such a shame. (Maybe when I
recover from the frustration, I'll try again without the Qt applet.)

It makes learning the strange udev rules syntax a lot less intimidating
after all :)

There really should be some simpler system to turn declarative USB
permissions into udev rules. USBGuard seemed like it, but it's far too
complex internally for my tastes. Some m4, python, bash scripts, and/or
make should be able to do the job without all the complexity.

These tutorials give the spirit of the type of thing I'd like to see
automated a bit:

http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devices#3.2_Locking_down_Linux_using_UDEV

https://askubuntu.com/questions/531445/only-use-mass-storage-devices-on-a-selected-usb-port-how

A simple lockdown:

https://incenp.org/notes/2014/disable-new-usb-input-devices.html

JJ

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Sep 01, 2016 at 06:55:05AM -0000, johny...@sigaint.org wrote:
> > On Wed, Aug 31, 2016 at 10:05:59PM -0000, johny...@sigaint.org wrote:
> >> I'm curious to some mentions-in-passing about Andrew's hate for USB
> >> keyboards. USB-anything isn't good for security, but what in particular
> >> so much worse about USB? Both USB and PS/2 can keylog, or play
> >> predefined
> >> scripts to try and exploit the system. One of the dangers of rogue USB
> >> devices is that they can suddenly pretend to be a keyboard (which Linux
> >> will accept without confirmation, something I'm not thrilled about).
> >
> > It is mostly not about the keyboard itself, but other devices on the
> > same bus. Anything that can control the bus to which keyboard is
> > connected, can control the keyboard / pretend to be a keyboard.
>
> I can understand pretending to be the keyboard, but seeing the keyboard's
> traffic, controlling the keyboard is really possible from another device
> on the bus? If so, what a fatal flaw in the design of USB.

On, it's about compromising system to which such USB device is
connected.

> > In addition, USB is quite complex and as with all complex code there are
> > bugs.
>
> I hear you. I've bit-banged PS/2 protocols myself, and it's not that
> hard. VUSB has achieved the same with USB, but its a *huge* project (and
> can barely achieve HID use).
>
> > If you (or someone else) plug a malicious USB device that will exploit
> > some bug in one of million USB device drivers, it can do whatever it
> > want with the other USB devices on the same bus. And if that USB
> > controller live in dom0, it's game over even without injecting malicious
> > keystrokes.
>
> Yikes. USB really needs to get out of dom0 all together, just as
> networking has. I'd also like to see the sound card in its own VM. With
> Pulse's networkability, it shouldn't be that hard. One could use the
> Pulse network ability instead of virtualization of the sound card.

Actually our VM audio solution is based on something like this: passing
raw samples (similar to pacat + module-simple-protocol-unix) over vchan
link - socket-like inter-VM connection. See here:
https://github.com/QubesOS/qubes-issues/issues/1590

> That might also be the best route to getting sound working in Windows
> HVM's, although some work is needed on Windows Pulse clients:
>
> https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3

I've looked at it few years ago and it was outdated/unmaintained at that
time already. I gave up on setting this on Win 7. I bet now it's even harder.

> When I assign a single USB drive to a VM, is dom0 still really in charge
> of the USB bus, and just shuffling stuff back and forth to the VM(s)?

If you assign a single USB device to VM (using qvm-usb or qvm-block),
then yes - all the nasty USB stuff is still handled in dom0/sys-usb.
Only assigning the whole USB controller (PCI device) to a VM will move
USB processing out of dom0.

> > PS/2 is much better, because you can't connect anything else than input
> > devices there, and attack surface is much smaller.
>
> Agreed. It's all I use for mouse/keyboard.
>
> > Some mitigation would be to use separate USB controller for USB
> > keyboard/mouse and have it in dedicated VM (separate form all-purposes
> > sys-usb).
>
> Another possibility is some built-in Qubes support for building udev rules
> (similar to how the firewall makes iptables rules), or perhaps adding
> USBGuard to dom0 (or any USB Qube). A good comparison of the two options
> is here:
>
> https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev

Very interesting project indeed. And it is packaged in Fedora!
But as you've noted below, if all we need can be done using udev rules,
it's better to not introduce another complexity.

> Seems like a great idea for Qubes in mitigating USB dangers, since in
> practice it is so hard to avoid USB all together. And that problem is
> only getting worse.
>
> One dodgy USB device from the dollar store, and your pwned. Or an
> NSA/syndicate-implanted commercial hard drive with alternate identities
> lurking.

The whole idea of having separate USB VM is to not care about USB
related compromise. It isn't fully possible with all kind of devices (like
USB camera - compromised USB VM will be able to sniff the traffic), but
it is surely an improvement.
It would make sense to have Disposable USB VM - I hope we'll manage to
have it in Qubes 4.0.

> Some discussions online argue that USB white-listing isn't helpful, since
> a BADUSB could just emulate your actual keyboard. Well, it would have to
> know the device ID's first.

Yes. But then, such device would be able to communicate with
only one driver - of that keyboard. Not arbitrary chosen one of hundreds
of them -> large reduction of attack surface.
Of course, if it hit unlocked system (or locked, but know the password),
controlling keyboard means controlling the whole system. But you can
guard against such attacks with 2FA:

https://www.qubes-os.org/doc/yubi-key/ (check also "USB keyboard" link
at the top)

> Even if it gloms my keyboard's USB vendor/device ID's and tires to imitate
> it, the system could spot the fact that there's a second similar device
> but on another USB port, no? Or is USB so stupid that the system couldn't
> differentiate the two (or the fact that there is two)?

If it will clone all the device properties (vendor, product, interface
etc), you'll see two identical devices. The only way to differentiate
them would be to look to which port are plugged.

> While the USBGuard project looks admirable, I'm guessing the more
> attractive option would be for Qubes to add support for creating custom
> udev whitelists, as the less software in dom0, the better.

It all make sense _in addition_ to move USB out of dom0, to USB VM
(sys-usb, or multiple of them).

> I was thinking earlier that some form of a "USB Firewall" hardware device
> might be cool to create; one that goes into each USB port in between each
> device and the PC, and only passes a specific device, or only a HID device
> (and doesn't permit a drive to add another HID identity). Yet another
> side project for winter. :) There may be existing products.

This is indeed interesting project. I think I've seen something similar
for USB storage (to avoid USB disk pretending being a keyboard). But the
one designed specifically for HID devices could do one additional
thing: encrypt+sign all the traffic. Then such encrypted HID traffic
would be decrypted in dom0, so USB VM would _not_ know the key and even
when compromised will have very little ability to manipulate real
keystrokes (or inject additional ones).

This will not guard against some timing attacks etc, but still would be
an improvement.

> > This will guard you from potentially malicious devices *you* plug into
> > the system, but not from someone else plugging it instead of keyboard
> > (so into that keyboard-only USB controller).
>
> This is scary:
>
> https://hakshop.myshopify.com/collections/usb-rubber-ducky/products/usb-rubber-ducky-deluxe?variant=353378649
>
> > To plug that hole, that
> > USB-keyboard VM should be configured to reject any non-keyboard device
> > before allowing any driver to talk to it. This will still left you
> > vulnerable for bug in USB stack itself, but the attack surface is much,
> > much smaller than all the USB devices drivers (some unmanaged for
> > years).
>
> Very interesting. Where dom0 is currently in charge of the
> keyboard/mouse, and I assume won't be separated out (even by 4.0?), I
> think some udev rules or USBGuard might be called for.

Even when USB keyboard is used, it is still good idea to move USB
controller out of dom0. This may not be easy in some cases (if your USB
VM crash, you'll lose keyboard access), but at least will make attacks
slightly harder (from "run any code you want", to "inject any
keystrokes").

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXyHkBAAoJENuP0xzK19cs+qMH/2wnIuv/qFYc7jYJ1wp/CeU4
OsA4S6YcrXCwRIeIijmJPJVRczU9hdZZlSQUXaapcKaveyWAiA0B6OThFTPkPs0e
nRe/WDFZevZMdTppJbpU6XwjReXrsj/MpaI49AJ4Qcyc5rJmjYZbRR0dM+7ueODF
4Oi4Ho0f2RMn78oIQRFoAe7pyShq9I+As1gb5NU/Oaf4PERKie6RoWQAzzl8Rlib
xcHysXAozvqaKkJU4tyu6zlupP6pQieG3+SESWH3uhXzxv/dsvQal0Eao1gMYO6h
C9FI9Ol+9PQ9/1wFu/+CB8xdRBwAxmn6G5oSBvTK/kLZVgQsJ3htQgdPCur37Io=
=NkRK
-----END PGP SIGNATURE-----

[johny...@sigaint.org]

>> https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3
>
> I've looked at it few years ago and it was outdated/unmaintained at that
> time already. I gave up on setting this on Win 7. I bet now it's even
> harder.

Yes, weird how neglected it is. Do people not write utility software for
Windows now? Is it too locked down by MS (expensive signing) or too
insecure for anyone to bother coding?

Remote sound seems like the type of thing a lot of power users would want,
even on Windows.

>> When I assign a single USB drive to a VM, is dom0 still really in charge
>> of the USB bus, and just shuffling stuff back and forth to the VM(s)?
>
> If you assign a single USB device to VM (using qvm-usb or qvm-block),
> then yes - all the nasty USB stuff is still handled in dom0/sys-usb.
> Only assigning the whole USB controller (PCI device) to a VM will move
> USB processing out of dom0.

So other than the potential of bugs in the stack, and faking a
keyboard/mouse, there's really nothing a USB device could do to provoke
any action (break-in attempts) in dom0?

Would a USB Wifi dongle auto-configure as a second adapter on Qubes? (I
might check that myself later.)

Mass storage devices will be noted by dom0, but nothing silly like autorun
could happen (unless you set it up manually). Device impersonation is a
threat, I suppose. Can one USB device effectively "bus master" to probe a
disk or something like that?

Any other device type that could be a threat via USB?

As long as you have a solid stack and reject HID/network, USB might not be
quite as scary as I thought.

Once you get your keyboard/mouse off of USB. That recipe for rejecting
HID in one of those links worked great,
/etc/udev/rules.d/99-disable-usb-input.rules:

ACTION=="add", SUBSYSTEM=="input", SUBSYSTEMS=="usb",
ATTRS{authorized}=="1", \
ENV{PARID}="$id", RUN+="/bin/sh -c 'echo 0
>/proc/bus/usb/devices/$env{PARID}/authorized'"

Any new attempts to insert HID devices are ignored.

I suppose there's a window at boot time before udev configures where a
rogue USB device could impersonate a HID device and try to hijack the
system (e.g. right at grub). But supervising any boots for any oddness is
trivial (and a good idea).

>> https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev
>
> Very interesting project indeed. And it is packaged in Fedora!

Noooooooo!!! Lol, I spent hours trying to get that to build. I had
checked for packages under debian-8, found none, so figured Fedora was
even less likely to have it (being more conservative).

I was even building it under a bare-bones Fedora-23 VM. I could have just
dnf'd it.

That's a great thing, presumably having undergone review from the Fedora
folks to be in the main repositories. (If Qubes can't in turn trust
Fedora and its repo, it's toast from the start.) But I assume you still
don't increase the amount of running dom0 software lightly.

Installing it only brought in libqb (102k) and itself (206k), so it's
fairly lightweight. Might see how well it agrees with dom0. :P

> But as you've noted below, if all we need can be done using udev rules,
> it's better to not introduce another complexity.

With Fedora's review (and a fairly small package), I feel a lot more
comfortable with it, perhaps as an option. Making it easier for people to
track/configure USB devices is a pretty compelling selling point.
Possibly outweighs the risk of the minimal additional of dom0 software.

> The whole idea of having separate USB VM is to not care about USB
> related compromise. It isn't fully possible with all kind of devices (like
> USB camera - compromised USB VM will be able to sniff the traffic), but
> it is surely an improvement.

Leaving any camera or microphone connected at all isn't for the highly
security conscious. :)

> It would make sense to have Disposable USB VM - I hope we'll manage to
> have it in Qubes 4.0.

That's interesting. So, for example, you could possibly configure it such
that if a certain device is inserted, a disposable VM could pop up,
attached to that USB device, that could then run an app (such as keepass).
When you're done, the DVM goes away. That's rather tidy. And safer.

I assume memory freed from a dead VM is wiped upon freeing by Xen? Or at
least wiped before allocating it elsewhere?

>> Some discussions online argue that USB white-listing isn't helpful,
>> since
>> a BADUSB could just emulate your actual keyboard. Well, it would have
>> to
>> know the device ID's first.
>
> Yes. But then, such device would be able to communicate with
> only one driver - of that keyboard. Not arbitrary chosen one of hundreds
> of them -> large reduction of attack surface.

I suppose even a brute-force search of device ID's through the relatively
few vendors is feasible (without some protection).

> Of course, if it hit unlocked system (or locked, but know the password),
> controlling keyboard means controlling the whole system. But you can
> guard against such attacks with 2FA:
>
> https://www.qubes-os.org/doc/yubi-key/ (check also "USB keyboard" link
> at the top)

I really like two-factor. I'm not sure I'd trust any such device I
received via the post, though, lol. You'd really want to get a device
verified from a trusted source. Or roll your own.

One-time-passwords are very interesting as well. The otpw package and a
related PAM package can let you hook in the features. Gives you printable
numbered lists of passwords to hang onto safely. The system will prompt
you for one by number, and you also have a prefix password component as
well (so a stolen list doesn't necessarily give up the keys).

Should be relatively easy to hook into dom0 for the screen lock. More of
an advanced user feature, likely.

> This is indeed interesting project. I think I've seen something similar
> for USB storage (to avoid USB disk pretending being a keyboard). But the
> one designed specifically for HID devices could do one additional
> thing: encrypt+sign all the traffic. Then such encrypted HID traffic
> would be decrypted in dom0, so USB VM would _not_ know the key and even
> when compromised will have very little ability to manipulate real
> keystrokes (or inject additional ones).

I like the idea of

> This will not guard against some timing attacks etc, but still would be
> an improvement.

Are timing attacks much of a problem? I would think they're fairly rare.?

And few VM's actively doing different things, it's probably even more
challenging and less of a threat than a more monolithic system.

JJ

[johny...@sigaint.org]

> On Wednesday, August 31, 2016 at 10:40:23 AM UTC-7, grzegorz....@gmail.com
> wrote:
>
>> An actual protection would be some kind of a chemical that would destroy
>> the ram chips if they ever reach certain (lower than room) temperature.
>
> the epoxy is likely to damage them in most means of removal.

I guess most people have shinier (literally, on the contacts) new hardware
than I do, but I know now and then I need to re-seat my RAM chips when the
system gets cranky. Epoxy would a pretty costly measure (probably
destroying the motherboard as well as the RAM). I guess I'd have to get a
shinier new mobo in that case. :)

I think case security and case (and room) intrusion detection is a bit
more "civilized."

> i know of things that can do their damage when they reach a certain
> temperature or higher. never heard of one set off by going below a certain
> temp.

While interesting, that seems like a bad idea. Unless you're UPS'd up and
never need to modify your hardware, insert/remove a card, whatever, you're
gonna have a bad day eventually and lose your ram/mobo.

> erasing on power loss would be good too, esp if the attacker doesnt know
> about it.

This, I do like, possibly hooked into case intrusion. I might just look
into that myself, see if there's certain RAM pins that can be safely
grounded to wipe the RAM in a case of power outage. I expect it's more
difficult than that, and that the RAM would have to be actively wiped,
since a power-off should basically be more or less equivalent to grounding
all the RAM pins, no?

Now, frying the memory with a high voltage zip from a charged up cap, say,
on some chip-enable line or whatever, if there is a case intrusion without
the proper trick done to disable it (such as a 16-dip-switch combination
lock that has to be set properly) might be kind of cool. :) You'd want
some gate to isolate that line (or thew whole chip) from the motherboard,
to protect it.

Maybe a capsule of acid on the ram chips (and contained to only affect
them) that gets popped on command. It'd be fun to burn the sticky fingers
of any intruder, too. :) Getting a bit fanciful here...

On that same line of thought, sending 120V to the case if it's opened
while the power is on (which is the mode of action for a cold boot attack,
I assume?) might be fun. You might want to remove your Underwriter's Lab
logo from the PC if you rig that up, lol. Getting into "Home Alone"
territory.

If you keep your PC on when you're away from it (which I think is safer,
and I guess is the situation when you need protection from a cold boot
attack), you could do something like immediately start wiping the RAM upon
case intrusion. That'd be harmless in the case of legitimate maintenance,
too. Seems much cleaner.

I wonder what the most straight forward method of stopping all
multi-tasking and starting to wipe the ram would be. Could a dom0 bash
script, watching an intrusion detection device, simply do an "xl pause" or
whatever on all VM's and start writing to some /proc memory device?

(That's probably not going to work, you'd need something more
ring-zero-ey...? Perhaps in a device driver. When I try to use my
on-board NVidia, it does a good job of locking up the computer and wiping
the RAM itself, after awhile, lol.)

It'd have to be reasonably fast at starting its work. And writing to
4g/8g of memory is going to take some time, in the best case. Which adds
points in the favour of the more destructive high-voltage zap method.
(Maybe not a sequential write, but a bit more randomized one would thwart
any attacker better?)

There may be some existing work done on this for xen; I might do a bit of
research and report back if I find anything useful.

Interesting subjects to ponder.

In my case (pun intended), there's not anything sensitive or incriminating
on my drive or in memory; it's more a matter of protecting privacy and
attempting to stop ongoing harassment and illegal surveillance.

Stealing some work designs or code or personal information would be
annoying, but it wouldn't jeopardize my life, land me in jail, or have me
detained for waterboarded or anything.

So knowing someone was tampering is good enough for me, and what I have
personally focused upon.

I'd be interested in others' thoughts on leaving the PC on versus leaving
it off. Lately, I've been leaving it on, but with an alternative OS

(another Linux) whose sole purpose is to know if somebody's been mucking
around. My actual useful drive, data, passwords, go with me.

It's only slightly inconvenient, but so far it has been the quickest route
towards some peace of mind until I'm 100% confident in physical security
and tamper detection.

Sorry for any digression.

JJ

>
> --
> You received this message because you are subscribed to the Google Groups
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-users...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/11f811f4-eaaf-41dc-824e-7f39b374bbdd%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

[Anon]

Marek Marczykowski-Górecki:

> If you (or someone else) plug a malicious USB device that will exploit
> some bug in one of million USB device drivers, it can do whatever it
> want with the other USB devices on the same bus. And if that USB
> controller live in dom0, it's game over even without injecting malicious
> keystrokes.
> PS/2 is much better, because you can't connect anything else than input
> devices there, and attack surface is much smaller.

After having read the entirety of the PC security paper Joanna wrote a
while back, I was shocked to see how poor PC security really is. I found
it one of the most profound papers I've ever read. As far as I'm
concerned, it should be required reading for anyone capable of
understanding even the basics.

What you wrote reminds me of that feeling and how wide open and
vulnerable things really are for those that know what they're doing.
It's amazing to me things have been "allowed" to get this bad.

All genuine efforts into making things better are very much appreciated
and needed by all of us. Thank you.

[Robert Fisk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 09/01/2016 06:55 PM, johny...@sigaint.org wrote:
> I was thinking earlier that some form of a "USB Firewall" hardware
> device might be cool to create; one that goes into each USB port in
> between each device and the PC, and only passes a specific device,
> or only a HID device (and doesn't permit a drive to add another HID
> identity). Yet another side project for winter. :) There may be
> existing products.

Ahem. Allow me to introduce you to a project I have been working on
for a while now:

https://github.com/robertfisk/usg/wiki
https://github.com/robertfisk/USG/wiki/FAQ

The USG (which is Good, not Bad) is a hardware firewall for your USB
ports. It connects between your computer and your untrusted USB
device, isolating the badness with two dedicated processors.

Features:
- Isolates low-level USB exploits by using a simple internal protocol
with minimal attack surface

- No hub support blocks 'hidden' malicious devices

- Prevents devices changing their enumerated class after connection,
stopping malicious class changes.


Device support: mass storage (flash drives), keyboards, mice.

Project status: You can build your own USG v0.9 hardware out of
development boards if you are handy with a soldering iron. End user
hardware is approaching production-ready status, samples will be
available in the coming months.

Feedback / pull requests / sales leads are welcome!

Robert

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXy8C+AAoJEN65WsAVra66zQEP/jJMgf8FnaLW9jLCb13dZbkM
IQQ50CgOFyzVF+S//FlZ794k9qfMFxumxfVMATawsTBooNhlTa9ASedMrcoWMuZI
fuYNMeVoSYijyavqvimHMS8axiKwaI48q6olrTsOKwDM6joBb3rKQnsv63NJlbH3
+qUOY9IVDSoFKG9ki9TpltknlYuI3NDIkPRr07Ekx5XiCs92CihuNn1xTlCtweEt
4Y1YtPv2HfYFGcbQk2w17efp0mFweiqZldsxbwNLEPv03GvrNg54vlxC1Yr8ByGB
nSPHslfgaCOqv4/XMvYAUA+22b7+d6VxRIYFojetdmmCi5u5fIFGv+6ErLIpPTVs
wNZOli0npmLeuAnYME+6wKw0ozsYtKQNudIATHy6t6IwWBew+SCoWnCdlJZQFx0i
YZwv8kJXzqTGU50vxad1FsDYQL1AaBEJBwqAGS9vV5OsyvAqpXuUacZWzrLgT4hM
+HupcnoWErFMZzbNZeTMMFHuP6yTwV0mh3jP99vLtLYyjYmq6qoy+aDCQUTvtH+Y
4wEq4h7VRY9U0HI5hq0B/5LyJw4KKpimYzNmSyiDi9/FSyRa9tPe1idYjHEQsCuU
sTybVvwCocIKF23XV4vPHNYydcdMvG8aHHQSeZ9ywLEkmxTeL0s9SL1+qaOOcqPC
c2HOcC6+FigpPFwrGvgC
=Hvzi
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This project have great potential! The USB proxy hardware can be used
for somehow more secure USB keyboard usage on Qubes OS, when only a
single USB controller is available.
Take a look at this idea[1]:

Have a piece of hardware plugged between USB keyboard and PC (based on
https://github.com/robertfisk/USG?), to encrypt and integrity-protect
the events. And then decrypt them in dom0 and check integrity
protection, and only then pass them down to input devices stack. This
should at least partially guard against malicious USB VM. It still will
be able to perform timing based attacks to guess what you're typing -
not sure how accurate such attacks are currently. Such device could
introduce artificial delay (like - inject queued events every 50ms) to
at least partially mitigate such attacks.

What do you think about it? I think the hardware you've designed is
perfect for this!

[1]
https://github.com/QubesOS/qubes-issues/issues/2507#issuecomment-265894809

- --
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?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYSwUuAAoJENuP0xzK19csXIYH/1Xw4r49ofa9P6RA3TJDqgv3
vN7+Qxzu6zXCIYt/TdWoaKtqvqsiHvhEHrFrTLE9+ysGcuiUtEzJtOBohw4WHFHd
1E1hOL14MTPUXEtu7Jrf2B5XYXQhnNTJgh58xG+nWqIpzi7/RkHz6lq9W8iRXfX2
qWfefAAH6PRywECaj6VEPh8PcbBtu9B3tn8977q1fKB3ZrltnFUjro0p9qLVQr6z
eXE6mBWKKmvTyVGCe1xe3yp7p9LGzoUgsecZEtERZHtxViOlk9faTAHwU4vOho0N
QlinJSUUdE8XWEVSGrNb+KB4Kbwikh7GoABWlSmYiJrOTxVMnOv7DE/mL5WEvtA=
=6Cbj
-----END PGP SIGNATURE-----

[Robert Fisk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

This sounds like a great idea, and I am keen to be involved. There is
plenty of flash space available on the embedded CPUs to implement some
form of encryption, although the best method of doing so on bare-metal
ARM is certainly open for discussion.

A recent batch of hardware samples sold out in November. Due to Real
Life(TM) the next batch of hardware is likely to be ready late January
or early February. Pricing is currently NZ$80 each (approx US$57).

Regards,
Robert

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJYTINVAAoJEN65WsAVra66UqgP/js8V9oHjYtsVs8wHhBs0Iq+
NL4pWUUtceGlCPBJZnKhmPM2Q7gNve3CS4K1i3JikSGIMw4BTqH59JqRmHIv1UDW
jH3DHfbGRLNXAJQTAUFQVV+M43rMQXcM0BT5xrTUdlwG8dQhe44cS+cW1BzmSBtn
FsszZVEp7UU6IJ/YZMYfEIbd/dhq92YBU5fU16F6PVdAFq8ObQoLCMPxWN8GLSKy
JgYkcRHiC2mjzYWN5hv+iZYFVWfxR33jkUoo7n2Iyaz27bYjHyKCy83sBsnhUaLg
Xr2+HJxGoxtScG9Q42ay1/40W5LQyhLRyvnYg1Yih1p18JrY54oe4k2F5jGnj953
giQri7lg6xWk9Md9rDRKvq7Xc2Kd6VdRAp1ooPfehGSIidGRdyYEAVttaqMxmZB3
7U1j35ELDTN3q79++LxnQr01yERsQHM6cKYQsog5/mOHtSG2+iOK2RoNK5M2fhQB
wrULmBTmwNruRGO+W2RBCcOZCvmP8WTthEb85BSVwHlrra6Vv02oFyAvDTj4Q8RI
NLV9HqwXILW1eICCoQUOzcW41SAYrn3ykX/eWgksg221Lks9RWzfxDItBXtrjXSR
pqKtbqRVZIT0k35GJug8RjTuG2JRaMbSEepblmWCvm9cN4bl/RRkOy9uRgfBLKsx
+k6vRfW54/ly/WT/XVJh
=1NhG
-----END PGP SIGNATURE-----

[Tai...@gmx.com]

For the record there is also http://syncstop.com/

It isn't "smart" like this but it is more secure if you just want
charging - in case you need to charge an unsafe (friends, colleagues)
device on your laptop, or charge your device with someone elses charger
or a public charger.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Tracking this as a community-developed feature:

https://github.com/QubesOS/qubes-issues/issues/2518
https://www.qubes-os.org/qubes-issues/#usg-keyboard-hardware-proxy

Please keep us posted as to your progress, and let us know how we can
help. :)

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYT6Z0AAoJENtN07w5UDAwXNsP/j0KrGEyjCHq0h3v7/nmlTwx
YGn05f+Bh7L7r9HSGOeH9PMgKkFr85btXdXPhG5+swCSdFgmhbkcad0lgy8hX2mz
uZND7Z/wnEI99kK7D2EN3Kl9vM4fHM4/I8jV6ulwXPrMfr8xNvdDiQn9JLfcUTwU
SvL4VzP92JKZTss2ILfjK8TsH7cIoFek72+Bn9dQKyppDmrlxi9xu0Y67m0B8NkW
L94YLLIQGO4Qq2vuuVlTIJmw6DGN8AXbwMwOixBtirM1AzeAZGt9GB3ZtTU438EE
xFXc9Ould67L2sqluuj7rkLoAE6QnkhzeyCbsgfS6OcE2rCXCNdQkmjx8zXzLrgL
DZg+D/PPCwSSyV2tzeGfsxTX4bY1w7dc8ecPHcgeuAV7L7UjL7hSrNJj3Y49jEtR
XBmleAq9XCaStYl29MkpYNLddCI3grLMwRFnW9adg85PU2Zay7q64Ay8OSjZDa72
wuO57t6UchbHRURth5P8Sa2SmjzenohPPWeWOqETa6O1ZMj+4+P+X2F+cS1pawio
EAggf4y/brbQkAAyC5eYpO7RxmzvbWN2Ciu0csYD8GEHBvvcJC2N/bENRBUujI8i
J9AjU2E1hoYwRbghwk7iNRFzCcPr1WJW3sbhibKjaTrIwKVsib/3XkgeXM5e6bU1
yGJ9eVDpcb/ekzvzM5qm
=kZIF
-----END PGP SIGNATURE-----

[thinkpad user]

On Wednesday, August 31, 2016 at 8:25:33 PM UTC+4, pixel fairy wrote:
> poured some epoxy over where the ram connects to the motherboard

modern RAM keeps data after hours after disconnecting in from MB. (wont search that paper now, plz search on your own). there are also physical traces of RAM state on RAM device. thats why some folks are moving keys in RAM(xoring it actually) every 10 seconds or so, in their opensource encryption software. there is papper on in too, with photo of such physical micro traces. paper also explains why RAM manufacturers are trying to keep volts as low as possible.

imo encrypted RAM is more safe. but where to store keys? CPU cache, VRAM? or separate PCI device? unsure about speed of PCI vs RAM though. but safe storing keys in HW of major, massive vendors is a wrong idea because of obligatory unofficial backdooring. maybe it is possible to only encrypt part of RAM with PCI located key(original PCI storage device). example: main system is in RAM, VM's RAM is encrypted (using driver) and the key is on PCI storage device.