Abstract

When a cgd(4) pseudo-device is unconfigured, the driver does not clear
memory containing key material before freeing it back to other kernel
use. A process may later allocate kernel memory and receive chunks
with data previously used by the cgd driver which may contain
encryption keys.

Technical Details

The cgd(4) pseudo-device provides an encrypted virtual disk, layered
on top of other disk device drivers. The encryption is done in
software, with cryptographic keys configured and supplied to the
kernel via the cgdconfig(8) program, and stored in the kernel for the
lifetime of the pseudo-device.

With any such software-based encryption scheme, there is a risk of key
disclosure via examination of kernel memory. This is inherent in the
need for the kernel to perform cryptographic operations, and
unavoidable while the disk must be accessible to user processes.

A cgd(4) device can be unconfigured, which removes the in-kernel
configuration structures and prevents any further access to the
decrypted contents of the disk via the cgd(4) driver until the key is
re-entered. However, the structures containing key material were
freed back to the kernel memory pool without having their contents
erased first. It was therefore possible that key material could still
be present in kernel memory after the user expected it to be
destroyed.

Any mechanism that allows kernel memory disclosure poses potential
security risks, and care is always taken to avoid disclosing previous
memory contents when allocating memory in the kernel and communicating
with userland; it is therefore considered unlikely that this problem
would expose stale key material to any attacker not otherwise able to
read kernel memory.

The potential exposure lies in the user expectation that the keys are
destroyed; they may therefore take steps at this time which they might
otherwise avoid while key material is live in the kernel, and which
may increase the risk of key disclosure. The most significant risk
lies in the use of BIOS suspend-to-disk mechanisms, which write out
the contents of all physical memory to disk - potentially including
uncleared cgd(4) key material.

Note that the use of such suspend-to-disk mechanisms with cgd(4)
devices is heavily discouraged for these reasons; even when the device
has been unconfigured and the key destroyed, decrypted copies of
sensitive information from the disk may remain in physical memory
pages from unrecycled kernel buffers or user applications.

The cgd(4) driver appeared in NetBSD-current prior to the 2.0 release;
this issue does not affect the NetBSD 1.6 releases or earlier.

Solutions and Workarounds

There is no workaround to this problem. The fix requires a new kernel
to be built and installed.

The following instructions describe how to upgrade your cgd driver
by updating your source tree and rebuilding and installing a new version
of the kernel.

* NetBSD-current:

Systems running NetBSD-current dated from before 2005-03-19
should be upgraded to NetBSD-current dated 2005-03-20 or later.

The following directories need to be updated from the
netbsd-current CVS branch (aka HEAD):
sys/dev/cgd_crypto.c

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

# cd src
# cvs update -d -P sys/dev/cgd_crypto.c
# ./build.sh kernel=GENERIC
# mv /netbsd /netbsd.old
# cp sys/arch/`machine`/compile/obj/GENERIC/netbsd /netbsd
# shutdown -r now

* NetBSD 2.0 (and subsequent point releases):

The binary distribution of NetBSD 2.0 (and subsequent point
releases) is vulnerable.

NetBSD 2.1 includes the fix.

Systems running NetBSD 2.0 (and subsequent point releases) built
from sources dated before 2005-03-20 should be upgraded from
sources dated 2005-03-21 or later.

The following directories need to be updated from CVS:
sys/dev/cgd_crypto.c

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

# cd src
# cvs update -d -P sys/dev/cgd_crypto.c
# ./build.sh kernel=GENERIC
# mv /netbsd /netbsd.old
# cp sys/arch/`machine`/compile/obj/GENERIC/netbsd /netbsd
# shutdown -r now

Thanks To

Daniel Carosone for reporting and fixing this vulnerability.

Revision History

2005-10-31 Initial release

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

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

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