DragonFlyBSD

: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

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

-Kevink

:> 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

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

: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

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

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
tgen@netphreax.net

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

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
tgen@netphreax.net

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

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

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

: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 
                    <dillon@backplane.com>

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

-Kevink

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

Cheers,
Alex Hornung

:Alex Hornung <ahornung@gmail.com> 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 
                    <dillon@backplane.com>

On Wed, Nov 24, 2010 at 11:30 AM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:

:Alex Hornung <ahornung@gmail.com> 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
                                       <dillon@backplane.com>

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

Sam

:
: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 
                    <dillon@backplane.com>

:
: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
                                       <dillon@backplane.com>

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

Sam

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

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