Problem Description:
When the arc4random(9) random number generator is
initialized, there may be inadequate entropy to meet the
needs of kernel systems which rely on arc4random(9); and it
may take up to 5 minutes before arc4random(9) is reseeded
with secure entropy from the Yarrow random number generator.
Impact:
All security-related kernel subsystems that rely on a
quality random number generator are subject to a wide range of
possible attacks for the 300 seconds after boot or until 64k
of random data is consumed. The list includes:
* GEOM ELI providers with onetime keys. When a provider is
configured in a way so that it gets attached at the same time
during boot (e.g. it uses the rc subsystem to initialize) it
might be possible for an attacker to recover the encrypted
data.
* GEOM shsec providers. The GEOM shsec subsytem is used to
split a shared secret between two providers so that it can be
recovered when both of them are present. This is done by
writing the random sequence to one of providers while
appending the result of the random sequence on the other host
to the original data. If the provider was created within the
first 300 seconds after booting, it might be possible for an
attacker to extract the original data with access to only one
of the two providers between which the secret data is split.
* System processes started early after boot may receive
predictable IDs.
* The 802.11 network stack uses arc4random(9) to generate
initial vectors (IV) for WEP encryption when operating in
client mode and WEP authentication challenges when operating
in hostap mode, which may be insecure.
* The IPv4, IPv6 and TCP/UDP protocol implementations rely
on a quality random number generator to produce unpredictable
IP packet identifiers, initial TCP sequence numbers and
outgoing port numbers. During the first 300 seconds after
booting, it may be easier for an attacker to execute IP
session hijacking, OS fingerprinting, idle scanning, or in
some cases DNS cache poisoning and blind TCP data injection
attacks.
* The kernel RPC code uses arc4random(9) to retrieve
transaction identifiers, which might make RPC clients
vulnerable to hijacking attacks.
Workaround:
No workaround is available for affected systems.