Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

2016-09-02 Thread johnyjukya
> 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+unsubscr...@googlegroups.com.
> To post to this group, send 

Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

2016-09-01 Thread johnyjukya
>> 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!

N!!!  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 

Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

2016-09-01 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Sep 01, 2016 at 06:55:05AM -, johnyju...@sigaint.org wrote:
> > On Wed, Aug 31, 2016 at 10:05:59PM -, johnyju...@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 

Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

2016-09-01 Thread johnyjukya
> 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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c2872d8b7c663d10b867f7b43b735ad3.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

2016-09-01 Thread johnyjukya
> On Wed, Aug 31, 2016 at 10:05:59PM -, johnyju...@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 

Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

2016-08-31 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Aug 31, 2016 at 10:05:59PM -, johnyju...@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-

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20160901022532.GE24732%40mail-itl.
For more options, visit https://groups.google.com/d/optout.