[lkml]   [2009]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Security] [PATCH] proc: avoid information leaks to non-privileged processes

* Eric W. Biederman <> wrote:

> Ingo Molnar <> writes:
> > * Matt Mackall <> wrote:
> >
> >> As to what's the appropriate sort of RNG for ASLR to use, finding
> >> a balance between too strong and too weak is tricky. [...]
> >
> > In exec-shield i mixed 'easily accessible and fast' semi-random
> > state to the get_random_int() result: xor-ed the cycle counter, the
> > pid and a kernel address to it. That strengthened the result in a
> > pretty practical way (without strengthening the theoretical
> > randomless - each of those items are considered guessable) and does
> > so without weakening the entropy of the random pool.
> The trouble is, that thinking completely misses the problem, and I
> expect that is why we have a problem. Throwing a bunch of
> possibly truly random values into the pot for luck is nice. But
> you didn't throw in a pseudo random number generator. An
> unpredictable sequence that is guaranteed to change from one
> invocation to the next.

Alas, i did - it got 'reviewed' out of existence ;)

I still have the backups, here's the original exec-shield RNG:

+ * Get a random word:
+ */
+static inline unsigned int get_random_int(void)
+ unsigned int val = 0;
+ if (!exec_shield_randomize)
+ return 0;
+#ifdef CONFIG_X86_HAS_TSC
+ rdtscl(val);
+ val += current->pid + jiffies + (int)&val;
+ /*
+ * Use IP's RNG. It suits our purpose perfectly: it re-keys itself
+ * every second, from the entropy pool (and thus creates a limited
+ * drain on it), and uses halfMD4Transform within the second. We
+ * also spice it with the TSC (if available), jiffies, PID and the
+ * stack address:
+ */
+ return secure_ip_id(val);

I thought that basing it on the networking PRNG is proper design:
the networking folks have showed it time and again that they care
about the PRNG not being brute-forceable easily, while still staying
fast enough.

I added the TSC and a few other pseudo-random details to increase
complexity of any brute-force attack. (in the hope of rendering it
less practical, at minimal cost)

> In a very practical sense a pseudo random generator is completely
> sufficient. Throwing in a few truly random numbers guards against
> attacks on the random number generator.
> What we have now is a hash over an a value that changes every 5
> minutes and some well known values.



 \ /
  Last update: 2009-05-05 21:59    [W:0.089 / U:3.720 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site