gcl-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]