[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: |
Camm Maguire |
Subject: |
Re: [Axiom-developer] Re: [Gcl-devel] [Re: Executable memory: further programs that fail] |
Date: |
02 Dec 2003 11:27:17 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings!
root <address@hidden> writes:
> 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
Just wanted to point out here that a randomization of this magnitude,
even if gcl can work around it, could potentially result in a loss of
100M in usable memory on each save-system. I think axiom currently
uses about 4 of these. The default memory maximum for GCL is only
128M. Count me among the elders :-).
> the discussion so I suppose that we may have to fall back on static
> linking as the only acceptable solution.
>
If you recall, static linking was broken even without exec-shield. I
think if brk randomization remains at the above mentioned range, we
would probably fall back on Roland's linker script solution, if I
understand correctly.
> 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.
>
OK, your understanding is considerably deeper than mine on this
issue. Even granting some security benefit, though, I don't see why
the range can't be quite small and still be effective. How long would
it take someone to guess a randomly generated address in even a 1k
range?
> >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) :-)
>
Take care,
> Tim
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- 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
- [Gcl-devel] 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