Security-Announce archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Updated NetBSD Security Advisory 2013-003: RNG Bug May Result in Weak Cryptographic Keys



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

                 NetBSD Security Advisory 2013-003
                 =================================

Topic:          RNG Bug May Result in Weak Cryptographic Keys

Version:        NetBSD-current:         affected prior to Jan 26th, 2013
                NetBSD 6.0.*:           affected
                NetBSD 6.0:             affected
                NetBSD 5.2.*:           not affected
                NetBSD 5.1.*:           not affected

Severity:       Cryptography Weakness

Fixed:          NetBSD-current:         Jan 26th, 2013
                NetBSD-6-0 branch:      Jan 26th, 2013
                NetBSD-6 branch:        Jan 26th, 2013

NetBSD 6.1 will contain the fix.

Please note that NetBSD releases prior to 5.1 are no longer supported.
It is recommended that all users upgrade to a supported release.


Abstract
========

Due to a programming error, pseudorandom numbers supplied with a warning
of "insufficient entropy at creation" may only contain sizeof(int) bits
of cryptographic randomness.


Technical Details
=================

When the kernel boots, it creates several instances of the kernel
random number generator very early.  Additional random number
generator instances may be created relatively early by, for example,
the sshd script generating keys when it first runs.

Because generators created very early may be keyed when the system
has very little entropy available, the system rekeys those generators
as soon as a "minimum entropy" threshold is passed, where the entropy
collection pool has enough bits to provide bits which are random in the
cryptographic sense: computationally infeasible to distinguish from
actual random noise.

However, internally, the pool has an "entropy estimator" which counts
how many bits have ever been put into the pool, for entropy consumers
who care about information-theoretic randomness rather than cryptographic
randomness.  If a consumer asks for "GOOD" bits rather than "ANY" bits,
the consumer will get only entropy-estimate worth of bits -- no more.

The code for keying the stream generators which actually supply bits to
kernel and user consumers requests GOOD bits and then, if it does not
get as many as it wanted, and the user has indicated that cryptographic
randomness is sufficient (for example, by opening /dev/urandom rather
than /dev/random) requests ANY bits for the remainder.

Due to a misplaced parenthesis, if insufficient GOOD bits were available
to satisfy a request, the keying/rekeying code requested either 32 or 64
ANY bits, rather than the balance of bits required to key the stream
generator.

The result of this bug is that even after the minimum entropy
threshold was reached, the generators for in-kernel and userspace
consumers could in the worst case be keyed, or re-keyed, with as few
as 32 bits (on 32 bit platforms) or 64 bits (on 64 bit platforms) of
data, plus a 32-bit cycle counter value, plus the name of the generator
(an LWP ID for userspace, a fixed string for kernel consumers),
plus stack noise for the remainder.

Systems which never experience an "insufficient entropy" condition
(for example, systems with hardware random number generators supported
by NetBSD) are not impacted by this bug.

All cryptographic keys generated on NetBSD 6 or NetBSD-current (prior to
2013-01-27) systems should be regenerated, unless it is certain that
the system in question cannot have suffered a low-entropy condition
when the keys were generated.

In particular, since ECDSA ssh host keys are new in NetBSD 6 and
are generated by /etc/rc.d/sshd at system boot if not yet present, it
is likely that for systems that have been updated to NetBSD 6.0 or a
netbsd-6 branch kernel before the fix date, ECDSA host keys have being
considerably weakened by lack of actual randomness, especially since
with little system uptime stack contents will be more predictable than
later.

For systems newly set up with NetBSD 6, all ssh host keys are suspect.

Other persistent cryptographic secrets (for example, SSH or SSL keys of
any type) generated using /dev/urandom on NetBSD 6 systems which may have
had insufficient entropy at key generation time may be impacted and should
be regenerated.


Solutions and Workarounds
=========================

Workaround:

Don't generate cryptographic keys, and don't use random numbers for
critical applications, on NetBSD 6 or NetBSD-current systems prior
to 2013-01-27, unless the system has sufficient "GOOD" entropy.  In
practice, this means reading from /dev/random rather than /dev/urandom
when using system entropy to generate cryptographic keys.

Fix:

Install a kernel containing the fix.

The fastest way to do that, if you are running or can run a standard kernel
built as part of the NetBSD release process, is to obtain the corresponding
kernel from the daily NetBSD autobuild output and install it on your system.

You can obtain such kernels from http://nyftp.netbsd.org/pub/NetBSD-daily/
where they are sorted by NetBSD branch, date, and architecture.  To fix
a system running NetBSD 6.0 or the stable NetBSD 6.0 branch, the
most appropriate kernel will be the "netbsd-6-0" kernel.  The "netbsd-6"
kernel can also be used; this is the branch that will become NetBSD 6.1.
To fix a system running NetBSD-current, the "HEAD" kernel should be used.
In all cases, a kernel from an autobuild dated 20130127 or newer must be
used to fix the problem.

If you cannot use the autobuilt kernels, then for all affected NetBSD
versions, you need to obtain fixed kernel sources, rebuild and install
the new kernel, and reboot the system.

The fixed source may be obtained from the NetBSD CVS repository.
The following instructions briefly summarise how to upgrade your
kernel.  In these instructions, replace:

  ARCH        with your architecture (from uname -m), and
  KERNCONF    with the name of your kernel configuration file.
  NEWVERSION  with the CVS version of the fix

Versions of src/sys/kern/subr_cprng.c:
        Branch          NEWVERSION
        ---------------------------
        HEAD            1.15
        netbsd-6        1.5.2.7
        netbsd-6-0      1.5.2.3.4.1

To update from CVS, re-build, and re-install the kernel:

        # cd src
        # cvs update -rNEWVERSION sys/kern/subr_cprng.c
        # ./build.sh kernel=KERNCONF
        # mv /netbsd /netbsd.old
        # cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd 
        # shutdown -r now

For more information on how to do this, see:

   http://www.NetBSD.org/guide/en/chap-kernel.html


Thanks To
=========

Thor Lancelot Simon for causing, finding and fixing the bug and
helping with this advisory.


Revision History
================

        2013-02-26      Initial release
        2013-03-07      Title change; stronger cautionary text; fix improved.


More Information
================

Advisories may be updated as new information becomes available.
The most recent version of this advisory (PGP signed) can be found at 
  http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2013-003.txt.asc

Information about NetBSD and NetBSD security can be found at
http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ .

Copyright 2013, The NetBSD Foundation, Inc.  All Rights Reserved.
Redistribution permitted only in full, unmodified form.

$NetBSD: NetBSD-SA2013-003.txt,v 1.3 2013/03/07 09:49:07 tonnerre Exp $
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (NetBSD)

iQIcBAEBAgAGBQJROHDUAAoJEAZJc6xMSnBu1UMQALknWo5yifg477W84ToMiiB3
avDjLtcJB3cn4M6QycbNkfas1kaA6Qklj1FExIAh4yYRm8WBppRypjTJTkg8qmEE
s3vhhXpN52lziJ8xjWtUT5NH5N2epkl/odxmSlZ5ae4FBQD7NRVltIJwWelTyOAq
oJDtbWlHEBPaHEq3ftKzRBbkcxS/ZVbYfYjP9v4R6LlXhaK+3rZQ2XuTae7cbAX6
SA3EK3t0RR2AJt3qrRi2YD+26irdx6RTzHh+CoDdXhCzvj+nlrV+ha/xBPNdcqGR
CwjPDuCeEuevDd3QH6VPC85YViJZ1YL0wqhElJToAVZcwQ5Se7RSk6xDXl4NPWta
sSvxcKjpZoj2rcNSZd0kMZULM/a4UbDMbkn5gF3t6Vjqk4KmDcJl3pbMBN4A3/6L
ah8frE1h33RWiyN5ExoZtkffjkMiQ9qr7elTvHciEVSXW00h+ghRda7oMGE8mUi4
dY7Pxw4kTczDkYXVu0FjQVT2R/4oxowAC7qKbDE02FhA5qoSdT9DLWHlxyyDAyno
DD+HLsvxMqEVx8q9NVqHPQIF9qdDeQZd5vED1qZ1MvVir89hjNgoWUA05x/vAvsG
vrxgzpAsphR4j7OYQmDekepsANyVUmHHh676wl/DhzNDzAsr+jsmrFEnKz0KXmRN
Np4EdRSr8Th68ygfgMVT
=28sX
-----END PGP SIGNATURE-----


Home | Main Index | Thread Index | Old Index