Re: [Axiom-developer] Re: [Gcl-devel] [Re: Executable memory: further programs that fail]

[root]

>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