Identifying Systemic Threats to Kernel Data - Advanced Operating Systems and Kernel Applications - page 53

Figure 5. The Linux Random Number Generator

this attack is to degrade the quality of the pseudo
random numbers that are generated by the PRNG.
The kernel depends on the PRNG to supply good
quality pseudo random numbers, which are used
by all security functions in the kernel as well as
by applications for key generation, generating
secure session id's, etc.All applications and kernel
functions that depend on the PRNG are in turn
open to attack.
Background: The PRNG provides two inter-
faces to user applications namely /dev/random and
/dev/urandom as shown in Figure 5. The PRNG
depends on three pools for its entropy require-
ments: the primary pool, the secondary pool and
the urandom pool. The /dev/random is a blocking
interface and is used for very secure applications.
The device maintains an entropy count and blocks
if there is insufficient entropy available. Entropy is
added to the primary pool from external events such
as keystrokes, mouse movements, disk activity
and network activity. When a request is made for
random bytes, bytes are moved from the primary
pool to the secondary and the urandom pools. The
/dev/urandom interface on the other hand is non-
blocking. The contents of the pool are stirred when
the bytes are extracted from the pools. A detailed
analysis of the Linux random number generator
is available in (Gutterman, 2006).
Attack Description: This attack constantly
contaminates the entropy pool by writing zeroes

into all the pools. This is done by loading an attack
module that consists of a kernel thread. The thread
constantly wakes up and writes zeroes into the en-
tropy pools. It also attacks the polynomials that are
used to stir the pool. Zeroing out these polynomials
nullifies a part of the extraction algorithm used
by the PRNG. The location of the entropy pool
is not exported by the Linux kernel. We can find
the location by simply scanning kernel memory.
Entropy pool has the cryptographic property of
being completely random (Shamir, 1999). Since
we know the size of the entropy pools, this can be
found by running a sliding window of the same
sizes through memory and calculating the entropy
of the data within the window. Kernel code and
data regions are more ordered than the entropy
pools and have a lower entropy value. The pool
locations can therefore be successfully located.
We measured the quality of the random num-
bers generated by using the diehard battery of tests
(Marsaglia, 1996). The results are summarized
in Table 3. Diehard is the suite of tests used to
measure the quality of random numbers generated.
Any test that generates a value extremely close to
0 or 1 represents a failing sequence. More about
the details of these tests can be found in (Mar-
saglia, 1996). We run the tests over ten different
10MB files that were generated by reading from
the /dev/random device. The table shows that
the sequence that is generated after attack, fails