FreeBSD Errata Notices
2014-Jan-14 20:11 UTC
[FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:01.random
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
============================================================================FreeBSD-EN-14:01.random
Errata Notice
The FreeBSD Project
Topic: /dev/random should not make direct usage of hardware RNG
Category: core
Module: random
Announced: 2014-01-14
Affects: All versions of FreeBSD prior to 10.0-BETA1
Corrected: 2014-01-14 19:27:42 UTC (stable/9, 9.2-STABLE)
2014-01-14 19:42:28 UTC (releng/9.2, 9.2-RELEASE-p3)
2014-01-14 19:42:28 UTC (releng/9.1, 9.1-RELEASE-p10)
2014-01-14 19:27:42 UTC (stable/8, 8.4-STABLE)
2014-01-14 19:42:28 UTC (releng/8.4, 8.4-RELEASE-p7)
2014-01-14 19:42:28 UTC (releng/8.3, 8.3-RELEASE-p14)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.freebsd.org/>.
I. Background
The random(4) and urandom(4) devices return an endless supply of pseudo-random
bytes when read. Cryptographic algorithms often depend on the secrecy of these
pseudo-random values for security.
Yarrow is a secure pseudo-random number generator that combines entropy from
several entropy sources, mitigating a possible attack when someone could
predict the output when they are able to intercept one or more of the
entropy sources
II. Problem Description
When a hardware RNG exists, the FreeBSD random(4) and urandom(4) devices
would use their output directly.
III. Impact
Someone who has control over these hardware RNGs would be able to
predicate the output from random(4) and urandom(4) devices and may be able
to reveal unique keys that are used to encrypt data.
IV. Workaround
Disable the hardware RNGs by adding the following settings to /boot/loader.conf
and reboot the system:
hw.nehemiah_rng_enable=0
hw.ivy_rng_enable=0
V. Solution
Hardware RNGs would be disabled by default with this errata notice. They
can be re-enabled by setting the corresponding loader tunables to non-zero
value.
Perform one of the following:
1) Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date.
2) To update your present system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 9.2 and 8.4]
# fetch http://security.FreeBSD.org/patches/EN-14:01/random-9.2-8.4.patch
# fetch http://security.FreeBSD.org/patches/EN-14:01/random-9.2-8.4.patch.asc
# gpg --verify random-9.2-8.4.patch.asc
[FreeBSD 9.1]
# fetch http://security.FreeBSD.org/patches/EN-14:01/random-9.1.patch
# fetch http://security.FreeBSD.org/patches/EN-14:01/random-9.1.patch.asc
# gpg --verify random-9.1.patch.asc
[FreeBSD 8.3]
# fetch http://security.FreeBSD.org/patches/EN-14:01/random-8.3.patch
# fetch http://security.FreeBSD.org/patches/EN-14:01/random-8.3.patch.asc
# gpg --verify random-8.3.patch.asc
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.
3) To update your system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch/path Revision
- -------------------------------------------------------------------------
stable/8/ r260644
releng/8.3/ r260647
releng/8.4/ r260647
stable/9/ r260644
releng/9.1/ r260647
releng/9.2/ r260647
- -------------------------------------------------------------------------
VII. References
The latest revision of this Errata Notice is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-14:01.random.asc
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJS1ZSoAAoJEO1n7NZdz2rnZcgP/3ITOg59t4PmOg2vUrlMsf35
jVDZojqeu+XgDepYi37HJVB6pHSWusYoI59YP6O2N1n15W34Bp91Vcthofyr+jgx
7Guz+DXOqZy1yxGMSGkAl0hIrksszqp5kAADy4f1NMkFmvc2+8dXW1xmxYpDHrkG
d/alEeK0LuFgWXYnnrea3x/aWqEVVR+/YhCbk8FTD01Q4zqtfacIDfNL+gLf4Mhx
gNO1HSHmvS4GEF1gawtHzY4i6rGX9e4LgxKSEKSMUXfl1WUfnD5f62z9FB1UN1Js
EfVniP2ZN2ojAzoVWfiX5WDhpMA/KZpdTSLF+zOM1/Tr+7+N7WTYftL6nHy/HSj8
LmsIZnSE4F7F2hFlZu7PPwGzaIj/rYk5tRzw3nTIoIwVoLbvbevzCrl0rIocq2CK
Sm5WV2qvMuWB+ZK2ZuzCIxAj6/fuLbUIBHmHd2VFfxWXcSwoK/cW3pFPMDyHKtJJ
ccocT7kXeHHtnSqzvSN1j1XFZsWdojbYU7HSU8QmiilG3ESvgrzZAKh7V+hC/aF/
TE0Xhaip8X/sOt1NnjHGs8XzA3w7wUukssz2V7gRdarSS7c/+mU23pajLknQ4eiB
l3g8z/iX4jPuL8e0sn9GUCXVtTZIXWGl9hSilWeYk6tEihhlf/gVhY6ldCwSoZjr
U6gPf7bQn/NzE7wSUaQD
=viar
-----END PGP SIGNATURE-----
Darren Pilgrim
2014-Jan-15 17:04 UTC
[FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:01.random
On 1/14/2014 12:11 PM, FreeBSD Errata Notices wrote:> III. Impact > > Someone who has control over these hardware RNGs would be able to > predicate the output from random(4) and urandom(4) devices and may be able > to reveal unique keys that are used to encrypt data.This is good to know, but I have to wonder: If the attacker has that level of access to the hardware, I would expect one of two things is also true: 1. If you're on "bare metal", the attacker has firmware-level or physical access to the machine; 2. If you're on a hypervisor, you can't trust the hypervisor; In both cases, I would think the attacker can use much simpler, more direct vectors and you have much worse things to worry about than the quality of /dev/random. I'm not questioning the validity of the advisory, I'm genuinely curious about this. I can't think of a scenario were someone could attack /dev/random using this vector without 1 or 2 above also being true.