Date:	Fri, 18 Nov 2011 17:10:37 -0500
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Pekka Enberg <penberg@...nel.org>
Cc:	Cyrill Gorcunov <gorcunov@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Glauber Costa <glommer@...allels.com>,
	Andi Kleen <andi@...stfloor.org>, Tejun Heo <tj@...nel.org>,
	Matt Helsley <matthltc@...ibm.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Vasiliy Kulikov <segoon@...nwall.com>
Subject: Re: [PATCH v2 0/4] Checkpoint/Restore: Show in proc IDs of objects
 that can be shared between tasks

On Fri, Nov 18, 2011 at 16:09, Pekka Enberg <penberg@...nel.org> wrote:
> On Fri, Nov 18, 2011 at 11:03 PM, Cyrill Gorcunov <gorcunov@...il.com> wrote:
>>> Of course.  But
>>>
>>> a) I'm not sure that this scheme actually protects the kernel
>>>    addresses - there may be way in which cunning userspace can work out
>>>    the random mask.
>>
>> Well, in case of hw-rng it should not be that easy, still of course
>> there is no 100% guarantee that there is absolutely no way to predict
>> this mask (espec since it's generated once at lives here forever). But
>> whatever makes attacker life harder -- is a good thing. After all we might
>> simply take some hash on kernel address here (such as sha256) since it's
>> not a time-critical operation and as far as I know collision is not found
>> for it yet (??).
>
> XOR cipher is very easy to crack with frequency analysis. I'd also
> consider using SHA256 or similar hash for this.

Some of the bits you don't even need to guess.  On 32-bit PPC, for
example, all kernel addresses have the top two bits set (0xC0000000 -
0xFFFFFFFF) and some of that space is reserved for virtual maps and
kernel code.  Additionally, all your significant datastructures are
probably allocated with kmalloc() and have 16-byte alignment or more,
so you only have maybe 24 or 25 bits (out of 32) with relevant
randomness.

Even then I'm sure you can brute-force that primitive XOR masking
pretty easily.  Just use memory pressure to get some large contiguous
chunks of free memory and then create lots of the relevant
datastructures... which will occur in linearly ascending order!
Examine the values from each "cookie" after large numbers of
allocations, if the highest bit to change was bit 20 and almost all of
the bits underneath it flip at the same time, then you know the real
value of bit X just changed from a 0 to a 1, so you know what the XOR
value for that bit is.

The #1 rule of one-time pads is never use it for more than one thing,
and you use it here for every object in the system.

If you actually want to be able to compare uniqueness without exposing
anything vulnerable to various kinds of guessing, you should generate
a random 64-bit value for each class of object and then use a proper
cryptographic hash function on it:
  crypto_hash(concat(object_ptr, random_value))

Even given the best possible practical attacks against SHA1 or MD5
today both still provides more than enough security to prevent someone
from guessing "object_ptr" in less than an absurd amount of time.

Cheers,
Kyle Moffett

-- 
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
--
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/

Powered by blists - more mailing lists