Elad Efrat wrote:
> The attack techniques this test suite checks for are
> 
>   1. If anonymous mappings, or the bss/data/stack/heap sections of a
>      binary, are executable by default. If they are, it means the most
>      basic buffer overflow exploits will work.

Some architectures (powerpc) have ABIs that mandate executable bss/data.
There is no way to turn that off.

>   2. If it's possible to make previously executable mappings writable,
>      or previously writable mappings executable. While this is standard
>      operation, it's a technique used to bypass W^X and the likes, and
>      can be seen in several modern exploits.

If you have textrel relocations, you have to allow this.  I think the
right way to have add a PROT_LOCKED that mprotect can understand.  If
this is supplied, the protection on such pages can't be downgraded.
munmap would still be allowed (it might be advisable to make munmap
change the region to PROT_NONE but leave it in place so it can't be
remapped.)

>   3. Amount of randomization in mappings each time a program starts.
>      The more predictable the mappings are, the easier it is to perform
>      attacks that require jumping to a known address - like ret-to-libc
>      for example, used also to bypass W^X.

The program itself is linked at a base address.  the libraries and stacks
could be vary but on machines with virtual caches, that might be very painful.

>      Note: While SSP may also help in preventing these ret-to-libc
>      attacks, this is another layer that should be considered, where the
>      two can provide more coverage against this type of attack.
> 
>   4. Return-to-lib attacks via string manipulation routines. If shared
>      libraries are mapped where the address of functions in them have
>      a NULL byte it means that the attacker can't (easily) use a
>      return-to-lib attack to get to them, because the input used to
>      overflow must be ASCII armored.

So you are saying that most libraries should be mapped at < 16MB?  That's
just not practical for most architectures.  I suppose that libraries with
<= 64KB of text can just be mapped on a 16MB boundary.  On LP64 you can map
libraries into the first 16MB of each 4GB region.  Of course, you'll fragment
your memory space that way.

>   5. Same as above, only this time the overflow is made in a routine
>      that isn't affected by a NULL byte. SSP should be able to stop
>      these attacks.
> 
>   6. Checks if code in the data/bss segments of a shared library can be
>      executed.

See above for ABI requirements.

>   7. Checks if it's possible to map text segments as writable. Another
>      form of the attack in #2.
> 
> The goal, of course, is to pass all tests in this suite.

I don't think that really practical for most platforms.

-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.