[Gllug] just preaching to the converted !

[Nix]

On Wed, 26 Oct 2005, Daniel P. Berrange stated:
> On Wed, Oct 26, 2005 at 10:48:39AM +0100, Huw Lynes wrote:
>> On Tue, 2005-10-25 at 22:43 +0100, Nix wrote:
>> 
>> > (This is just one of the reasons why I prefer *not* to use precompiled
>> > binaries. I'm wondering about the feasibility of adding random
>> > perturbations to stack frames as well, done with zero overhead by a
>> > suitable rand() call in GCC... hm, I shall have to hack that up.)
>> > 
>> Isn't that essentially what PIE and PIC do? Which I think Fedora and
>> others turn on by default these days.
> 
> 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.)

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

>                                       Switching to 64-bit gives one
> a huge address space to play with, making brute force attack pretty
> much impractical.

Indeed it does, which means that hopefully this major attack vector will
decline into irrelevance (well, reduce to a DoS attack) in coming years.

-- 
`"Gun-wielding recluse gunned down by local police" isn't the epitaph
 I want. I am hoping for "Witnesses reported the sound up to two hundred
 kilometers away" or "Last body part finally located".' --- James Nicoll
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug