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]

Date:	Mon, 4 May 2009 16:54:06 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
cc:	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>, Matt Mackall <mpm@...enic.com>
Subject: Re: [Security] [PATCH] proc: avoid information leaks to non-privileged
 processes

On Mon, 4 May 2009, Linus Torvalds wrote:
> 
> Quite frankly, the way "get_random_bytes()" works now (it does a _full_ 
> sha thing every time), I think it's insane overkill. But I do have to 
> admit that our current "get_random_int()" is insane _underkill_.

Actually, I don't think "get_random_int()" is underkill per se (it does 
that half md4 transform to try to hide the source of the data), but the 
data itself is simply not modified at all, and the buffers aren't updated 
in between rounds.

In fact "secure_ip_id()" (which it uses) explicityl does that private 
hash[] array so that the mixing that "half_md4_transform()" does do will 
_not_ be saved for the next round - so the next round will always start 
from the same keyptr "secret" state.

I think.

If that wasn't the case, and we actually kept mixing up the end result 
back into the next iteration, I suspect the current "get_random_int()" 
wouldn't be _nearly_ as bad as it is now. 

Or maybe I'm missing some part of the transform, and we do mix the values 
back as we do that "get_random_int()". I just don't see it. And if I'm 
right, then I think _that_ is the real weakness of our current 
get_random_int().

			Linus
--
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/