Travis H. wrote:

> Apart from that, I think that the knowledge of what programs are
> segfaulting, in what directories and for what users would be a
> great way to identify if someone is testing SGUID programs for
> vulernabilities, or to outright exploit them. 

I have recently added a segvguard implementation:

phyre:elad {6} sysctl security.pax.segvguard
security.pax.segvguard.enabled = 1
security.pax.segvguard.global = 0
security.pax.segvguard.expiry_timeout = 120
security.pax.segvguard.suspend_timeout = 600
security.pax.segvguard.max_crashes = 5
phyre:elad {7}

see security(8).

> The harder this is,
> the more noise they make, so the better our detection can work here.
> We can probably even figure out exactly what they were doing,
> which could lead to whitehats learning about a new technique
> before it is publicly discussed.

I'm assuming you want something like this:

phyre:elad {7} sysctl kern.coredump.setid
kern.coredump.setid.dump = 0
kern.coredump.setid.path = /var/crash/%n.core
kern.coredump.setid.owner = 0
kern.coredump.setid.group = 0
kern.coredump.setid.mode = 0600 (rw-------)
phyre:elad {8}

only for "normal" programs too?

> Also, it will increase the "noise" of the exploitation, especially
> with address space layout randomization. 

indeed.

> Another neat trick would be to give the cores (corpses) very confusing
> contents; perhaps some binary stuff that looks like code, with heap
> and stack pages partially corrupted and swapped about, and missing
> chunks from the .text segment, and with the shared libraries remapped
> to new addresses just for fun.  Oh yeah, don't forget to load all
> the saved registers with random data (or taken from another part
> of the image).  That would be kind of a fun project, actually :-)

let's get back to this once you have a working implementation. ;)

-e.