[Opendnssec-user] ods-signerd calling vmstat?!?

[Rickard Bellgrim]

>
> What I can do is to forward your concerns to the Botan mailing list. To
> discuss the usage of "ls -alni /tmp" as one of the low priority sources.
>

Here is the response from Jack Lloyd:

Well, there are two issues potentially involved - that a local attacker can
manipulate the input, and that a local attacker can see /tmp.

With regards to input manipulation - the PRNG design is explicitly intended
to process arbitrary attacker chosen inputs; as long as the min-entropy of
the entire set of sampled data is sufficiently high, there should not be a
problem. There is substantial justification for this in the paper on which
the RNG is designed (http://webee.technion.ac.il/~hugo/kdf/kdf.pdf). It is
worth considering that a local attacker can also manipulate inputs via
other approaches (process names in ps output, filenames in lsof and netstat
output, etc).

However in terms of entropy provided, keep in mind that for a local
attacker, Unix_EntropySource provides very little conditional entropy
anyway, as the entire point of it is that it is querying information which
is publically available to users of the local machine, and a local attacker
could easily sample the same set of sources. So the entropy gathered
(conditioned on the attackers knowledge of what he sampled, potentially at
a high resolution) would be quite small in any case.

The problem of gathering large amounts of entropy on a system without a
kernel provided/protected PRNG and a local attacker is not a satisfactorily
solved one to my knowledge. There is simply not that much variability to
sample from in that situation; the only approach I'm aware of that might
work is timing jitter ala truerand, which essentially is trying to sample
from the hidden states of clocks (drifting characteristics) and the
scheduler. I've done experiments with some approaches along this line in
the past, but not nearly enough to convince myself that it can be done in a
way that behaves securely, especially across a range of hardware and
kernels.

All that said, I am not particularly tied to ls /tmp as a source so if for
whatever reason this particular one is of great concern to your users it
can be removed without issue, but I hope I've made it clear how that is a
very small part of a larger issue surrounding entropy collection. Also, if
earlier polls (eg /dev/random or EGD) succeed, then we will never query
these sources at all, as spawning off all these processes is quite slow, so
we avoid it except in cases where it is necessary due to lack of other
options.
Hope this makes sense, let me know if you have any other questions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20130904/3f9aac4b/attachment.htm>