check if binary images for random seeds

phabricator-migrator · February 19, 2024, 5:48pm

Information

ID: 379
PHID: PHID-TASK-jo5ekgm52lozyqlxco3g
Author: Patrick
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

More info:

github.com/grml/grml-debootstrap

random-seed - security issue?

opened 03:55PM - 10 Jul 15 UTC

adrelanos

help wanted verify

random-seeds have probably not been though through yet? Files such as... - /var…/lib/random-seed - /var/lib/urandom/random-seed - /var/lib/systemd/random-seed - others? Those should not be included in images for security reasons. Especially not if images are going to be redistributed. Quote @intrigeri: > The urandom initscript makes it clear that the assumption for this file is that its content is "unique to this machine and not known to attackers"... which is not the case when we ship that file in our ISO images. Questions: 1) Are any of such random seeds in images [or iso's] generated by grml-debootstrap? 2) What to do about those? Resources: - https://labs.riseup.net/code/issues/7642 - https://labs.riseup.net/code/issues/7675

github.com/QubesOS/qubes-issues

Prevent shared random seed across VMs

opened 07:13PM - 09 Oct 15 UTC

closed 10:42PM - 12 Oct 15 UTC

marmarek

T: bug C: core C: templates P: major cryptography

Reported by @v6ak: I've examined what is shared between AppVMs that use the sam…e template with focus on security and discussed that with the Qubes team. I've found that /var/lib/systemd/random-seed is stored on /, which means: 1. Subsequent starts of a non-standalone VM use the same random-seed unless the underlying TemplateVM shutdown is performed between those two AppVM boots. 2. Two different AppVMs with the same TemplateVM may be seeded with the same initial random seed 3. This also applies between AppVM and TemplateVM. Such attacks are more attractive (as compromising entire TemplateVM is attractive), but they should be much less likely, as users are supposed to do limited set of tasks with a very limited network access. 4. When cloning a TemplateVM (either to another TemplateVM or to a StandaloneVM), the new VM gets initially the same random seed. It should, however, diverge after some time, so this issue is less serious. 5. Marek has confirmed that initial random seeds are predistributed with the ITL templates. However, it is not as bad as it might look: 1. If haveged is used (i.e. on all ITL templates except fedora-minimal), it generates new entropy very quickly. Users of fedora-minimal should, however, be careful and consider installing haveged. 2. Quoting Marek: “the template is automatically started during its installation, so the new random seed will be saved. Not sure how predictable that new value is...” 3. According to Marek, systemd-random-seed only pushes the seed to the entropy pool, but does not increase the entropy_avail. As a result, this issue affects only /dev/urandom, while /dev/random seems to be unaffected. Even better, this means that haveged reaches low water mark immediatelly and starts gathering new entropy (if haveged is present), which minimizes the issue. ### Impact: 1. Long-term keys: They are usually recommended to be generated from /dev/random, so they should be usually unaffected. The cryptsetup uses /dev/urandom by default, but cryptsetup is typically not used in AppVMs. 2. Short-term keys can be affected in some cases, mostly on fedora-minimal, when you don't haveged installed. 3. Cryptographic nonces can be affected. If user is unlucky enough, he might get “ntwices” instead of nonces. Security implication of “ntwices” can vary, but it can be, for example, critical for ECDSA keys and thus for Bitcoin wallets. (Note that there were AFAIK some successful attacks on Bitcoin wallets where was a transaction signed by an Android client with flawed RNG, so such attacks might be practical.) Again, mostly users of fedora-minimal without haveged installed should be worried about this. Note that users of non-systemd OSes (Debian 7?) _may_ be affected more, because the random seed scripts may behave differently. If entropy_avail is increased by the random seed script, such issue would also affect /dev/random. Moreover, haveged would probably not reach low water mark so quickly, so the impact would be greater in such case. However, not using systemd does not imply this behavior. Not using systemd just means I don't know how it behaves. ### How to fix? Moving random seed to /rw does not fully solve this issue at the moment. The /rw is cloned from the TemplateVM, which is somehow suboptimal. We've also discussed distributing some entropy from dom0 to AppVMs. Some related discussion: https://github.com/QubesOS/qubes-issues/issues/673 . While it solves these issues, it makes dom0 potentially more vulnerable to its RNG flaws. I remember a keyboard timing side-channel vulnerability on /dev/random. Maybe dom0 should only provide an one-time random seed in order to lower impact of such vulnerabilities. If an AppVM asks for new random seed second time within one boot, the user should be at least notified. ### How to prevent similar issues? This and similar issues could have been found by: 1. deterministic builds of templates (random seed would cause) can uncover issues like pre-distributed random seed 2. no mutation after reboot (except some whitelist like logs) can uncover issues like random seed shared between AppVMs Note that 1) does not uncover issues with packages that are not preinstalled. But such testing can be used on any package. It can uncover issues like shared SSH keys (I remember such issue at one VPS provider that provides VPS templates…) and so on. ### Public discussion We have decided to start a public discussion in order to find the best solution. The discussion: https://groups.google.com/d/msgid/qubes-devel/8f3553f3-cf7e-41ce-959f-d81a6285a0f5%40googlegroups.com

TODO check:

Whonix VBox / libvirt images
Qubes Debian templates
Qubes-Whonix images
Should any exist, think about what to do with those. As random-seed - security issue? · Issue #91 · grml/grml-debootstrap · GitHub explains, it may not be as simple as deleting those.

Comments

Patrick

2015-10-15 16:18:03 UTC

Patrick

2015-10-16 16:53:48 UTC