Bug #514

patch to randomize mmap offsets

Added by kevin.kane over 7 years ago. Updated over 3 years ago.

Status:ClosedStart date:
Priority:LowDue date:
Assignee:corecode% Done:

0%

Category:-
Target version:-

Description

I pulled this little patch from OpenBSD to randomize mmap offsets as
per request on projects page, described by
http://www.openbsd.org/papers/auug04/index.html

-Kevink

random-mmap.patch Magnifier (4.16 KB) kevin.kane, 01/14/2007 08:15 PM

History

#1 Updated by dillon over 7 years ago

:I pulled this little patch from OpenBSD to randomize mmap offsets as
:per request on projects page, described by
:http://www.openbsd.org/papers/auug04/index.html
:
:-Kevink
:
:--
:Kevin L. Kane
:kevin.kane at gmail.com

hmm. I'm not a big fan of OpenBSD's randomization code. I'm not
rabidly against the patch but it is a bit hackish. It seems to me
that somthing similar could be implemented simply by having the RTLD
or LIBC code mmap() a randomly sized dead segment, and not have to
build anything into the kernel.

-Matt

#2 Updated by kevin.kane over 7 years ago

Wouldn't that result in 2x the syscalls for calling mmap()?(isn't this
expensive?) Or do I not understand what you mean?

-Kevink

#3 Updated by dillon over 7 years ago

:> hmm. I'm not a big fan of OpenBSD's randomization code. I'm not
:> rabidly against the patch but it is a bit hackish. It seems to me
:> that somthing similar could be implemented simply by having the RTLD
:> or LIBC code mmap() a randomly sized dead segment, and not have to
:> build anything into the kernel.
:
:Wouldn't that result in 2x the syscalls for calling mmap()?(isn't this
:expensive?) Or do I not understand what you mean?
:
:-Kevink
:
:--
:Kevin L. Kane

You could just request more space then you need and randomly offset
the allocations you do from within that space. That has the same
result pretty much.

Or you could just make a few randomly-sized mmap() calls at the start
of the program but not on every mmap. The first few calls will offset
the address returned by all later calls.

Similarly you can create a random stack offset by allocating a random
amount of space on the stack at program start. There is no need to
have the kernel do it for you when you can do it yourself (libc, that is).

-Matt

#4 Updated by corecode over 7 years ago

well, that's quite different. randomizing mmap offsets gives a real random distribution over the whole userland address space. allocating more and then offsetting within this allocation still gives a deterministic order of allocated memory locations, just the padding between those varies.

cheers
simon

#5 Updated by dillon over 7 years ago

:well, that's quite different. randomizing mmap offsets gives a real random distribution over the whole userland address space. allocating more and then offsetting within this allocation still gives a deterministic order of allocated memory locations, just the padding between those varies.
:
:cheers
: simon

Randomizing mmap offsets that much will fragment user virtual memory
and cause the program to run out of space if it uses mmap() heavily.
I really dislike the concept.

-Matt

#6 Updated by kevin.kane over 7 years ago

I have to agree with Simon, doing as you suggest will reduce the
effectiveness of the concept(maybe to the point where its not worth
doing at all?) Obviously we shouldn't be wasteful but the benefit of
random distrobution here outweighs the memory costs.

-Kevink

#7 Updated by TGEN over 7 years ago

Given other comments, I think you should put all the changed code under
an #ifdef, and add that to conf/options to be defined in file opt_vm.h
(e.g., VM_MMAPOFF_RANDOMIZE opt_vm.h), then include opt_vm.h in the
relevant files. Ofcourse, the option wouldn't be enabled by default, but
people who want security through obscurity can easily enable it at their
leasure in their kernel config, and recompile :).

Cheers,
--
Thomas E. Spanjaard

#8 Updated by corecode over 7 years ago

it is not obscurity, but instead prevents the exploitation of any fixed memory offset in executables. it makes memory ordering basically so non-deterministic that it is close to impossible to craft a working exploit. in combination with W^X this creates a very very secure execution environment.

cheers
simon

#9 Updated by TGEN over 7 years ago

No matter how close-to-impossible it is to craft a working exploit,
technically it is still obcurity. Ofcourse I do agree with you that
given a large enough address space, this is a very powerful tool to
deter attackers (imagine groveling a 64bit virtual address space for the
hole you're looking for, I'll prefer to do other things with my time;
also, it's quite possible to construct an IDS which catches these
grovelings real quick). The chance of the attacker finding the hole
becomes so slim that, economically, it is not worth pursueing. However:
this does not change the fact that *technically*, it still is obscuring.

P.S.
If you wish to do so, read the IRC backlog; I had this discussion with
'tigger^' already :).

Cheers,
--
Thomas E. Spanjaard

#10 Updated by dillon over 7 years ago

Ok, lets not turn this into a bikeshed.

I actually agree that memory randomization is a good tool against
hacking. I just don't like it due to the unexpected side effects
that can sneak up on you when you enable it globally.

-Matt

#11 Updated by kevin.kane over 7 years ago

Thomas had an earlier suggestion to make a kernel option, would that
be a reasonable compromise, or would you still prefer it to be limited
to libc?

-Kevink

#12 Updated by corecode over 7 years ago

More about this patch:

this I386_MAX_EXE_ADDR is only used for openbsd's W^X i386 implementation, I think. The code is not really complicated, so I think we should add it. However, I think that it should be optional to switch on via a sysctl. Putting everything in kernel options makes everything so... bulky. Of course this sysctl would need to be guarded by securelevel.

cheers
simon

#13 Updated by dillon over 7 years ago

:Thomas had an earlier suggestion to make a kernel option, would that
:be a reasonable compromise, or would you still prefer it to be limited
:to libc?
:
:-Kevink
:
:--
:Kevin L. Kane
:kevin.kane at gmail.com

Well, I don't want to do anything for this release. Lets discuss it
again after the release. As I said, I am not against putting it in
the kernel, I'm just not happy with the side effects of doing so.

-Matt
Matthew Dillon
<>

#14 Updated by kevin.kane over 7 years ago

Sounds good, ill sit on it until after the release.

-Kevink

#15 Updated by alexh over 3 years ago

Well, 3 and a half years later it's after the release, so let's get it in.

Cheers,
Alex Hornung

#16 Updated by dillon over 3 years ago

:Alex Hornung <> added the comment:
:
:Well, 3 and a half years later it's after the release, so let's get it in.
:
:Cheers,
:Alex Hornung

I dunno. I never liked the concept of randomizing mmap offsets.
It could potentially create massive fragmentation of a process's
memory map as well as make testing more difficult.

-Matt
Matthew Dillon
<>

#17 Updated by sjg over 3 years ago

On Wed, Nov 24, 2010 at 11:30 AM, Matthew Dillon
<> wrote:
>
> :Alex Hornung <> added the comment:
> :
> :Well, 3 and a half years later it's after the release, so let's get it in.
> :
> :Cheers,
> :Alex Hornung
>
>    I dunno.  I never liked the concept of randomizing mmap offsets.
>    It could potentially create massive fragmentation of a process's
>    memory map as well as make testing more difficult.
>
>                                        -Matt
>                                        Matthew Dillon
>                                        <>
>

What's the attack vector when mmap offsets are predictable?

Sam

#18 Updated by dillon over 3 years ago

:
:What's the attack vector when mmap offsets are predictable?
:
:Sam

I'm well aware that predictable offsets make code replacement
attacks easier. I just don't think the best solution is to jumble
stuff up to the point where programs no longer operate predictably.

-Matt
Matthew Dillon
<>

#19 Updated by sjg over 3 years ago

> :
> :What's the attack vector when mmap offsets are predictable?
> :
> :Sam
>
>    I'm well aware that predictable offsets make code replacement
>    attacks easier.  I just don't think the best solution is to jumble
>    stuff up to the point where programs no longer operate predictably.
>
>                                        -Matt
>                                        Matthew Dillon
>                                        <>

That's actually what I was asking :) -- I wasn't attempting to make a
point or etc.

Sam

#20 Updated by alexh over 3 years ago

Let's put it under a sysctl that by default is off. The code is really compact
and well suited for that.

Can we agree on that?

Cheers,
Alex

#21 Updated by alexh over 3 years ago

I actually took the liberty to commit this straight ahead after a few IRC reviews. The
randomization is now under the control of a sysctl, vm.randomize_mmap, which by default is 0
(off).

See commit 911e30e25724984efec56accba87f739cfca2937.

Regards,
Alex

Also available in: Atom PDF