Bug #1924

mmap - add mmap offset randomisation

Added by robin.carey1 over 3 years ago. Updated over 3 years ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Dear DragonFlyBSD bugs,

Alex Hornung recently (today ?) added mmap randomisation (security feature),
but in his commit he uses:

karc4random()

When he should really be using the superior kernel random number generator
presented to userland via

/dev/random

and

/dev/urandom

There are other portions of Kernel code which needs to do the same, e.g. I
think OpenBSDs PF Packet
Filter uses karc4random() ....

unnamed (656 Bytes) robin.carey1, 11/25/2010 04:12 PM

unnamed (2.11 KB) robin.carey1, 11/25/2010 05:30 PM

unnamed (6.49 KB) robin.carey1, 11/25/2010 05:36 PM

unnamed (1.58 KB) robin.carey1, 11/26/2010 08:56 AM

History

#1 Updated by alexh over 3 years ago

Care to explain the reasoning behind that a bit more? Why is karc4random()
worse? What are the exact benefit of using the other interface?

I thought karc4random also takes advantage of randomness fed in from devices,
etc.

Cheers,
Alex

#2 Updated by alexh over 3 years ago

After a short check it uses exactly the same interface to get the 'randomness'
(entropy?), read_random_unlimited().

So what exactly do you mean? And why is karc4random no good?

Cheers,
Alex

#3 Updated by robin.carey1 over 3 years ago

Hi,

Last time I checked karc4random() was an in-kernel ARC4 CSPRNG/random number
generator.

Maybe since the last time I checked, someone has ripped that out and
replaced it with a call to the superior
IBAA/L15 in-kernel CSPRNG/random number generator.

I would have to check the sources to find out if that is the case or not;
I'll do it after I finish this reply.

--

To answer your question: ARC4/RC4 is a poor quality CSPRNG/random number
generator, i.e. it is
bad in a number of different ways.

Whereas, the in-kernel IBAA/L15 CSPRNG random numberr generator is vastly
superior in a number of
different ways.

That's why it is better to use it, rather than ARC4/RC4 (karc4random()).

Hope that answers your question.

On 25 November 2010 16:30, Alex Hornung (via DragonFly issue tracker) <
> wrote:

>
> Alex Hornung <> added the comment:
>
> Care to explain the reasoning behind that a bit more? Why is karc4random()
> worse? What are the exact benefit of using the other interface?
>
> I thought karc4random also takes advantage of randomness fed in from
> devices,
> etc.
>
> Cheers,
> Alex
>
> ----------
> status: unread -> chatting
>
> _____________________________________________________
> DragonFly issue tracker <>
> <http://bugs.dragonflybsd.org/issue1924>
> _____________________________________________________
>

#4 Updated by robin.carey1 over 3 years ago

Dear Alex and bugs,

I just checked the source tree, and karc4random() does not use
read_random_unlimited().

Well, it does not use it directly ... I see a call to it elsewhere in:

/sys/libkern/arc4random.c

I sent a post into a while back and I think it was
Matthew Dillon who replied
stating that there are numerous references to e.g. karc4random() strewn
about all over the source tree,
and it would be a good idea to update those references to use the superior
CSPRNG in:

/sys/kern/kern_nrandom.c

But it seems nobody has bothered to do that.

I'm just sending this bug report in, because the mmap randomisation is a new
commit, i.e. it is new
code, and since it is new code it should be using the best CSPRNG available
and not the old references
to karc4random().

Here is the relevant source snippet:

u_int32_t
116<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l116&gt;karc4random(void)
117<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l117&gt;{
118<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l118>
u_int32_t ret;
119<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l119>
struct timeval tv_now;
120<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l120>
121<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l121>
/* Initialize array if needed. */
122<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l122>
if (!arc4_initialized)
123<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l123>
arc4_init();
124<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l124>
125<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l125>
getmicrotime(&tv_now);
126<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l126>
if ((++arc4_numruns > ARC4_MAXRUNS) ||
127<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l127>
(tv_now.tv_sec > arc4_tv_nextreseed.tv_sec))
128<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l128>
{
129<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l129>
arc4_randomstir();
130<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l130>
}
131<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l131>
132<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l132>
ret = arc4_randbyte();
133<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l133>
ret |= arc4_randbyte() << 8;
134<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l134>
ret |= arc4_randbyte() << 16;
135<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l135>
ret |= arc4_randbyte() << 24;
136<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l136>
137<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l137>
return ret;
138<http://gitweb.dragonflybsd.org/dragonfly.git/blob/master:/sys/libkern/arc4random.c#l138&gt;}

On 25 November 2010 16:32, Alex Hornung (via DragonFly issue tracker) <
> wrote:

>
> Alex Hornung <> added the comment:
>
> After a short check it uses exactly the same interface to get the
> 'randomness'
> (entropy?), read_random_unlimited().
>
> So what exactly do you mean? And why is karc4random no good?
>
> Cheers,
> Alex
>
> _____________________________________________________
> DragonFly issue tracker <>
> <http://bugs.dragonflybsd.org/issue1924>
> _____________________________________________________
>

#5 Updated by alexh over 3 years ago

Well, karc4random calls arc4_randomstir(), which calls read_random_unlimited(),
so it *is* using the same entropy as /dev/random and /dev/urandom.

I'm not sure I understand your point considering the above. I don't think
reading directly from read_random_unlimited() on each and every karc4random()
call is a good idea at all. This way it gets called every few times, it seems,
which should be good enough (?)

Cheers,
Alex

#6 Updated by dillon over 3 years ago

One thing we could do... something I've actually wanted to do for a
while, is to create separate randomization domains and give the
kernel its own personal generator that userland never touches.

Maybe even also give each jail its own random number generator too,
though that would be extra.

-Matt

#7 Updated by robin.carey1 over 3 years ago

Hi Matt,

I thought you were ignoring me !

If you choose to do that, I hope you use L15 and the customised (counter +
bit-shift changes) IBAA
you have in the tree at the moment ...

On 25 November 2010 20:16, Matthew Dillon (via DragonFly issue tracker) <
> wrote:

>
> Matthew Dillon <> added the comment:
>
> One thing we could do... something I've actually wanted to do for a
> while, is to create separate randomization domains and give the
> kernel its own personal generator that userland never touches.
>
> Maybe even also give each jail its own random number generator too,
> though that would be extra.
>
> -Matt
>
> _____________________________________________________
> DragonFly issue tracker <>
> <http://bugs.dragonflybsd.org/issue1924>
> _____________________________________________________
>

Also available in: Atom PDF