A better screen locker option for those interested

[fowlslegs zyzzyx]

If you have experienced problems with graphical screen lockers where either (a) the screen locker flashes the contents of your desktop briefly after resume from suspend or (b) the screenlocker fails altogether, I have found something more reliable. Namely, one may disable their current screen locker and use physlock in combination with xautolock and two systemd services. Further, since physlock drops you to a virtual console and then locks from there, this provides a more secure method of locking one's screen, as screen lockers on X11 cannot be secure (I don't understand the author's worry about a fake screen locker prompt--you're owned anyway at that point, but there are other important points. Software need not be malicious to prevent your screen locker from starting. Also, besides this blog post there has been a history of exploiting X11 screen lockers, e.g., one was not too long ago shown using a special key combo). If you want, you can read my relevant bug report and some additional info. regarding the problem with the default Qubes screen lockers. Without further ado, I'll provide a walk-through on how to set this up for yourself.

First, open up a terminal in a networked DispVM. We'll be moving code (after cryptographically verifying it's integrity) into dom0, so we want to ensure we are working in an uncompromised domU.

$ echo gnome-terminal | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red

We clone the repository we want with

$ git clone https://github.com/muennich/physlock

Next, we will check the git tags. It is possible to sign git tags, however, if you run `git log --show-signatures` you will see that our author has only signed their tagged releases. When in the physlock directory we may call git tag to get a list of the release versions.

$ cd physlock

$ git tag

At the time of writing, the latest tagged version is v0.4.5. In order to verify it, we must first download the developer's signing key. It has RSA key ID 2F2C3DB4.

$ gpg --recv-key 2F2C3DB4

$ git tag -v v0.4.5

If the signature is good, we can either (a) checkout this branch or (b) manually review the commits (3 tiny ones at time of writing) since v0.4.5 and decide whether to trust them.

(a) $ git checkout v0.4.5

(b) $ git diff v0.4.5

We're going to use tar to make this into an archive, for ease of copy to dom0, but while we're at it we can save some time by adding in the systemd files we would like to use. I've uploaded them to Github for your convenience. No signature, so read over the unit files yourself. An explanation of these units can be found in my bug report (linked above).

$ git clone https://github.com/fowlslegs/qubes-misc

$ cd ..

$ tar -cf physlock.tar.gz physlock

Now move the tar.gz archive into dom0. I placed it in my ~/bin folder in dom0. At this point you may close the DispVM terminal and we proceed from the dom0 terminal. First, let's install tar, gcc, make, and xautolock. I think this is everything you need to extract the archive, compile the source, and get everything running.

$ sudo qubes-dom0-update gcc make xautolock

Now extract the archive and get qubes-misc out of there.

$ tar -xf physlock.tar.gz

$ mv physlock/qubes-misc .

We can now make and install physlock

$ cd physlock

$ make

$ sudo make install

Now that physlock is installed we copy our systemd unit files to where they need to be

$ cd ../qubes-misc

$ sudo cp physlock.service /etc/systemd/system/sleep.target.wants/

$ sudo cp xautolock.service /etc/systemd/system/graphical.target.wants/

We can now enable our systemd services and then start them immediately.

$ sudo systemctl enable physlock.service

$ sudo systemctl enable xautolock.service

$ sudo systemctl start physlock.service

$ sudo systemctl start xautolock.service

You can now disable your other screenlocker. You may lastly wish to map the command `/usr/bin/xautolock -locknow` to a key combination. I chose Ctrl-Alt-L to override the default for activating KDE's screenlocker.

[Vít Šesták]

$ gpg --recv-key 2F2C3DB4

One should never use 32b key ids, as it is easy to find colisions with them.

Note that I don't see so much improvement for Qubes compared to the standard lockscreen, because AppVMs in Qubes have very limited capabilities to interact with the dom0's X11.

Regards,
Vít Šesták 'v6ak'

[fowlslegs zyzzyx]

On Tuesday, June 2, 2015 at 5:03:18 AM UTC-7, Vít Šesták wrote:


>$ gpg --recv-key 2F2C3DB4
>One should never use 32b key ids, as it is easy to find colisions with them.

Good point. One should use

$ gpg --recv-key 0x230107be2f2c3db4

instead.

>Note that I don't see so much improvement for Qubes compared to the standard lockscreen, because AppVMs in Qubes have very limited capabilities to interact with the dom0's X11.

In this sense I agree. I actually hinted at it in my comments on that KDE dev's blog post. The improvements come from

(a) reliability: the KDE and XFCE screenlockers are buggy, and

(b) physical security: there are many examples of screen lockers being crashed through special key combinations, use of another tty to rapidly retry to login or just switching back and forth, etc.. If you do some web searches for bugs and exploits, you'll see that X11 screen lockers have a bad security history that is not due to malicious applications.

[Vít Šesták]

OK. Note that if you care about physical security, it will never be perfect, as someone might perform cold-boot attack. The physlock seems to be a minor improvement for me, but it depends on what threats you fear from.

Regards,
Vít Šesták 'v6ak'

[fowlslegs zyzzyx]

>OK. Note that if you care about physical security, it will never be perfect, as someone might perform cold-boot attack. The physlock seems to be a minor improvement for me, but it depends on what threats you fear from.

This was mentioned in the discussion on the Github issues page linked in the original post. For many people this is not in their threat model, or they would only worry about this in certain situations, such as at airports, hotels, borders, etc.. I think most of Qubes users are aware of cold-boot attacks and know this wouldn't protect them.

Besides, Bitlocker for Windows and TRESOR for Linux (which seems difficult to implement considering I have only seen one kernel build using it that is now no longer maintained--you can still find it in the Arch AUR--not to mention the problems with it) are the only software options I know of if you're worried about cold boot attacks. Neither are an option for Qubes atm. The RAM on my laptop is soldered to the motherboard, which provides an additional obstacle, but I'm sure it's still surmountable for an advanced and determined adversary. Considering there are things like FROST, I imagine someone has a way of getting keys off soldered laptop RAM (although it seems unlikely it is hardware and firmware agnostic--I suppose I'm less sure it's possible to get keys from all computers with soldered RAM).

I think I've already made my point of why one might like to use physlock. If you think the benefits are minimal or your X11 screenlocker is not buggy and never flashes your desktop on resume from suspend (or it does and you don't care), then it's probably not worth the 5-10 minute setup described above.

[Jake]

On 06/04/15 04:55, fowlslegs zyzzyx wrote:

>OK. Note that if you care about physical security, it will never be perfect, as someone might perform cold-boot attack. The physlock seems to be a minor improvement for me, but it depends on what threats you fear from.

This was mentioned in the discussion on the Github issues page linked in the original post. For many people this is not in their threat model, or they would only worry about this in certain situations, such as at airports, hotels, borders, etc.. I think most of Qubes users are aware of cold-boot attacks and know this wouldn't protect them.

Besides, Bitlocker for Windows and TRESOR for Linux (which seems difficult to implement considering I have only seen one kernel build using it that is now no longer maintained--you can still find it in the Arch AUR--not to mention the problems with it) are the only software options I know of if you're worried about cold boot attacks. Neither are an option for Qubes atm. The RAM on my laptop is soldered to the motherboard, which provides an additional obstacle, but I'm sure it's still surmountable for an advanced and determined adversary. Considering there are things like FROST, I imagine someone has a way of getting keys off soldered laptop RAM (although it seems unlikely it is hardware and firmware agnostic--I suppose I'm less sure it's possible to get keys from all computers with soldered RAM).

i experimented with doing a cold boot attack on DDR3 RAM a couple years ago and couldn't find any hardware (that i had laying around) that would allow the cold booted RAM to read out.

iirc DDR3 and DDR4 have a tuning and load-leveling done on boot by most hardware, which will make it difficult to get a good dump. i'm not sure you could get a coherent dump of the memory by simply disabling the tuning of the RAM on boot.

on the plus side, a cold boot attack falls into the "you know they know" bucket.

I think I've already made my point of why one might like to use physlock. If you think the benefits are minimal or your X11 screenlocker is not buggy and never flashes your desktop on resume from suspend (or it does and you don't care), then it's probably not worth the 5-10 minute setup described above.

--
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/2693d398-ce42-4551-a5b6-710502cf50b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vít Šesták]

This was mentioned in the discussion on the Github issues page linked in the original post. For many people this is not in their threat model, or they would only worry about this in certain situations, such as at airports, hotels, borders, etc..

Sure. I divide such threats to:
a) casual attacks (including some bad jokes) – KDE lockscreen is often enough, unfamiliar GUI is also often a blocker
b) targeted attacks by a knowledgeable attacker – I assume he can perform cold boot attack. Note that my laptop has the RAM easily accessible and definitely not soldered. (I know that as I have upgraded the RAM.)

I think most of Qubes users are aware of cold-boot attacks and know this wouldn't protect them.

I hope so, but I find it reasonable to repeat it.
 

 

Besides, Bitlocker for Windows and TRESOR for Linux (which seems difficult to implement considering I have only seen one kernel build using it that is now no longer maintained--you can still find it in the Arch AUR--not to mention the problems with it) are the only software options I know of if you're worried about cold boot attacks. Neither are an option for Qubes atm.

 
Note that this would mitigate such attacks only partially. It would make access to the keys infeasible, but not other RAM contents. Some RAM encryption would solve it, but it is hard to design and implement. (Maybe one could do that via kernel chainloading?)

The RAM on my laptop is soldered to the motherboard, which provides an additional obstacle, but I'm sure it's still surmountable for an advanced and determined adversary. Considering there are things like FROST, I imagine someone has a way of getting keys off soldered laptop RAM (although it seems unlikely it is hardware and firmware agnostic--I suppose I'm less sure it's possible to get keys from all computers with soldered RAM).

A RAM soldered on the MoBo is a serious obstacle, considering the fact that unsoldering requires high temperature on the pins (it is usually done at temperatures over 200°C), while coldboot requires low temperature. My small experience with soldering suggests that it would be infeasible to unsolder the RAM while keeping the chip cold, as wires are good at propagating heat. One might, however, try even some destructive approach, e.g., to destroy the MoBo in order to get RAM alone.

However, coldboot can be done on the same machine in some cases, which is AFAIK the case of FROST. It requires booting some custom code (a password protected BIOS or locked bootloader might mitigate it) and, if I remember it correctly, unlocked bootloader was a prerequisite for FROST.

I'll sum some hardware-related notes what I've learned about cold boot attack from various sources:
* Can be done just by reboot to a custom OS if such option is available unless the BIOS rewrites the content of RAM. This should be feasible even with DDR3.
* With DDR2, you can even leave the RAM module for about five minutes even without any power and without cooling.
* With DDR3, it loses its content even after several seconds of power loss in a way that it is infeasible to extract the keys.
* Even with DDR3, an attack would be probably feasible with cooling or reboot. (Not 100% sure this is feasible, but it sounds plausible for me.)
* ECC probably makes the data recovery easier when attacker has some access to the RAM contents, but it also mitigates the same-machine attack scenario, because BIOS has to overwrite whole RAM contents in order to prevent spurious read errors caused by random content in an ECC RAM.

Regards,
Vít Šesták 'v6ak'

[Noah Vesely]

Just a heads up I moved this repo to https://github.com/fowlslegs/qubes-physlock-systemd-scripts. qubes-misc didn't make sense as a name.