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

[Camm Maguire]

Hi Tim!

root <address@hidden> writes:

> Camm,
> 
> I believe you can query the exec-shield state by 
> 
>   cat /proc/sys/kernel/exec-shield
> 
> and probably fail to build if it is set to 1.
> The user will have to be root to set it which is not required
> otherwise unless they want to do a make install.
> 

OK, I'll probe this file, query its value, and add -Wa,--execstack to
the flags for now.  Will let you know when this is done.

> I can add it to the Axiom configure script.
> 
> I've raised objections to exec-shield on the fedora mailing
> list (I'm a developer). The code has only been added in the last

Thanks for your lisp defense efforts! :-)

> two weeks so now is the time to complain. However the complaints
> have been dismissed. I've read all the docs they pointed out to
> me and nowhere is it explained how it helps security. It does 
> hurt memory management but the basic response is "hey, nobody
> REQUIRES memory to be contiguous". It's about like putting chairs
> on the football field and claiming that there is nothing in the
> rules that says this is illegal. Of course every team at every
> game will have to play "around" the random chairs. 

>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.

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.

> 
> I'm not sure how to fix unexec. It appears that a possible solution
> will be to dynamically rebuild memory. One poster claimed that the
> "randomized shared library locations" will only happen in a 100Meg
> area. A possible strategy is to find the highest allocated byte
> in the highest shared library, mark the area below as part of the
> image and only allocate above that mark. Unexec could "save" the
> shared libraries as part of the image even though they are relinked
> again on restart.
> 

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. 

Take care,

> In general I'm rather confused about the whole issue. I'll have to
> read the unexec code in Emacs and get a real clue.
> 
> Tim
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah