Bug #514
closedpatch to randomize mmap offsets
Added by kevin.kane over 17 years ago. Updated over 13 years ago.
0%
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
Files
random-mmap.patch (4.16 KB) random-mmap.patch | kevin.kane, 01/14/2007 08:15 PM |
Updated by dillon over 17 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
Updated by kevin.kane over 17 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
Updated by dillon over 17 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
Updated by corecode over 17 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
Updated by dillon over 17 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
Updated by kevin.kane over 17 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
Updated by TGEN over 17 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
tgen@netphreax.net
Updated by corecode over 17 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
Updated by TGEN over 17 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
tgen@netphreax.net
Updated by dillon over 17 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
Updated by kevin.kane over 17 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
Updated by corecode over 17 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
Updated by dillon over 17 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
<dillon@backplane.com>
Updated by kevin.kane over 17 years ago
Sounds good, ill sit on it until after the release.
-Kevink
Updated by alexh almost 14 years ago
Well, 3 and a half years later it's after the release, so let's get it in.
Cheers,
Alex Hornung
Updated by dillon almost 14 years ago
: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>
Updated by sjg almost 14 years ago
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 HornungI 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
Updated by dillon almost 14 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
<dillon@backplane.com>
Updated by sjg almost 14 years ago
:
:What's the attack vector when mmap offsets are predictable?
:
:SamI'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
Updated by alexh almost 14 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
Updated by alexh almost 14 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