linux-kernel - Re: [Security] [PATCH] proc: avoid information leaks to non-privileged processes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <82prel54fo.fsf@mid.bfk.de>
Date:	Thu, 07 May 2009 17:16:27 +0200
From:	Florian Weimer <fweimer@....de>
To:	Matt Mackall <mpm@...enic.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Jake Edge <jake@....net>, security@...nel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	James Morris <jmorris@...ei.org>,
	linux-security-module@...r.kernel.org,
	Eric Paris <eparis@...hat.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Roland McGrath <roland@...hat.com>, mingo@...hat.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <greg@...ah.com>, Dave Jones <davej@...hat.com>
Subject: Re: [Security] [PATCH] proc: avoid information leaks to non-privileged processes

* Matt Mackall:

> On Wed, May 06, 2009 at 09:48:20AM -0700, Linus Torvalds wrote:
>> 
>> Matt, are you willing to ack my suggested patch which adds history to the 
>> mix? Did somebody test that? I have this memory of there being an 
>> "exploit" program to show the non-randomness of the values, but I can't 
>> recall details, and would really want to get a second opinion from 
>> somebody who cares about PRNG's.
>
> I still don't like it. I bounced it off some folks on the adversarial
> side of things and they didn't think it looked strong enough either.
> Full MD5 collisions can be generated about as fast as they can be
> checked, which makes _reduced strength_ MD4 not much better than an
> LFSR in terms of attack potential.

Well, with periodic reseeding, even that shouldn't be a problem.  You
don't need collision resistance at all, so those MD5 attacks don't
tell you anything about the difficulty of state recovery/prediction
attacks on your variant.  (The trouble with hash functions is that
they haven't got any secrets to work from.  With seeded PRNGs, this is
obviously different.)

On the other hand, most people who need a quick, unpredictable source
of randomness seem to use RC4 with a random key initialized from a
more costly source.  (If you're paranoid, you should discard the first
few hundred bytes.)  The nice thing is that you can use a well-tested
primitive, unchanged, so it's easier to avoid nasty suprises.

Oh, and you should really, really ditch that Tausworthe generator (in
lib/random32.c).

-- 
Florian Weimer                <fweimer@....de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/