[Gllug] just preaching to the converted !

[Daniel P. Berrange]

On Thu, Oct 27, 2005 at 12:01:11AM +0100, Nix wrote:
> > ExecSheild randomization works on PIE (Position Independant Executable)
> > program and PIC shared libraries to randomization the location of
> > the start of the stack, the program heap, and the address at which
> > shared libraries are mmap()d into a process. An ever increasing number
> > of programs in Fedora & RHEL are built as PIE/PIC binaries enabling
> > randomization. You can run this script
> 
> ... but it does not randomize things below the ELF object level: i.e.
> it won't reshuffle the pieces of one shared library with respect to the
> others, so someone who finds a suitable vulnerability in something
> qsort() calls could potentially smash the stack *just for the qsort()
> return address*, pointing it at some routine of his own choosing.
> 
> (Doing this without smashing intervening locations on the stack, thus
> avoiding ProPolice, is difficult but doable.)
> 
> >   http://people.redhat.com/drepper/lsexec
> 
> (Note that this needs Ulrich's elfutils.)

Yep, everything I write is usually wrt to RHEL/Fedora, although all of
this stuff is making its way slowly upstream & thus eventually into other 
distros.

> > The main problem with stack randomization is that the 4 GB process
> > address space on 32-bit architecture limits the level to which one
> > can randomize things. While its good at protecting against remote
> > users, there's not enough scope for randomization, to prevent a 
> > brute force attack from a local user.
> 
> Well, combined with ProPolice, which uses an eight-byte stack canary, it
> boosts the number of trials required to an average of 2^15 * 2^63 == 2^78,
> an implasibly high number. Mind you given that ProPolice kills the
> process on each trial and syslogs it at priority LOG_CRIT, that 2^15
> extra might be considered a waste of time.
> 
> (ProPolice imposes a noticeable overhead --- but then so does PIE.
> Is it worth it? On firewalls and root-owned daemons, perhaps. For

PIE is no more overhead than PIC and given that every shared library 
on Linux is PIC, I don't think the addition of PIE will be too much
of a problem. Hence all network daemons in Fedora are now PIE, and
a number of other network facing programs are also using it.

> everything else, well, I'm not sure how to integrate it with automake-
> built makefiles without modifying every makefile: there's no analogue
> of CFLAGS which applies *only* to builds of things which will *not*
> land in shared libraries! I suppose I should look at how RH does it:
> I'm probably missing something really, really obvious...)

Exactly it - you have to modify the individual Makefile.am files for
each binary to add -fpie into the CFLAGS for the executable. Merely
setting global CFLAGS is no good since that'd impact shared libraries
too, which need to be PIC rather than PIE. In the great scheme of things
the work involved in adding one more patch for Makefiles to 30-40 RPMs 
for network daemons is not a huge problem, particularly if it mitigates
future security problems.

Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Digital signature
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20051027/f6ddb915/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug