[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Re: [Gcl-devel] [Re: Executable memory: further pr
From: |
root |
Subject: |
Re: [Axiom-developer] Re: [Gcl-devel] [Re: Executable memory: further programs that fail] |
Date: |
Tue, 2 Dec 2003 10:53:09 -0500 |
>From our conversation with Roland, there appears to be one area they
>would consider changing, and this would help us a lot -- to forgo brk
>randomization, as apart from mmap, malloc, and ld.so randomization.
>Roland thought this randomization was a violation of the 'spec' of brk
>(I agree) and therefore should not be implemented, rather people
>should be encouraged to not use brk in favor of more 'modern' memory
>allocation routines. If I were in your position of influence, I would
>lobby for this, and not waste your wind trying to blow down
>exec-shield in its entirety. This simple change would solve virtually
>all our problems. It would however leave a non-randomized allocation
>path on the system, which may not be desirable from the point of view
>of security. Just to be clear, we might be able to work around a
>randomized brk as long as someone fixes unexec, but it will leave
>holes in the heap and diminish the available memory to the user.
I've only been attacking the brk randomization issue, not all of
exec-shield. The claim is that brk randomization will "only" allocate
within 100M of memory. (We elders-of-the-field consider 1M to be a
significant amount of memory :-) ) Roland appears to be unmoved by
the discussion so I suppose that we may have to fall back on static
linking as the only acceptable solution.
I forget why static linking failed but I'll have to get up to speed
on that again. I'll be at a workshop in italy until next tuesday so
nothing is going to happen until then. When I get back I'll figure
out how to statically link Axiom so the issue goes away.
>There are security gains to be had from this approach in general, and
>that is that an attacker cannot rely on a buffer overflow exploit
>being in a certain position in memory. I've never studied the
>construction of such exploits, but it would seem this would pose an
>insuperable obstacle.
The basic idea is that you find an exploit in library code, find out
where the dynamic library gets loaded, put a bogus "return address"
onto the stack which branches to the library code and run the exploit.
Since you don't know where the dynamic library will get loaded you
can't hard-code a branch address onto the stack. Of course if you'll
let me choose the execution location (because I have compromised your
stack) I pretty much own the machine.
Your fixed code probably does a call to the dynamic library anyway
otherwise it wouldn't have linked in the first place. From your
fixed code I can figure out the branch point your code will use,
compute the offset I want to exploit and push THAT address onto
the stack. Randomizing dynamic library locations is just a trivial
piece of fluff as far as security goes. However it is a huge
performance hit as far as memory management goes. The tradeoff isn't
worth the effort. I have yet to see a convincing argument otherwise.
>Luckily emacs seems to have sufficient importance that someone else
>will likely do this for us. I've been treating unexec as a black box
>myself.
Yeah, somebody will figure out unexec. It may even be me (though I
doubt it) :-)
Tim
- [Axiom-developer] Re: [Gcl-devel] [Re: Executable memory: further programs that fail], Camm Maguire, 2003/12/01
- Re: [Axiom-developer] Re: [Gcl-devel] [Re: Executable memory: further programs that fail], root, 2003/12/02
- Re: [Axiom-developer] Re: [Re: Executable memory: further programs that fail], Peter Simons, 2003/12/02
- Re: [Axiom-developer] Re: [Gcl-devel] [Re: Executable memory: further programs that fail], Camm Maguire, 2003/12/02
- Re: [Axiom-developer] Re: [Gcl-devel] [Re: Executable memory: further programs that fail], root, 2003/12/02
- Re: [Axiom-developer] Re: [Gcl-devel] [Re: Executable memory: further programs that fail], Camm Maguire, 2003/12/02
- Re: [Axiom-developer] Re: [Gcl-devel] [Re: Executable memory: further programs that fail], root, 2003/12/02
- Re: [Axiom-developer] Re: [Gcl-devel] [Re: Executable memory: further programs that fail], Camm Maguire, 2003/12/02