Shared data between AppVMs: random seed
217 views
Skip to first unread message
Vít Šesták
Jul 1, 2015, 1:05:10 PM7/1/15
to qubes...@googlegroups.com
Hello,
I've examined what is shared between AppVMs that use the same 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
2.1. 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.
3. 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.
4. 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.
Regards,
Vít Šesták 'v6ak'
I've examined what is shared between AppVMs that use the same 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
2.1. 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.
3. 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.
4. 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.
Regards,
Vít Šesták 'v6ak'
HW42
Jul 1, 2015, 3:15:40 PM7/1/15
to Vít Šesták, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Vít Šesták:
> Note that users of non-systemd OSes (Debian 7?) *may* be affected
not newly initialized). So if the boot process (or anything before the
key/nonce generation) generated enough randomness you should also be saf
e.
> 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.
I have started to implement something similar a few months ago but
never finished it. I have cleaned it up quickly - see attached patches.
When dom0 starts a new VM it reads a 64 bytes from /dev/urandom. Those
byte are hashed with sha512 to prevent potential leakage of the rng
state (it _should_ be safe without).
A small script + systemd-service feeds this seed into /dev/urandom
when a VM get started.
I have tested this only for AppVMs and DispVMs.
> 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.
Does someone evaluated the usage of haveged in a virtualized
environment? I'm a bit skeptical since there are successful cache
attacks for x86 virtualisation and haveged relies (partially) on cache
timing.
> Public discussion
>
> We have decided to start a public discussion in order to find the
> best solution.
>
> Regards, Vít Šesták 'v6ak'
>
HW42
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVlDw0AAoJEOSsySeKZGgWP74P/jJZljGQdDA52ftVwjHhPrZ9
jGMbnB2gAZXy/+kiHpsbq8BMdaAt2++J+6ZI9pGmICrrsnkdoAMI9txJsI9WxavW
n/sTQLpZKkaSSoSkXZXIR8MsgOvhrE9eWLvB3dATxou8KOC5Yy+dPgCVW5Slar0l
xDF7S9EY1svEpFqv26uKfhCln/IBhtWtyuG5IEOTsGMBpWQABZYOPyvz1EINFVNp
jUAEP2Wggw7rOdsGEdrA0XbxYW3oOf6pi5O7yNsqxCGyTU0V3e0/RgsHPxrz8bbg
BUu9zvqywcmg6dfGNwTPsiJbAQxq2gA4/ybkkI8tq2EdT/uWO0wmKg2IwIZb/B+t
fjHguLZF3PIN1b+hUOYuoZCTmA5a96P1aLP8jmWo5LHw3oPgL+8URT0KCi3ua3I0
64CPs9ksgt6/jNLirGJ1Fb2Twi7v5Up2lU/PMWQ8jvdwfrEZWRQYYaCdhJMjNwIC
HGzyLrrafAQXWd2Yp3HJl2xo3F9W9I8N2bdXpoFnuxjfyfJWa5BID0SYJqnV6HcZ
0FmZLf7NJrld5CV5gtO9NNFz0/h5ahYQxaQ6T7+SRY2T80xcemuLjHZ1YCAHqI8u
DfchzyTvpHkDzAF4OPSxcAi2HmcXeBmdfGYrKX2hSpX8alPI/cdP6b2HOvVfFre9
Qb05mG/nYx5mHriu4l5T
=OEeK
-----END PGP SIGNATURE-----
Hash: SHA512
Vít Šesták:
> 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.
As far as I know the seed is only added to the randomness pool (i.e.
> 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.
not newly initialized). So if the boot process (or anything before the
key/nonce generation) generated enough randomness you should also be saf
e.
> 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.
never finished it. I have cleaned it up quickly - see attached patches.
When dom0 starts a new VM it reads a 64 bytes from /dev/urandom. Those
byte are hashed with sha512 to prevent potential leakage of the rng
state (it _should_ be safe without).
A small script + systemd-service feeds this seed into /dev/urandom
when a VM get started.
I have tested this only for AppVMs and DispVMs.
> 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.
environment? I'm a bit skeptical since there are successful cache
attacks for x86 virtualisation and haveged relies (partially) on cache
timing.
> Public discussion
>
> We have decided to start a public discussion in order to find the
> best solution.
>
> Regards, Vít Šesták 'v6ak'
>
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVlDw0AAoJEOSsySeKZGgWP74P/jJZljGQdDA52ftVwjHhPrZ9
jGMbnB2gAZXy/+kiHpsbq8BMdaAt2++J+6ZI9pGmICrrsnkdoAMI9txJsI9WxavW
n/sTQLpZKkaSSoSkXZXIR8MsgOvhrE9eWLvB3dATxou8KOC5Yy+dPgCVW5Slar0l
xDF7S9EY1svEpFqv26uKfhCln/IBhtWtyuG5IEOTsGMBpWQABZYOPyvz1EINFVNp
jUAEP2Wggw7rOdsGEdrA0XbxYW3oOf6pi5O7yNsqxCGyTU0V3e0/RgsHPxrz8bbg
BUu9zvqywcmg6dfGNwTPsiJbAQxq2gA4/ybkkI8tq2EdT/uWO0wmKg2IwIZb/B+t
fjHguLZF3PIN1b+hUOYuoZCTmA5a96P1aLP8jmWo5LHw3oPgL+8URT0KCi3ua3I0
64CPs9ksgt6/jNLirGJ1Fb2Twi7v5Up2lU/PMWQ8jvdwfrEZWRQYYaCdhJMjNwIC
HGzyLrrafAQXWd2Yp3HJl2xo3F9W9I8N2bdXpoFnuxjfyfJWa5BID0SYJqnV6HcZ
0FmZLf7NJrld5CV5gtO9NNFz0/h5ahYQxaQ6T7+SRY2T80xcemuLjHZ1YCAHqI8u
DfchzyTvpHkDzAF4OPSxcAi2HmcXeBmdfGYrKX2hSpX8alPI/cdP6b2HOvVfFre9
Qb05mG/nYx5mHriu4l5T
=OEeK
-----END PGP SIGNATURE-----
Vít Šesták
Jul 1, 2015, 4:01:40 PM7/1/15
to qubes...@googlegroups.com, groups-no-private-mail--con...@v6ak.com, hw...@ipsumj.de
As far as I know the seed is only added to the randomness pool (i.e.
not newly initialized). So if the boot process (or anything before the
key/nonce generation) generated enough randomness you should also be saf
e.
That's true, I also hope that the internal RNG state is never discarded, but it is not so important, as RNG state when booting has usually poor entropy. The main point is if restoring the seed affects entropy_avail. With sytemd, Marek has found it does not. This situation together with haveged seems to practically mitigate any attack abusing the mentioned weakness. With other scripts, I don't know at the moment how they behave.
I have started to implement something similar a few months ago but
never finished it. I have cleaned it up quickly - see attached patches.
When dom0 starts a new VM it reads a 64 bytes from /dev/urandom. Those
byte are hashed with sha512 to prevent potential leakage of the rng
state (it _should_ be safe without).
A small script + systemd-service feeds this seed into /dev/urandom
when a VM get started.
I have tested this only for AppVMs and DispVMs.
Cool.
Does someone evaluated the usage of haveged in a virtualized
environment? I'm a bit skeptical since there are successful cache
attacks for x86 virtualisation and haveged relies (partially) on cache
timing.
To be honest, I don't know. Qubes team told me they have checked that RDTSC is configured to work securely on Qubes (see https://github.com/QubesOS/qubes-issues/issues/673#issuecomment-109805914 ), but I am not expert on RNGs, timing attacks or caches. While I know something about all of those three things and I understand something bad might happen, I don't feel to be so good to review this.
However, I'd like to ask what kind of timing attack was it? I guess: If there was a way to abuse timing to get some information about internal RNG state (e.g. to get some information about data that the RNG is seeded by), it would be abusable by a local non-root user even in non-virtualized environment. Well, there might be such attack, but I hope haveged to be reviewed against such attacks, as those might be much more practically useful. (Consider JS-based attacks from a webbrowser.) If there is some virtualization-specific attack (that can't be abused by a local non-root user in non-virtualized environment) on cache timing, I am curious about that.
Regards,
Vít Šesták 'v6ak'
Patrick Schleizer
Jul 10, 2015, 1:17:38 PM7/10/15
to qubes...@googlegroups.com
>
qubes-core-admin_0001-qubes-random-seed-feed-kernel-rng-with-randomness-fr.patch
f = open('/dev/urandom', 'r')
Why read from /dev/urandom? Not from /dev/random? Can you please explain
the rationale behind this?
Cheers,
Patrick
qubes-core-admin_0001-qubes-random-seed-feed-kernel-rng-with-randomness-fr.patch
f = open('/dev/urandom', 'r')
Why read from /dev/urandom? Not from /dev/random? Can you please explain
the rationale behind this?
Cheers,
Patrick
Patrick Schleizer
Jul 10, 2015, 1:18:25 PM7/10/15
to HW42, Vít Šesták, qubes...@googlegroups.com, nrgaway
Do these patches also cover the Whonix templates?
Cheers,
Patrick
Cheers,
Patrick
Patrick Schleizer
Jul 10, 2015, 1:52:58 PM7/10/15
to qubes...@googlegroups.com
Where can I find,
- qubes-random-seed.service and
- qubes-random-seed.sh
?
Haven't found by grepping the source and Google doesn't know either.
Cheers,
Patrick
- qubes-random-seed.service and
- qubes-random-seed.sh
?
Haven't found by grepping the source and Google doesn't know either.
Cheers,
Patrick
HW42
Jul 10, 2015, 1:57:30 PM7/10/15
to Patrick Schleizer, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Patrick Schleizer:
Hash: SHA512
http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVoAdUAAoJEOSsySeKZGgW+twP/RTasaR9wiqGtb7AaUaMsc5F
HdFGvAEM/bgIOkwrJSDKbBxdW7vD6XU8eat1bO1S2A44Bl7pkq0EScdY8ExyFA+Z
O1uN7zFrBhxXPK7sxLZGooX5qaEu7vCmPj27HQXNWUqLtkRENCTJ8pbxCb6cM7sd
/3mp9AX6YGX0OSE28cvXgyGWimV9CoekC//c4UxGNUsOxMuM84tMPc+kEjPPyWX3
JbPuGV+rHZg3GdjM7wyyyhD6AlDJ6jYzKnXgIq4A1J7M86n302TqRUGhxiv0xx42
DZlYxrVBckPkzHsDNpB5XKSGIKL37BRVyjMDV6c8M8e24N/zFoFKUJ2vweRPFSAN
Zmh1JLsgrh7A4vqFPbOQQP5wD+Kq2d716OP8OAb4P1UWaufGZmJwO1DU8nfFPfmP
wztS/J1K5gFr/XGk9Y4YqH9plJVHRKv1jFLckTXBqQRglqlOuw75hxxaFviiGho3
rk9PCKLJrBjYepTUt6DYksPPsRTcBcdUd3unnwB4CEadh+43DvlJrMCne/wBt1Mn
sJKL8Es/2ckmiyGcsZsE1bKQpK7Z9DWsjzEUPZ3h6nUUTgrKOcvV9GBOFbINo0UV
w8D0Djkf2V5Aehlhn9KXM2c0PcTravz5wLydTbv8ISj6iMpuLP+QzFI5lTcPWyrT
hfVbSm6ucxl87Bz93S+/
=aNmj
-----END PGP SIGNATURE-----
HW42
Jul 10, 2015, 1:59:56 PM7/10/15
to Patrick Schleizer, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Patrick Schleizer:
Hash: SHA512
> Where can I find, - qubes-random-seed.service and -
> qubes-random-seed.sh ?
>
> Haven't found by grepping the source and Google doesn't know
> either.
They are created by my patch.
> qubes-random-seed.sh ?
>
> Haven't found by grepping the source and Google doesn't know
> either.
> Cheers, Patrick
>
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVoAfuAAoJEOSsySeKZGgWrk0QAK8yjgLxP3wp3Dxt58l+0B4v
qYEWTXc5Dg+JWFaYgXMmgz56Aw6TmKIlMGKxE9pP4SSbGhNGJ7dGuqK7mHq2ONCg
HIvIM48pxPjE77rJS37POzcPwuJL1BRcHI7mWhD+odvd9kHSTDjTND6w5WH8J8U/
FmoZ7WCAVM6L4VN/N6qM3ZskiDdEe0UjJ8A7Q6CaqCahlexYxjWI4FXZP33HF9ut
ZHyP+AdD0zMtKdc+7sSiusT+QGgO+K4oqA/JIuVr1h9RhWpl3YM6H8bA0yWZWRo9
gP0hZ2ESq8s1UMdR+z14gc70jg5Vc5uAp3Dn3oh3Md8quPZ5VdNf/SqaPm13SJNp
tQ/HSw8w8wfHBN8tdCNZK0m3yUOBuR/l/26fVd3nFyLE66W2RQ1R/3sz9wOAbWLB
bbunNAT1LO3fVIgYztapEHw8O6LOQ5kLBabg7BJT9EuLgobBhKXcJud8YpYGjJ/X
8HNYGLxBwPwvJt5H5W+1qhT/whlmi6HIO8woOjuZhg/LKwDUdEVey4DiG2bum6qF
LneWGm9VrmWAYLlJV4nQoiD0+RO7KepS9nbS70BKqHpZ9jhMD4q/keu/e1nvabhS
rNph+eMKyaGnrH40gbBItxdd3dpcGrb8TyB50T/FZ0Fe4XqWdwy3Ev6gmYguTjyQ
Y9s5lIz88Z9m2xMbCSCz
=udwD
-----END PGP SIGNATURE-----
Patrick Schleizer
Jul 10, 2015, 2:03:44 PM7/10/15
to HW42, qubes...@googlegroups.com
HW42:
Cheers,
Patrick
> Patrick Schleizer:
>> Where can I find, - qubes-random-seed.service and -
>> qubes-random-seed.sh ?
>
>> Haven't found by grepping the source and Google doesn't know
>> either.
>
> They are created by my patch.
Those have not been merged yet?
>> Where can I find, - qubes-random-seed.service and -
>> qubes-random-seed.sh ?
>
>> Haven't found by grepping the source and Google doesn't know
>> either.
>
> They are created by my patch.
Cheers,
Patrick
HW42
Jul 10, 2015, 2:08:26 PM7/10/15
to Patrick Schleizer, Vít Šesták, qubes...@googlegroups.com, nrgaway
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Patrick Schleizer:
Hash: SHA512
> Do these patches also cover the Whonix templates?
They should work. But I haven't tested it yet.
When you have installed the qubes-core-admin patch (in dom0) you
should be able do read the seed (base64 encoded) in newly booted
VMs with
qubesdb-read /qubes-random-seed
When you then install the qubes-core-agent-linux patch (in the
template) the above command should no longer be able to read the
seed (because it is deleted after being feed into /dev/urandom) and
systemctl status qubes-random-seed
should not show an error.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVoAnoAAoJEOSsySeKZGgWPPUQAKfcA3eSV1ogq+n1ckNoZJVE
RDnGluTDWn/uSEXaF+XZ6jVftDoHq6/Gdu2RwUvqKqxd0d36wVFMxiZUHWLy3j4e
l1QLX1ErfVc4KDIKGuo1rXtbbK1r0h0Z6pA1f3fmsnWfyrcocLe4THznmLRFcWBB
k8Scji2PFZcu2roJNNUVDJTkmOIk5RRZf5MUe/zTXlMtkqAbmoGBm3Qb+xdP5EJl
nRC5sp+6SMy9RVQdavDBNxTbhOPUOuKLNrmiHahYm97t7Y/b2snA1L7WjkCwpiAE
D7I6sa41tJ1mAqEQEwW9yJ2sVnO/KJTGGKoJP5Akke/SgoHLuh6Mqbjh2K1Stp4b
YReAPPI2qBBtidKhYMGXDSV/OzPBNoc3CCeZm67X2xnEL+5sKGJu9MXBdYO7i1TR
f3CasePP92Jz6box4t7qemBF9GjPWyxXduOV5YCZM6w7Opj9Tb49qAlsZrWhMCIF
WWmPIXnrnTI8QFGbsMb2JgjcCTvcf7EHDQh5Nl96c2OxwJBSOxTCd7JRapMiZf9M
cRbU9dZwTq5qpDUabSJh5FbIiTOFTHih71TDabBVIANWwYxZ1K/BihUqyxDTAZWf
UybbRXUlNvAZaQWko1DXZUu+gboCuPIDHFrkrNXdjxGd1RvvGT3Ks4nlyocVBb2c
oHJmtZcEeCQ2A8S0nh3+
=mHM1
-----END PGP SIGNATURE-----
Patrick Schleizer
Jul 10, 2015, 2:59:04 PM7/10/15
to HW42, Vít Šesták, qubes...@googlegroups.com
Are you sure, that simple shell redirection writing, i.e. '>
/dev/urandom' is sufficient and actually effective? [2]
Isn't RNDADDENTROPY [1] required?
I hope, I am wrong. Because then my comment in a related ticket [3]
would be wrong and things would be simpler.
Cheers,
Patrick
[1]
http://manpages.debian.org/cgi-bin/man.cgi?query=random&apropos=0&sektion=4&manpath=Debian+8+jessie&format=html&locale=en
[2]
https://unix.stackexchange.com/questions/141197/why-writing-to-dev-random-does-not-make-parallel-reading-from-dev-random-faste
[3]
https://github.com/QubesOS/qubes-issues/issues/673#issuecomment-108585795
/dev/urandom' is sufficient and actually effective? [2]
Isn't RNDADDENTROPY [1] required?
I hope, I am wrong. Because then my comment in a related ticket [3]
would be wrong and things would be simpler.
Cheers,
Patrick
[1]
http://manpages.debian.org/cgi-bin/man.cgi?query=random&apropos=0&sektion=4&manpath=Debian+8+jessie&format=html&locale=en
[2]
https://unix.stackexchange.com/questions/141197/why-writing-to-dev-random-does-not-make-parallel-reading-from-dev-random-faste
[3]
https://github.com/QubesOS/qubes-issues/issues/673#issuecomment-108585795
Marek Marczykowski-Górecki
Jul 10, 2015, 3:05:34 PM7/10/15
to Patrick Schleizer, HW42, Vít Šesták, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, Jul 10, 2015 at 06:58:53PM +0000, Patrick Schleizer wrote:
> Are you sure, that simple shell redirection writing, i.e. '>
> /dev/urandom' is sufficient and actually effective? [2]
>
> Isn't RNDADDENTROPY [1] required?
>
> I hope, I am wrong. Because then my comment in a related ticket [3]
> would be wrong and things would be simpler.
systemd-random-seed simply writes to /dev/urandom, so when we want to
"fix" random-seed issue it should be enough.
Ticket 673 is about /dev/random, which is a separate issue, but IIUC
there is no problem with sharing initial seed or sth like this. This
should be solved by haveged - as commented in that ticket, it seems to
be effective in Xen environment.
> Cheers,
> Patrick
>
> [1]
> http://manpages.debian.org/cgi-bin/man.cgi?query=random&apropos=0&sektion=4&manpath=Debian+8+jessie&format=html&locale=en
> [2]
> https://unix.stackexchange.com/questions/141197/why-writing-to-dev-random-does-not-make-parallel-reading-from-dev-random-faste
> [3]
> https://github.com/QubesOS/qubes-issues/issues/673#issuecomment-108585795
>
- --
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 v1
iQEcBAEBAgAGBQJVoBd1AAoJENuP0xzK19csB6MH/3xr8qI4Jkw49CU/bbDG35m5
h7W9/Y2lZTOOTCDbcFccH7w5jlGpXl+981imtw2DLOy3OqGt6hel54kgsGRFDoyE
0JFdoItQMTvhgYeqXZR8a1fJrHF9y+yEuPW5c9FmQRdfJHJ9NYZk5pBFEPm6IgTU
KSDgkBgX7eet51/utXiS0l41hzWNniJ7GDQkojpE80eI3i5WVXoBbZyxu5HxG9B7
l2a1byGX07DycmtNPip2DDcCHEq/RggKk50PvzANbpaX4PvP4L6PI3b0Ys2CIGI6
X8bdC+J9zkrt6qL62rFGQ+COTeYQTs/bpXeBt86wiPGm5+EWPuH7ay9YcmV4LMo=
=BZBu
-----END PGP SIGNATURE-----
Hash: SHA1
On Fri, Jul 10, 2015 at 06:58:53PM +0000, Patrick Schleizer wrote:
> Are you sure, that simple shell redirection writing, i.e. '>
> /dev/urandom' is sufficient and actually effective? [2]
>
> Isn't RNDADDENTROPY [1] required?
>
> I hope, I am wrong. Because then my comment in a related ticket [3]
> would be wrong and things would be simpler.
"fix" random-seed issue it should be enough.
Ticket 673 is about /dev/random, which is a separate issue, but IIUC
there is no problem with sharing initial seed or sth like this. This
should be solved by haveged - as commented in that ticket, it seems to
be effective in Xen environment.
> Cheers,
> Patrick
>
> [1]
> http://manpages.debian.org/cgi-bin/man.cgi?query=random&apropos=0&sektion=4&manpath=Debian+8+jessie&format=html&locale=en
> [2]
> https://unix.stackexchange.com/questions/141197/why-writing-to-dev-random-does-not-make-parallel-reading-from-dev-random-faste
> [3]
> https://github.com/QubesOS/qubes-issues/issues/673#issuecomment-108585795
>
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 v1
iQEcBAEBAgAGBQJVoBd1AAoJENuP0xzK19csB6MH/3xr8qI4Jkw49CU/bbDG35m5
h7W9/Y2lZTOOTCDbcFccH7w5jlGpXl+981imtw2DLOy3OqGt6hel54kgsGRFDoyE
0JFdoItQMTvhgYeqXZR8a1fJrHF9y+yEuPW5c9FmQRdfJHJ9NYZk5pBFEPm6IgTU
KSDgkBgX7eet51/utXiS0l41hzWNniJ7GDQkojpE80eI3i5WVXoBbZyxu5HxG9B7
l2a1byGX07DycmtNPip2DDcCHEq/RggKk50PvzANbpaX4PvP4L6PI3b0Ys2CIGI6
X8bdC+J9zkrt6qL62rFGQ+COTeYQTs/bpXeBt86wiPGm5+EWPuH7ay9YcmV4LMo=
=BZBu
-----END PGP SIGNATURE-----
HW42
Jul 10, 2015, 3:50:14 PM7/10/15
to Marek Marczykowski-Górecki, Patrick Schleizer, Vít Šesták, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Marek Marczykowski-Górecki:
required. But 1) my intention was only to ensure there is enough
randomness in the RNG and 2) I don't know how I would estimate the
entropy count (I this case /dev/random in dom0 might be useful).
> Ticket 673 is about /dev/random, which is a separate issue, but
> IIUC there is no problem with sharing initial seed or sth like
> this. This should be solved by haveged - as commented in that
> ticket, it seems to be effective in Xen environment.
The comment refer to whether the real rdtsc is used. But do you know
some argumentation/research whether this timing can indeed not be
predicted by other running VMs?
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVoCHCAAoJEOSsySeKZGgWCaEQAILxBN7AqG2muuHTlQ8TM74T
kcAqAyXT4bJgbVp383c+Am/nMdUwPeABkof2P3nS5L8Dh8ZtGrZdjOubfH8OJn8X
1HRlLxh9A+engMj1w3l9zZBGCCfQYK1pfKMWHN+tqmTfjBYl8+oJvYhzvPyNp/oj
BIGlyCBQnfIQmPra7JXc7LD287+IwdXvOrTE+kcSFMtoRO7Hd2bX3xC228ionECP
A4LngKSF/lJjbsKIuHTAyzEeW5evv5xrNRPzhZMIGdthZRSZ5aZICp92lqsbrVXS
4nRYoVnAqAjA+/C3uRJoHRIT42FrG9dA/phzbxc8TPCWxascr0HTD+KntmqYaT8P
1iKdhpVmd2zl8MN0cLzJOLc/UQhWk8FRF6/hsofS+Zyk8f1aLt9yVQCA07JgODyU
mK5iRlKkyvJC8+G4iMV/q5NpOrulKb350zaIgPjUTNU3u7GUdDeUlXyVbA1zCMud
clvHQcLn/Q2yW4LduLVMq9JYhY7cs27T2PTADX7YyQZyo4KKrWy1+M0yMncMBT4/
BZsOK6f7yvK6KkwGRBZRRsN/MQ5czku8ulj5R6rk4fd+G5NbbNUxQwbSfOpKJqQH
4xZe5Jq6Phe+GDYF67hqjzy0j/QQ27C0hf6/qMMPAy4x7YhztHmy4RtYJI7EWC/o
zPLoVdyw3X/BnEEqH3ui
=rV/W
-----END PGP SIGNATURE-----
Hash: SHA512
Marek Marczykowski-Górecki:
> On Fri, Jul 10, 2015 at 06:58:53PM +0000, Patrick Schleizer wrote:
>> Are you sure, that simple shell redirection writing, i.e. '>
>> /dev/urandom' is sufficient and actually effective? [2]
>
>> Isn't RNDADDENTROPY [1] required?
>
>> I hope, I am wrong. Because then my comment in a related ticket
>> [3] would be wrong and things would be simpler.
>
> systemd-random-seed simply writes to /dev/urandom, so when we want
> to "fix" random-seed issue it should be enough.
Yes. If you want to update the entropy estimate then RNDADDENTROPY is
>> Are you sure, that simple shell redirection writing, i.e. '>
>> /dev/urandom' is sufficient and actually effective? [2]
>
>> Isn't RNDADDENTROPY [1] required?
>
>> I hope, I am wrong. Because then my comment in a related ticket
>> [3] would be wrong and things would be simpler.
>
> systemd-random-seed simply writes to /dev/urandom, so when we want
> to "fix" random-seed issue it should be enough.
required. But 1) my intention was only to ensure there is enough
randomness in the RNG and 2) I don't know how I would estimate the
entropy count (I this case /dev/random in dom0 might be useful).
> Ticket 673 is about /dev/random, which is a separate issue, but
> IIUC there is no problem with sharing initial seed or sth like
> this. This should be solved by haveged - as commented in that
> ticket, it seems to be effective in Xen environment.
some argumentation/research whether this timing can indeed not be
predicted by other running VMs?
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVoCHCAAoJEOSsySeKZGgWCaEQAILxBN7AqG2muuHTlQ8TM74T
kcAqAyXT4bJgbVp383c+Am/nMdUwPeABkof2P3nS5L8Dh8ZtGrZdjOubfH8OJn8X
1HRlLxh9A+engMj1w3l9zZBGCCfQYK1pfKMWHN+tqmTfjBYl8+oJvYhzvPyNp/oj
BIGlyCBQnfIQmPra7JXc7LD287+IwdXvOrTE+kcSFMtoRO7Hd2bX3xC228ionECP
A4LngKSF/lJjbsKIuHTAyzEeW5evv5xrNRPzhZMIGdthZRSZ5aZICp92lqsbrVXS
4nRYoVnAqAjA+/C3uRJoHRIT42FrG9dA/phzbxc8TPCWxascr0HTD+KntmqYaT8P
1iKdhpVmd2zl8MN0cLzJOLc/UQhWk8FRF6/hsofS+Zyk8f1aLt9yVQCA07JgODyU
mK5iRlKkyvJC8+G4iMV/q5NpOrulKb350zaIgPjUTNU3u7GUdDeUlXyVbA1zCMud
clvHQcLn/Q2yW4LduLVMq9JYhY7cs27T2PTADX7YyQZyo4KKrWy1+M0yMncMBT4/
BZsOK6f7yvK6KkwGRBZRRsN/MQ5czku8ulj5R6rk4fd+G5NbbNUxQwbSfOpKJqQH
4xZe5Jq6Phe+GDYF67hqjzy0j/QQ27C0hf6/qMMPAy4x7YhztHmy4RtYJI7EWC/o
zPLoVdyw3X/BnEEqH3ui
=rV/W
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Jul 10, 2015, 3:54:24 PM7/10/15
to HW42, Patrick Schleizer, Vít Šesták, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, Jul 10, 2015 at 09:49:23PM +0200, HW42 wrote:
> Marek Marczykowski-Górecki:
- --
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 v1
iQEcBAEBAgAGBQJVoCLlAAoJENuP0xzK19cswkUIAJQAWz/LQnpCcfl6A/bHbFN4
ay8oK1/ry0BPkLsYwXfTFH1TVqt/jApN01d2fNKKagEEqySK6EW4H1xkzeHinXpG
rsOh74BLBdbEwpKKxyRcvlUcbe+yc03E0pM4qrkqvxmcXRi5teoFB6b7cVefY1wO
Wf9XpYzMB+IDBErCBHh7lJ0NTAigEakTPqE6wC6SzJyKhxa2vniWRzarUYVs5k0/
XxjxJEY4vgB0E7iVPo7TCoqguGI7bFjKc0Ti7IPuV+v496S7PnuGsddYdMcd00jG
bcAm3or/MdQBWiQOVJHpOowQeJH5ka1ldkoliazxVcxIdq+p7NtnRq9QlmXNwKw=
=fGD3
-----END PGP SIGNATURE-----
Hash: SHA1
On Fri, Jul 10, 2015 at 09:49:23PM +0200, HW42 wrote:
> Marek Marczykowski-Górecki:
> > Ticket 673 is about /dev/random, which is a separate issue, but
> > IIUC there is no problem with sharing initial seed or sth like
> > this. This should be solved by haveged - as commented in that
> > ticket, it seems to be effective in Xen environment.
>
> The comment refer to whether the real rdtsc is used. But do you know
> some argumentation/research whether this timing can indeed not be
> predicted by other running VMs?
No, I don't...
> > IIUC there is no problem with sharing initial seed or sth like
> > this. This should be solved by haveged - as commented in that
> > ticket, it seems to be effective in Xen environment.
>
> The comment refer to whether the real rdtsc is used. But do you know
> some argumentation/research whether this timing can indeed not be
> predicted by other running VMs?
- --
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 v1
ay8oK1/ry0BPkLsYwXfTFH1TVqt/jApN01d2fNKKagEEqySK6EW4H1xkzeHinXpG
rsOh74BLBdbEwpKKxyRcvlUcbe+yc03E0pM4qrkqvxmcXRi5teoFB6b7cVefY1wO
Wf9XpYzMB+IDBErCBHh7lJ0NTAigEakTPqE6wC6SzJyKhxa2vniWRzarUYVs5k0/
XxjxJEY4vgB0E7iVPo7TCoqguGI7bFjKc0Ti7IPuV+v496S7PnuGsddYdMcd00jG
bcAm3or/MdQBWiQOVJHpOowQeJH5ka1ldkoliazxVcxIdq+p7NtnRq9QlmXNwKw=
=fGD3
-----END PGP SIGNATURE-----
Vít Šesták
Jul 13, 2015, 2:54:32 PM7/13/15
to qubes...@googlegroups.com, hw...@ipsumj.de, marm...@invisiblethingslab.com, patrick-ma...@whonix.org, groups-no-private-mail--con...@v6ak.com
Ad the patch: I am generally OK with this design. I haven't reviewed details (e.g. what happens when a read from /dev/urandom fails – but that's rather theoretical issue).
Ad RNDADDENTROPY: I am against this. Om bare Debian (and other SystemD distributions), there seems to be nothing increasing the entropy estimate and neither should we unless there is a special (well-discussed) reason. Moreover, when we read the seed from /dev/urandom, we should not increase VM's entropy by definition, I think.
Ad haveged: I am also not sure. I am not expert on RNGs. However, it is worth noting that the mentioned patch would very likely make such issue (unless combined with some other issue) very impractical to abuse. Even if all the VMs gathered the same entropy bits from haveged, they would have different initial entropy bits. For inter-VM attacks, this would decrease /dev/random's quality somewhere to /dev/urandom's quality, but the different initial seed feeded from dom0 should guarrant proper /dev/random behavior. One might argue that one could attack dom0's random seed this way, but this is virtually impossible, as dom0 can collect entropy even when other VMs are not running and it stores the entropy between reboots. Some review of using haveged in Qubes would be welcome, though.
Regards,
Vít Šesták 'v6ak'
Ad RNDADDENTROPY: I am against this. Om bare Debian (and other SystemD distributions), there seems to be nothing increasing the entropy estimate and neither should we unless there is a special (well-discussed) reason. Moreover, when we read the seed from /dev/urandom, we should not increase VM's entropy by definition, I think.
Ad haveged: I am also not sure. I am not expert on RNGs. However, it is worth noting that the mentioned patch would very likely make such issue (unless combined with some other issue) very impractical to abuse. Even if all the VMs gathered the same entropy bits from haveged, they would have different initial entropy bits. For inter-VM attacks, this would decrease /dev/random's quality somewhere to /dev/urandom's quality, but the different initial seed feeded from dom0 should guarrant proper /dev/random behavior. One might argue that one could attack dom0's random seed this way, but this is virtually impossible, as dom0 can collect entropy even when other VMs are not running and it stores the entropy between reboots. Some review of using haveged in Qubes would be welcome, though.
Regards,
Vít Šesták 'v6ak'
Vít Šesták
Aug 18, 2015, 5:26:48 PM8/18/15
to qubes-devel, hw...@ipsumj.de, marm...@invisiblethingslab.com, patrick-ma...@whonix.org, groups-no-private-mail--con...@v6ak.com
If I understand Disposable VMs well, the problem with entropy will be somehow greater there. If they are just restored from suspend savefile, RNG state will be also restored. However:
* There will be not so much time for haveged.
* /proc/sys/kernel/random/entropy_avail will be also restored, so /dev/random will be affected
* If /proc/sys/kernel/random/entropy_avail is high enough, haveged will not gather more entropy.
One might wonder what cryptography will one do in a DisposableVM, as DVM is intended rather for untrusted stuff. But…
* TOR: If one runs tor directly in DVM (e.g. through torbrowser), user might get better trackable
* One might use Firefox in DVM just for more separated private browsing. In such case, both HTTPS and .onion might be weakened.
I haven't analyzed any of these cases in deep. The issue might be either practical or purely theoretical, I don't know. But the issue seems to be much more close to be practical with DVMs than with regular AppVMs.
Regards,
Vít Šesták 'v6ak'
* There will be not so much time for haveged.
* /proc/sys/kernel/random/entropy_avail will be also restored, so /dev/random will be affected
* If /proc/sys/kernel/random/entropy_avail is high enough, haveged will not gather more entropy.
One might wonder what cryptography will one do in a DisposableVM, as DVM is intended rather for untrusted stuff. But…
* TOR: If one runs tor directly in DVM (e.g. through torbrowser), user might get better trackable
* One might use Firefox in DVM just for more separated private browsing. In such case, both HTTPS and .onion might be weakened.
I haven't analyzed any of these cases in deep. The issue might be either practical or purely theoretical, I don't know. But the issue seems to be much more close to be practical with DVMs than with regular AppVMs.
Regards,
Vít Šesták 'v6ak'
Marek Marczykowski-Górecki
Aug 25, 2015, 10:56:15 PM8/25/15
to Vít Šesták, qubes-devel, hw...@ipsumj.de, patrick-ma...@whonix.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tue, Aug 18, 2015 at 02:26:48PM -0700, Vít Šesták wrote:
> If I understand Disposable VMs well, the problem with entropy will be
> somehow greater there. If they are just restored from suspend savefile, RNG
> state will be also restored. However:
> * There will be not so much time for haveged.
> * /proc/sys/kernel/random/entropy_avail will be also restored, so
> /dev/random will be affected
> * If /proc/sys/kernel/random/entropy_avail is high enough, haveged will not
> gather more entropy.
>
> One might wonder what cryptography will one do in a DisposableVM, as DVM is
> intended rather for untrusted stuff. But…
> * TOR: If one runs tor directly in DVM (e.g. through torbrowser), user
> might get better trackable
> * One might use Firefox in DVM just for more separated private browsing. In
> such case, both HTTPS and .onion might be weakened.
>
> I haven't analyzed any of these cases in deep. The issue might be either
> practical or purely theoretical, I don't know. But the issue seems to be
> much more close to be practical with DVMs than with regular AppVMs.
The HW42's patch takes care also about this case - random-seed is feeded
also at DispVM startup (after restoring from a savefile).
Which reminds me I still haven't applied those patches...
- --
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 v1
iQEcBAEBCAAGBQJV3SrIAAoJENuP0xzK19cssm8H/0GXsjpX4Dy4YKzrbysC5OX4
lkfNRM3ciYPPxXtPlJbvhlW9vB60PGcIuiMB8/OEZ6WYqFCsDL8SLDTE4ec6ddVV
Th1HFHoKTEjN+Ix6QbOCVv5YaZXbmBRUWG6eVsY8wVy3ZwjwkzXR0Q/AW5Nu1tLM
KS89tK7+KiZvf82kQzEaeigUBYveYqCyYUbhrZ57T7NDXoOt8zz5b1uDxrKWA6qV
OunGVj65zPPsxgppZdRU+KvQ6XwDrEC6FD4/gVok6GA4OpKCIWYfngeEamtZzq9d
Zwu4Dl7hUUvJgCjVNiv0LaiJvvOiIii7+3fuSt58bYlzs9sn+aFPJGpISDUe7lY=
=AB6f
-----END PGP SIGNATURE-----
Hash: SHA256
On Tue, Aug 18, 2015 at 02:26:48PM -0700, Vít Šesták wrote:
> If I understand Disposable VMs well, the problem with entropy will be
> somehow greater there. If they are just restored from suspend savefile, RNG
> state will be also restored. However:
> * There will be not so much time for haveged.
> * /proc/sys/kernel/random/entropy_avail will be also restored, so
> /dev/random will be affected
> * If /proc/sys/kernel/random/entropy_avail is high enough, haveged will not
> gather more entropy.
>
> One might wonder what cryptography will one do in a DisposableVM, as DVM is
> intended rather for untrusted stuff. But…
> * TOR: If one runs tor directly in DVM (e.g. through torbrowser), user
> might get better trackable
> * One might use Firefox in DVM just for more separated private browsing. In
> such case, both HTTPS and .onion might be weakened.
>
> I haven't analyzed any of these cases in deep. The issue might be either
> practical or purely theoretical, I don't know. But the issue seems to be
> much more close to be practical with DVMs than with regular AppVMs.
also at DispVM startup (after restoring from a savefile).
Which reminds me I still haven't applied those patches...
- --
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 v1
lkfNRM3ciYPPxXtPlJbvhlW9vB60PGcIuiMB8/OEZ6WYqFCsDL8SLDTE4ec6ddVV
Th1HFHoKTEjN+Ix6QbOCVv5YaZXbmBRUWG6eVsY8wVy3ZwjwkzXR0Q/AW5Nu1tLM
KS89tK7+KiZvf82kQzEaeigUBYveYqCyYUbhrZ57T7NDXoOt8zz5b1uDxrKWA6qV
OunGVj65zPPsxgppZdRU+KvQ6XwDrEC6FD4/gVok6GA4OpKCIWYfngeEamtZzq9d
Zwu4Dl7hUUvJgCjVNiv0LaiJvvOiIii7+3fuSt58bYlzs9sn+aFPJGpISDUe7lY=
=AB6f
-----END PGP SIGNATURE-----
Vít Šesták
Aug 29, 2015, 12:00:58 PM8/29/15
to qubes-devel, groups-no-private-mail--con...@v6ak.com, hw...@ipsumj.de, patrick-ma...@whonix.org
On Wednesday, August 26, 2015 at 4:56:15 AM UTC+2, Marek Marczykowski-Górecki wrote:
The HW42's patch takes care also about this case - random-seed is feeded
also at DispVM startup (after restoring from a savefile).
Partially… While I agree that it should make any attack impractical and it is better than nothing, it may overestimate the entropy for /dev/random. (Which also inhibits haveged.)
So, attacks should be impractical (and probably impossible with the current knowledge) after applying the HW42's patch, but /dev/random may give urandom-grade entropy after DVM boot. This is unlikely practical for today's attackers, but still not nice.
I am not sure how can one decrease entropy_avail in other way that by actual reading from /dev/random. Which is not nice for multiple reasons.
Regards,
Vít Šesták 'v6ak'
Vít Šesták
Aug 29, 2015, 2:41:02 PM8/29/15
to qubes-devel, groups-no-private-mail--con...@v6ak.com, hw...@ipsumj.de, patrick-ma...@whonix.org
In order to demonstrate that the current situation with DVMs is bad, I've done some experiment:
1. Get some entropy samples:
% for i in $(seq 1000); do time qvm-run '$dispvm' 'dd if=/dev/random bs=16 count=1' > /tmp/ent-$i; done
This generated 998 valid samples and two empty files with hanging DVMs. I don't care about the two failed samples now.
2. Compare them by a command like: for i in /tmp/ent-*; do printf "%s\n" "$(head -c4 "$i" | base64)"; done | sort -k2 | uniq -cd
It is clear that there will be some one-byte collisions (due to pigeonhole principle). It is likely that there will be some 2-byte collisions (about 99.95% probability according to the Birthday paradox). There were 7 such pairs and one such quadruple. OK, but is should be extremely unlikely (about 2^-64) to get a 16-bytes collision.
Going further, I looked for at least 3 common leading bytes. This should be rather unlikely (about 2.92%), but still plausible. There was one quadruple. While going further, I realized that the quadruple has all the sixteen bytes equal! Let's use fdupes:
/tmp% mkdir ent
/tmp% mv ent-* ent
/tmp% cd ent
/tmp/ent% fdupes .
./ent-5
./ent-578
./ent-646
./ent-703
./ent-452
./ent-462
In order to be sure, I'll examine the files:
/tmp/ent% base64 ent-5
ULI5NczxnCk8DVpuCGUFSQ==
Uahh, this quadruple seems to be real! Probability of such pair should be negligibly low. Probability of such quadruple should be even lower.
/tmp/ent% base64 ent-452
OK, this pair is the pair of failed tries. Those DVMs are hanging and they have produced no output. We should ignore it. (Note that I've also taken care to exclude this false collision from other parts of this report.)
(Some probability calculations come from https://lazycackle.com/Probability_of_repeated_event_online_calculator__birthday_problem_.html .)
One more note (impact on the experiment and haveged will be explained later): qvm-run '$dispvm' cat /proc/sys/kernel/random/entropy_avail gives consistent numbers. For 35 tries, I got numbers from 2127 to 2150.
Conclusion: /dev/random (NOT just /dev/urandom!) in DVM is seriously broken provided that you compare results from multiple instances of one DVM snapshot. While I haven't confirmed any practical exploitability, it seems to be plausible in some scenarios.
Workarounds (one of them should be enough):
a. Don't use DVM for anything relying on either /dev/random or /dev/urandom, especially any crypto-related tasks. This may affect HTTPS, TOR, BTC wallets and some update mechanisms relying on HTTPS (maybe Firefox addon update mechanism)?
b. Remove the bad entropy from entropy pool. You can use for example the following command:
head -c"$(cat /proc/sys/kernel/random/entropy_avail)" /dev/random > /dev/null
Note that this command is a bit ham-fisted. When you are using haveged, you should be fine with that. When there is no fast source of entropy like haveged, this command may take much more time than desired in some situations. (Well, maybe I have interchanged bytes and bits… Maybe calvulating entropy_avail/8+1 would be OK.)
c. Don't reuse DVM snapshots. This is, however, somewhat hard to do. Moreover, it is impossible to enforce if you have a malicious AppVM…
Note on haveged: I repeat that haveged may not help in case of DVMs. If you are unlucky, the DVM savepoint generation process generates much entropy. According to its documentation, it starts gathering entropy when entropy_avail falls below low water mark (which is AFAIK 1024 bits by default). The point is that having too much “entropy” (i.e. having high entropy estimate) prevents haveged from doing its job, so /dev/random will continue will the spoiled entropy and /dev/urandom's entropy will not be improved.
Regards,
Vít Šesták 'v6ak'
1. Get some entropy samples:
% for i in $(seq 1000); do time qvm-run '$dispvm' 'dd if=/dev/random bs=16 count=1' > /tmp/ent-$i; done
This generated 998 valid samples and two empty files with hanging DVMs. I don't care about the two failed samples now.
2. Compare them by a command like: for i in /tmp/ent-*; do printf "%s\n" "$(head -c4 "$i" | base64)"; done | sort -k2 | uniq -cd
It is clear that there will be some one-byte collisions (due to pigeonhole principle). It is likely that there will be some 2-byte collisions (about 99.95% probability according to the Birthday paradox). There were 7 such pairs and one such quadruple. OK, but is should be extremely unlikely (about 2^-64) to get a 16-bytes collision.
Going further, I looked for at least 3 common leading bytes. This should be rather unlikely (about 2.92%), but still plausible. There was one quadruple. While going further, I realized that the quadruple has all the sixteen bytes equal! Let's use fdupes:
/tmp% mkdir ent
/tmp% mv ent-* ent
/tmp% cd ent
/tmp/ent% fdupes .
./ent-5
./ent-578
./ent-646
./ent-703
./ent-452
./ent-462
In order to be sure, I'll examine the files:
/tmp/ent% base64 ent-5
ULI5NczxnCk8DVpuCGUFSQ==
Uahh, this quadruple seems to be real! Probability of such pair should be negligibly low. Probability of such quadruple should be even lower.
/tmp/ent% base64 ent-452
OK, this pair is the pair of failed tries. Those DVMs are hanging and they have produced no output. We should ignore it. (Note that I've also taken care to exclude this false collision from other parts of this report.)
(Some probability calculations come from https://lazycackle.com/Probability_of_repeated_event_online_calculator__birthday_problem_.html .)
One more note (impact on the experiment and haveged will be explained later): qvm-run '$dispvm' cat /proc/sys/kernel/random/entropy_avail gives consistent numbers. For 35 tries, I got numbers from 2127 to 2150.
Conclusion: /dev/random (NOT just /dev/urandom!) in DVM is seriously broken provided that you compare results from multiple instances of one DVM snapshot. While I haven't confirmed any practical exploitability, it seems to be plausible in some scenarios.
Workarounds (one of them should be enough):
a. Don't use DVM for anything relying on either /dev/random or /dev/urandom, especially any crypto-related tasks. This may affect HTTPS, TOR, BTC wallets and some update mechanisms relying on HTTPS (maybe Firefox addon update mechanism)?
b. Remove the bad entropy from entropy pool. You can use for example the following command:
head -c"$(cat /proc/sys/kernel/random/entropy_avail)" /dev/random > /dev/null
Note that this command is a bit ham-fisted. When you are using haveged, you should be fine with that. When there is no fast source of entropy like haveged, this command may take much more time than desired in some situations. (Well, maybe I have interchanged bytes and bits… Maybe calvulating entropy_avail/8+1 would be OK.)
c. Don't reuse DVM snapshots. This is, however, somewhat hard to do. Moreover, it is impossible to enforce if you have a malicious AppVM…
Note on haveged: I repeat that haveged may not help in case of DVMs. If you are unlucky, the DVM savepoint generation process generates much entropy. According to its documentation, it starts gathering entropy when entropy_avail falls below low water mark (which is AFAIK 1024 bits by default). The point is that having too much “entropy” (i.e. having high entropy estimate) prevents haveged from doing its job, so /dev/random will continue will the spoiled entropy and /dev/urandom's entropy will not be improved.
Regards,
Vít Šesták 'v6ak'
Vít Šesták
Aug 29, 2015, 3:40:35 PM8/29/15
to qubes-devel, groups-no-private-mail--con...@v6ak.com, hw...@ipsumj.de, patrick-ma...@whonix.org
So, I am sorry for the 2^-64 number, this is wrong, as it does not take in account number of tries. However, the number should be still really negligible.
I have some hypothesis on the four cases of same result: While time is fairly predicable, it might be added to the RNG state (without increasing the entropy estimate). In many cases, the time is probably synced early enough, so even flawed RNG output generated different results. In at least 4 of 998 cases, the time did not get synced early enough, so it generated the same value.
This hypothesis would explain multiple phenomena:
* There is no collision of length 3-15 bytes. There are shorted collisions and longer collisions, but no one in this range.
* There is just one 16B value with multiple occurrences. There are not, for example, two distinct pairs. There is just one quadriple.
Obviously, more tries would give us statistically more significant data.
I am, however, not sure how this hypothesis affects the seriousness of the problem.
Regards,
Vít Šesták 'v6ak'
I have some hypothesis on the four cases of same result: While time is fairly predicable, it might be added to the RNG state (without increasing the entropy estimate). In many cases, the time is probably synced early enough, so even flawed RNG output generated different results. In at least 4 of 998 cases, the time did not get synced early enough, so it generated the same value.
This hypothesis would explain multiple phenomena:
* There is no collision of length 3-15 bytes. There are shorted collisions and longer collisions, but no one in this range.
* There is just one 16B value with multiple occurrences. There are not, for example, two distinct pairs. There is just one quadriple.
Obviously, more tries would give us statistically more significant data.
I am, however, not sure how this hypothesis affects the seriousness of the problem.
Regards,
Vít Šesták 'v6ak'
HW42
Aug 29, 2015, 8:45:57 PM8/29/15
to Vít Šesták, qubes-devel, patrick-ma...@whonix.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Vít Šesták:
once properly seeded /dev/{u,}random should be good enough for anything;
see second half of http://blog.cr.yp.to/20140205-entropy.html and
http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
for a reasoning why.
I addition it's not clear for me why haveged should generate
"better" random than the seed from dom0.
(This doesn't mean I have anything against clearing the entropy
estimate (see also other mail) as long haveged is running.)
> So, attacks should be impractical (and probably impossible with the
> current knowledge) after applying the HW42's patch, but
> /dev/random may give urandom-grade entropy after DVM boot. This is
> unlikely practical for today's attackers, but still not nice.
>
> I am not sure how can one decrease entropy_avail in other way that
> by actual reading from /dev/random. Which is not nice for multiple
> reasons.
>
> Regards, Vít Šesták 'v6ak'
>
>
>
>> Which reminds me I still haven't applied those patches...
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJV4lIlAAoJEOSsySeKZGgWg3wP/18yfSCt0dMHqThHKFOBhYqD
j0e9rca5MsRcVaZdCc8cheJSzeUdenMVuFn9srt0iXoEbBW9viCbC73f39fx1tLN
10B0OBbi6GuLGIXy/cjnZ7ceJoMqBgiUMMLt3pndKQ3R26qPdaiqPIDVv1Gv9k4D
XQyHBfk5sbj40mVh6aU7cyVyMP72raBdvHFdBj2A7WCQSOSHHSM2+G1EFmbHgf2y
IbJW9nB3Z7n4d12TGS7ISWvjVsOqfxQzt7fW8nukuPulz0IOvqHGtb9vDVm00lk7
KxPiIwqKcpu4uPxEHbjbXMC8EUYD9B5h7D18P0z33vFO+0f+OpNQfh9HmoGD+hFR
Fw/wDG9t/VM3FRF0WiM6XsG49MEnXnTJ6eBuqWKTvbYVdzBmGuPo9N52pjd8/AWu
Dcp25lkiDYYUBeM64dBTGY7ZNXL4oEhjat4/iS0EHCVBydcDsJTtrLGVjBOrrdXM
66TvYJSdWnpGO+PPalsDtx5+o0VAay9uou9YKqdgvWhEZ+0OdZXGkxa3tj41NccE
tKNW2KWpZ4jTFxx/7AIruTfr3nXVWSQUlOL4Q7VPEqBpQV6P0gsTrklC0RkAfM4s
wiZ+B7qY0niEfcqeHuXRx6KT9wwcYh+ePxFFxWA/Jxf4KtqTVAewiUAi8EwRU9sb
PGPz4Rws3IeAgpfzm/6e
=OE+J
-----END PGP SIGNATURE-----
Hash: SHA512
Vít Šesták:
>
> On Wednesday, August 26, 2015 at 4:56:15 AM UTC+2, Marek
> Marczykowski-Górecki wrote:
>
>> The HW42's patch takes care also about this case - random-seed is
>> feeded also at DispVM startup (after restoring from a
>> savefile).
>>
>
> Partially… While I agree that it should make any attack impractical
> and it is better than nothing, it may overestimate the entropy for
> /dev/random. (Which also inhibits haveged.)
I don't really care much about the entropy estimate in /dev/random since
> On Wednesday, August 26, 2015 at 4:56:15 AM UTC+2, Marek
> Marczykowski-Górecki wrote:
>
>> The HW42's patch takes care also about this case - random-seed is
>> feeded also at DispVM startup (after restoring from a
>> savefile).
>>
>
> Partially… While I agree that it should make any attack impractical
> and it is better than nothing, it may overestimate the entropy for
> /dev/random. (Which also inhibits haveged.)
once properly seeded /dev/{u,}random should be good enough for anything;
see second half of http://blog.cr.yp.to/20140205-entropy.html and
http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
for a reasoning why.
I addition it's not clear for me why haveged should generate
"better" random than the seed from dom0.
(This doesn't mean I have anything against clearing the entropy
estimate (see also other mail) as long haveged is running.)
> So, attacks should be impractical (and probably impossible with the
> current knowledge) after applying the HW42's patch, but
> /dev/random may give urandom-grade entropy after DVM boot. This is
> unlikely practical for today's attackers, but still not nice.
>
> I am not sure how can one decrease entropy_avail in other way that
> by actual reading from /dev/random. Which is not nice for multiple
> reasons.
>
> Regards, Vít Šesták 'v6ak'
>
>
>
>> Which reminds me I still haven't applied those patches...
iQIcBAEBCgAGBQJV4lIlAAoJEOSsySeKZGgWg3wP/18yfSCt0dMHqThHKFOBhYqD
j0e9rca5MsRcVaZdCc8cheJSzeUdenMVuFn9srt0iXoEbBW9viCbC73f39fx1tLN
10B0OBbi6GuLGIXy/cjnZ7ceJoMqBgiUMMLt3pndKQ3R26qPdaiqPIDVv1Gv9k4D
XQyHBfk5sbj40mVh6aU7cyVyMP72raBdvHFdBj2A7WCQSOSHHSM2+G1EFmbHgf2y
IbJW9nB3Z7n4d12TGS7ISWvjVsOqfxQzt7fW8nukuPulz0IOvqHGtb9vDVm00lk7
KxPiIwqKcpu4uPxEHbjbXMC8EUYD9B5h7D18P0z33vFO+0f+OpNQfh9HmoGD+hFR
Fw/wDG9t/VM3FRF0WiM6XsG49MEnXnTJ6eBuqWKTvbYVdzBmGuPo9N52pjd8/AWu
Dcp25lkiDYYUBeM64dBTGY7ZNXL4oEhjat4/iS0EHCVBydcDsJTtrLGVjBOrrdXM
66TvYJSdWnpGO+PPalsDtx5+o0VAay9uou9YKqdgvWhEZ+0OdZXGkxa3tj41NccE
tKNW2KWpZ4jTFxx/7AIruTfr3nXVWSQUlOL4Q7VPEqBpQV6P0gsTrklC0RkAfM4s
wiZ+B7qY0niEfcqeHuXRx6KT9wwcYh+ePxFFxWA/Jxf4KtqTVAewiUAi8EwRU9sb
PGPz4Rws3IeAgpfzm/6e
=OE+J
-----END PGP SIGNATURE-----
HW42
Aug 29, 2015, 8:53:19 PM8/29/15
to Vít Šesták, qubes-devel, patrick-ma...@whonix.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Vít Šesták:
> *Conclusion:* /dev/random (NOT just /dev/urandom!) in DVM is
> *Workarounds (one of them should be enough):* a. Don't use DVM for
from random(4):
RNDZAPENTCNT, RNDCLEARPOOL
Zero the entropy count of all pools and add some system data
(such as wall clock) to the pools.
So as long haveged is running (to avoid strange locks in programs
using /dev/random) the solution seems to use a little program which
calls the RNDZAPENTCNT ioctl on /dev/random in combination with my
patches.
> *Note on haveged:* I repeat that haveged may not help in case of
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJV4lPeAAoJEOSsySeKZGgWT2cQAKuzSJMiWdjLykrv8RgyAO9y
ReOHelfbf07v1rb97U6yFwg+cgIQRcZ9nc/v94Ble5+08sOUfwUN9M3ZheJPBdGm
E0i/X+xWCUWKn6GmAaTEERYQ87kRF+IUq5BOJifoGe2I2+Q/g0TE6C8w6dC0Y13m
KGblereUnnHeSi62sz6D1lU7hNBE4S23BcbJLoqpeTGuLXbE9+0Q1W/VbVUurPO0
unBVZOohIAn5G1Wzu/YRelirXwALsGjVvd/ylKy96RPIdpjIYbXNwmfOTf4FmdH7
c5/OU7c6KxAErrzSrbJIWr3AOx4ijlMxNvbkzIXQUspEARr5Awquj133fGBrIE54
AG+I9Mizo0WBUxGEU4/d02zkJrvMwAdy9hhqpGtAVuE6tv+AMKUW3VHDKHMGbq5w
41zhQdK84Xs7bBd/8AnOx0NBk6gy8hiZgNziwDKCQHxxTs2Gy4lcybl7JRyw61Bx
IMKPMNQdXHNE+e3QnlbvwEFxq+xRrOOtJ0+3ikRd5yKJcA7s//g62rgyQcVpI2mN
6jcNhuouHK7uwNuSpbmS2pQKaO3LpFat0rUI+Q+QATgj8keHt2O7M/TSopqlLljG
WHZ6Gvr+jj4ziu3Prep5iSsnUnHamvL88H0KDB+aNAGdqm1nRX91BGRdfiUAGJxI
KA6CPrHpMbCDPvs3n280
=CxfS
-----END PGP SIGNATURE-----
Hash: SHA512
Vít Šesták:
> seriously broken provided that you compare results from multiple
> instances of one DVM snapshot. While I haven't confirmed any
> practical exploitability, it seems to be plausible in some
> scenarios.
Interesting tests. I will comment later.
> instances of one DVM snapshot. While I haven't confirmed any
> practical exploitability, it seems to be plausible in some
> scenarios.
> *Workarounds (one of them should be enough):* a. Don't use DVM for
> anything relying on either /dev/random or /dev/urandom, especially
> any crypto-related tasks. This may affect HTTPS, TOR, BTC wallets
> and some update mechanisms relying on HTTPS (maybe Firefox addon
> update mechanism)? b. Remove the bad entropy from entropy pool. You
> can use for example the following command: head -c"$(cat
> /proc/sys/kernel/random/entropy_avail)" /dev/random > /dev/null
> Note that this command is a bit ham-fisted. When you are using
> haveged, you should be fine with that. When there is no fast source
> of entropy like haveged, this command may take much more time than
> desired in some situations. (Well, maybe I have interchanged bytes
> and bits… Maybe calvulating entropy_avail/8+1 would be OK.) c.
> Don't reuse DVM snapshots. This is, however, somewhat hard to do.
> Moreover, it is impossible to enforce if you have a malicious
> AppVM…
I think the proper way to do this is the RNDZAPENTCNT ioctl. Citing
> any crypto-related tasks. This may affect HTTPS, TOR, BTC wallets
> and some update mechanisms relying on HTTPS (maybe Firefox addon
> update mechanism)? b. Remove the bad entropy from entropy pool. You
> can use for example the following command: head -c"$(cat
> /proc/sys/kernel/random/entropy_avail)" /dev/random > /dev/null
> Note that this command is a bit ham-fisted. When you are using
> haveged, you should be fine with that. When there is no fast source
> of entropy like haveged, this command may take much more time than
> desired in some situations. (Well, maybe I have interchanged bytes
> and bits… Maybe calvulating entropy_avail/8+1 would be OK.) c.
> Don't reuse DVM snapshots. This is, however, somewhat hard to do.
> Moreover, it is impossible to enforce if you have a malicious
> AppVM…
from random(4):
RNDZAPENTCNT, RNDCLEARPOOL
Zero the entropy count of all pools and add some system data
(such as wall clock) to the pools.
So as long haveged is running (to avoid strange locks in programs
using /dev/random) the solution seems to use a little program which
calls the RNDZAPENTCNT ioctl on /dev/random in combination with my
patches.
> *Note on haveged:* I repeat that haveged may not help in case of
iQIcBAEBCgAGBQJV4lPeAAoJEOSsySeKZGgWT2cQAKuzSJMiWdjLykrv8RgyAO9y
ReOHelfbf07v1rb97U6yFwg+cgIQRcZ9nc/v94Ble5+08sOUfwUN9M3ZheJPBdGm
E0i/X+xWCUWKn6GmAaTEERYQ87kRF+IUq5BOJifoGe2I2+Q/g0TE6C8w6dC0Y13m
KGblereUnnHeSi62sz6D1lU7hNBE4S23BcbJLoqpeTGuLXbE9+0Q1W/VbVUurPO0
unBVZOohIAn5G1Wzu/YRelirXwALsGjVvd/ylKy96RPIdpjIYbXNwmfOTf4FmdH7
c5/OU7c6KxAErrzSrbJIWr3AOx4ijlMxNvbkzIXQUspEARr5Awquj133fGBrIE54
AG+I9Mizo0WBUxGEU4/d02zkJrvMwAdy9hhqpGtAVuE6tv+AMKUW3VHDKHMGbq5w
41zhQdK84Xs7bBd/8AnOx0NBk6gy8hiZgNziwDKCQHxxTs2Gy4lcybl7JRyw61Bx
IMKPMNQdXHNE+e3QnlbvwEFxq+xRrOOtJ0+3ikRd5yKJcA7s//g62rgyQcVpI2mN
6jcNhuouHK7uwNuSpbmS2pQKaO3LpFat0rUI+Q+QATgj8keHt2O7M/TSopqlLljG
WHZ6Gvr+jj4ziu3Prep5iSsnUnHamvL88H0KDB+aNAGdqm1nRX91BGRdfiUAGJxI
KA6CPrHpMbCDPvs3n280
=CxfS
-----END PGP SIGNATURE-----
Vít Šesták
Aug 30, 2015, 4:33:12 AM8/30/15
to qubes-devel, groups-no-private-mail--con...@v6ak.com, patrick-ma...@whonix.org, hw...@ipsumj.de
First, I'll do one more correction to my statements. The fact that entropy_avail is above low water mark does not tell us so much, because haveged has been started before taking the snapshot and because there is some hysteresis. So, when the entorpy_avail is somewhere between low water mark and the upper bound (which is probably the pool size), haveged may be either running (and gathering more entropy) or suspended (waiting the entropy_avail to fall below the low water mark). The latter is however more likely, because the haveged seems to be very very fast and I assume that entropy is consumed rather wisely. I also suppose that this is the state of haveged for most of the time in almost all systems.
However, if gathering entropy by haveged was my case, there is a possible explanation for the collisions other than seeding by time…
However, if gathering entropy by haveged was my case, there is a possible explanation for the collisions other than seeding by time…
I don't really care much about the entropy estimate in /dev/random since
once properly seeded /dev/{u,}random should be good enough for anything;
see second half of http://blog.cr.yp.to/20140205-entropy.html and
http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
for a reasoning why.
I know that urandom should be OK when properly seeded – provided that there is no flaw in RNG etc. Theoretically, we could just seed the RNG by 32 bytes, disable haveged (and maybe also other entropy sources) and link /dev/random to /dev/urandom. However, when there is some flaw (either a flaw of RNG itself or a flaw like that), things like haveged might make it less serious (e.g. less practical to exploit in a real case). That's also a reason why /dev/random is recommended for long-term keys (e.g. OpenPGP keys, TLS keys, …).
I also don't feel good of breaking some expectations and subsequent reasoning that nothing bad should happen. Especially when it is simple not to break the expectation.
I addition it's not clear for me why haveged should generate
"better" random than the seed from dom0.
Well, I didn't argue against a seed from dom0. Arguing against some seed like that would be dumb, as this affects /dev/urandom even if entropy estimate is set to zero. (The impact is much lower when using haveged, but the situation is still not nice.)
(This doesn't mean I have anything against clearing the entropy
estimate (see also other mail) as long haveged is running.)
So, we probably agree with each other that:
* A 32B seed from dom0's /dev/urandom should solve most of things.
* Clearing entropy estimate is not essential if there is not some another flaw, but it gives some safety margin.
* Using haveged is also not essential, but it also gives some safety margin.
I think the proper way to do this is the RNDZAPENTCNT ioctl. Citing
from random(4):
RNDZAPENTCNT, RNDCLEARPOOL
Zero the entropy count of all pools and add some system data
(such as wall clock) to the pools.
So as long haveged is running (to avoid strange locks in programs
using /dev/random) the solution seems to use a little program which
calls the RNDZAPENTCNT ioctl on /dev/random in combination with my
patches.
Great! That's something I've unsuccessfully tried to Google for.
Regards,
Vít Šesták 'v6ak'
Vít Šesták
Sep 23, 2015, 2:33:36 PM9/23/15
to qubes-devel, groups-no-private-mail--con...@v6ak.com, patrick-ma...@whonix.org, hw...@ipsumj.de
Marek, what's the current status?
From my point of view, I would see the priorities to be in the following order:
1. Apply the patch. This should bring most security benefits and should be easy.
2. Make it fail-securely. That means that any theoretical fail will prevent VM from normal booting rather than allow the VM to boot silently insecurely. This seems to be important especially for DispVMs.
3. Add RNDCLEARPOOL for DispVMs. This should fix entropy estimate. Even without this, users should be safe if other counter-measures are applied. However, having overestimated entropy estimates might go wrong with some another RNG-related flaw, so it would be better to have this also fixed, especially if the fix seems rather trivial.
Should I create a ticket on Github?
Regards,
Vít Šesták 'v6ak'
From my point of view, I would see the priorities to be in the following order:
1. Apply the patch. This should bring most security benefits and should be easy.
2. Make it fail-securely. That means that any theoretical fail will prevent VM from normal booting rather than allow the VM to boot silently insecurely. This seems to be important especially for DispVMs.
3. Add RNDCLEARPOOL for DispVMs. This should fix entropy estimate. Even without this, users should be safe if other counter-measures are applied. However, having overestimated entropy estimates might go wrong with some another RNG-related flaw, so it would be better to have this also fixed, especially if the fix seems rather trivial.
Should I create a ticket on Github?
Regards,
Vít Šesták 'v6ak'
Patrick Schleizer
Feb 15, 2016, 2:56:42 PM2/15/16
to qubes...@googlegroups.com
There are various issues wrt to the security of randomness / entropy in
Linux distributions generally. (therefore also in Qubes). More so in VMs
and read-only media. I am unable to express most of them for now. Please
read the following:
https://www.av8n.com/computer/htm/secure-random.htm
***
https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/qubes-random-seed.sh
> qubesdb-read /qubes-random-seed | base64 -d > /dev/urandom
Would it make sense to add below...
qubesdb-read /qubes-random-seed | base64 -d > /dev/random
?
***
Related...
persist random seed files [entropy] in TemplateBasedVMs
https://github.com/QubesOS/qubes-issues/issues/1752
Linux distributions generally. (therefore also in Qubes). More so in VMs
and read-only media. I am unable to express most of them for now. Please
read the following:
https://www.av8n.com/computer/htm/secure-random.htm
***
https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/qubes-random-seed.sh
> qubesdb-read /qubes-random-seed | base64 -d > /dev/urandom
Would it make sense to add below...
qubesdb-read /qubes-random-seed | base64 -d > /dev/random
?
***
Related...
persist random seed files [entropy] in TemplateBasedVMs
https://github.com/QubesOS/qubes-issues/issues/1752
HW42
Feb 15, 2016, 9:02:26 PM2/15/16
to Patrick Schleizer, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Patrick Schleizer:
Hash: SHA512
> There are various issues wrt to the security of randomness / entropy in
> Linux distributions generally. (therefore also in Qubes). More so in VMs
> and read-only media. I am unable to express most of them for now. Please
> read the following:
> https://www.av8n.com/computer/htm/secure-random.htm
This contains some intresesting thoughts on seeding (I think the
> Linux distributions generally. (therefore also in Qubes). More so in VMs
> and read-only media. I am unable to express most of them for now. Please
> read the following:
> https://www.av8n.com/computer/htm/secure-random.htm
vmlinux/initramfs seeding is an interesting approach for non Qubes
systems), but it lacks a description of the current state of the Linux
RNG.
> ***
>
> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/qubes-random-seed.sh
>
>> qubesdb-read /qubes-random-seed | base64 -d > /dev/urandom
>
> Would it make sense to add below...
>
> qubesdb-read /qubes-random-seed | base64 -d > /dev/random
>
> ?
> ***
>
> Related...
> persist random seed files [entropy] in TemplateBasedVMs
> https://github.com/QubesOS/qubes-issues/issues/1752
those seeds.
There are two things which I don't consider important but might be worth
to think about regarding the current solution.
1) Try harder to seed early.
Currently there are a few things which get executed before the seeding
through dom0. I think this is ok since the RNG is mostly important for
the applications run by the user which get started much later. But with
some tricks this could be done much earlier.
2) Clear the entropy estimate at DispVM start.
We reseed the RNG during the DispVM start, but as discussed earlier we
could also reset the entropy estimate. See [2], [3].
[0]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?h=v4.4#n1584
[1]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?h=v4.4#n1512
[2]: https://groups.google.com/d/msgid/qubes-devel/55E253E3.8020704%40ipsumj.de
[3]: https://groups.google.com/d/msgid/qubes-devel/55E25227.3060709%40ipsumj.de
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJWwoMXAAoJEOSsySeKZGgWww0P/i88iJiaL403p9MukSwwdMaT
kFUdHkXS6ArLc4dWMi2BrPw9/rlbvH+EAH7qeSR2QLMczxinb+v/xV5SuXDZWM5b
7ZSYYjcdJdQHLCK9i25fLSYFc2VhFPuqXhuEhbNKTd2vm6cPfkwlVEPlhleaouCJ
wnZ9MFHZ07pgLMrTUT7HCRbQw3Q4liwa8JukfwED2DQYHAWVlU2Wjf4RoYvCy9nl
ugdUUYEXEVBbDfUL3c7gJHd1wzLEkBPDkFmYT19uh1JklTiblcs1H4Pz0xOgI106
sOrVKKC0QaA42qXfZbtQnE6D4NnrNpP9UBfENsAbRzqBGlWSwdJQSnZu3lOxFwiC
fWjI3pANZTSXLgyPeT5p9vwYs4A4Bh0x8RVK1WKFZ8u8Mp0PmZJck49oJmIZ7EVz
+LeaKlwD7mc7xSUYSi1rH6W3RdDi8cRXkMGFs4K506+bJENMO1BJ4SnAxZtLruZb
pUPsWxnvcxcPXjtpxBUYsdvdm3pZrgUN+kaigQ8r+PyzobW/N1UIIL+L/O5w4kSY
we+wai9M/77zJ5EIO92prGQD3huDnHzZaYG66nmmLAxKQ9ouvwGj7I6E1YH3NAqq
WeHzaRTQwLOUw++ZX1B11b2QcEdMLFILTOyDI+gp6emLm3GuZAW4dAf3cJzDUNuk
NP8QcjKVHRxVBkF/rNWg
=+CBA
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages