DnsLookup: Configurable dnsQueryId generation including random

Dns lookup logic has been updated to provide a configurable compile
time selection of dns query id generation logics, including random,
where possible, instead of the previous simple counter mode.

This should make dns poison attempts more difficult. The uclibc
developers wish to thank the white hat teams which alerted the
community about the possible weakness in the dns path, given the
increased resources with adversaries today.

Given that embedded systems may or may not have sources for trying
to generate random numbers, and also to try and keep the load on
the system low, by default it uses the standard random prng based
logic to indirectly generate the ids.

However if either urandom or else if realtime clock is available on
the target, then the same is used to reseed the prng periodically
in a slightly non deterministic manner. Also additional transform
(one way where possible) is used to avoid directly exposing the
internal random sequence.

The dns lookup logic maintains its own state wrt the random prng
functions, so that other users of the library's random prng are
not affected wrt their operations with the prng.

Note to Platform developers:

If you want to change from the default prngplus based logic, to one
of the other logics provided, then during compile/config time you can
switch to one of these additional choices wrt dns query id generation,
by using make config and companions.

If your platform doesnt support urandom nor a realtime clock backed
by a source with sufficient resolution, and or for some reason if you
want to revert to previous simple counter, rather than the transformed
random prng plus logic, you can force the same at compile time by
selecting SimpleCounter mode.

If you want to increase the randomness of the generated ids, and dont
mind the increased system load and latency then you could select the
Urandom mode during config. Do note that it will be dipping into the
entropy pool maintained by ur system.

If your target has a system realtime clock available and exposed to
user space, and inturn if you want to keep the underlying logic simple,
you could try using the clock option from the config. However do note
that the clock should have nanosecond resolution to help generate ids
which are plausibly random. Also improvements to processor and or io
performance can affect this.

Wrt the URandom and Clock modes, if there is a failure with generation
of the next random value, the logic tries to fallback to simple counter
mode.

If you want to change the underlying logic to make it more random
and or more simple, look at dnsrand_setup and dnsrand_next.

Signed-off-by: hanishkvc <hanishkvc@gmail.com>

1 files changed, 51 insertions, 0 deletions

diff --git a/extra/Configs/Config.in b/extra/Configs/Config.in
index a06a17864..a58ceb265 100644
--- a/extra/Configs/Config.in
+++ b/extra/Configs/Config.in
@@ -1344,6 +1344,57 @@ config UCLIBC_HAS_RESOLVER_SUPPORT
 	  ns_name_pack, ns_name_compress, ns_name_skip, dn_skipname,
 	  ns_get16, ns_get32, ns_put16, ns_put32
 
+choice
+	prompt "DNS Query ID generation"
+	default UCLIBC_DNSRAND_MODE_PRNGPLUS
+	help
+	  Control how successive dns query ids' are generated during
+	  dns lookup.
+
+config UCLIBC_DNSRAND_MODE_URANDOM
+	bool "urandom"
+	help
+	  "urandom" uses /dev/urandom available under many unix flavours
+	  to generate dns query id. This can generate good random ids,
+	  by dipping into the entropy pool maintained by the system.
+	  However this is relatively slow compared to the other options,
+	  as it may involve cryptographic operations internally and
+	  kernel-userspace handshake.
+
+config UCLIBC_DNSRAND_MODE_CLOCK
+	bool "clock"
+	depends on UCLIBC_HAS_REALTIME
+	help
+	  "clock" uses CLOCK_REALTIME of the system to generate plausibly
+	  random dns query id. Systems require to have clock source with
+	  nanosec granularity mapped to this clock id for this to generate
+	  plausibly random values. However has processor and io performances
+	  improve in future, its effectiveness can get impacted.
+
+config UCLIBC_DNSRAND_MODE_PRNGPLUS
+	bool "prngplus"
+	help
+	  "prngplus" uses random prng available within uclibc, to indirectly
+	  generate the dns query id. This tries to provide a good balance
+	  between speed and randomness to an extent. It periodically reseeds
+	  the prng using random value generated from either the urandom or
+	  else the clock, if either of them is available. Additionally applies
+	  transform (one way, if possible) on internal generated random values.
+	  These make it difficult to infer internal state of prng from unbroken
+	  sequences of exposed random values.
+	  This is the default.
+
+config UCLIBC_DNSRAND_MODE_SIMPLECOUNTER
+	bool "simplecounter"
+	help
+	  "simplecounter" uses a simple counter to generate dns query id.
+	  This is a very simple logic and can be subjected to dns poison
+	  attack relatively easily.
+	  It is recommended to avoid this option.
+
+endchoice
+
+
 endif