Re: thoughts on kernel security issues

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Arjan van de Ven wrote:
>>ES has been actively developed since it was poorly implemented in 2003.
>> PaX has been actively developed since it was poorly implemented in
>>2000.  PaX has had about 4 times longer to go from a poor
>>proof-of-concept NX emulation patch based on the plex86 announcement to
>>a full featured security system, and is written by a competant security
>>developer rather than a competant scheduler developer.
> 
> 
> I would call that an insult to Ingo.
> 

You're reading too deeply then.

> 
> 
>>Split-out portions of PaX (and of ES) don't make sense.  
> 
> 
> they do. Somewhat. 

They do to "break all existing exploits" until someone takes 5 minutes
to make a slight alteration.  Only the reciprocating combinations of
each protection can protect the others from being exploited and create a
truly secure environment.

Ingo said there's other stuff in ES that this doesn't apply to but
*shrug* again, beyond what I intended when I said that.

> 
>>ASLR can be
>>evaded pretty easily:  inject code, read %efp, find the GOT, read
>>addresses.  The NX protections can be evaded by using ret2libc.  on x86,
>>you need emulation to make an NX bit or the NX protections are useless.
> 
> 
> actually modern x86 cpus have hardware NX. 

not my point. . .
> 
> 
>>PT_GNU_STACK annoys me :P  I'm more interested in 1) PaX' full set of
>>markings (-ps for NX, -m for mprotect(), r for randmmap, x for
>>randexec), 2) getting rid of the need for anything but -m, and 3)
>>eliminating relocations.  Sometimes they don't patch GLIBC here and
>>Firefox won't load flash or Java because they're PT_GNU_STACK and don't
>>really need it (the java executables are marked, but the java plug-in
>>doesn't need PT_GNU_STACK).
> 
> 
> so remark them.

Manually.  Annoying because now I'm doing PaX AND Exec Shield markings,
but I do remark them anyway.  This wasn't meant to sound like it was a
major problem, just to be a side comment.

> 
> 
>>I guess it works on Exec Shield, but it frightens me that I have to
>>audit every library an executable uses for a PT_GNU_STACK marking to see
>>if it has an executable stack.
> 
> 
> there is lsexec which does this automatic for you based on running
> propcesses
> 

I don't want to run something potentially dangerous.  Think secret
military installation with no name and blank checks made out to nobody.
 The security has to scale up and down; it has to be useful for the home
user, for the business, and for those that don't officially exist.

> 
>>Either or if it stops an exploit; there's no "stopping an exploit
>>better," just stopping more of them and having fewer loopholes.  As I
>>understand, ES' NX approximation fails if you relieve protections on a
>>higher mapping
> 
> 
> which is REALLY rare for programs to do
> 

True, but PaX has a failsafe in PAGEEXEC, and doesn't suffer this in
SEGMEXEC.

> 
>>-- which confuses me, isn't vsyscall() a high-address
>>executable mapping, which would disable NX protection for the full
>>address space?
> 
> 
> just like PaX, execshield has to disable the vsyscall page.
> Exec-Shield actually has the code to 1) move the vsyscall page down in
> the address space and 2) randomize it per process, but that is inactive
> right now since it needs a bit of help from the VM that isn't provided
> anymore since 2.6.8 or so.
> 
> 

ah.

> 
>>PaX though gives me powerful, flexible administrative control over
>>executable space protections as a privileged resource.
>>mprotect(PROT_EXEC|PROT_WRITE) isn't something normal programs need; so
>>it's not something I allow everyone to do.
> 
> 
> it's a balance between compatibility and security. PaX strikes a
> somewhat different balance from E-S. E-S goes a long way to avoid
> breaking things that posix requires, even if they are silly and rare.
> Apps don't DO   PROT_EXEC|PROT_WRITE normally after all.. so this added
> "protect" is to a point artifical.
> 
> 

The actual threat this mitigates is that the app may be ret2libc'd to
mprotect() (possible with unrandomized ET_EXEC?), but in reality a more
complex attack can accomplish the same thing.  I prefer it more as a
speed bump to expose broken code to me or at least give me an idea of
what to audit.  If something HAS to mprotect() the stack, then I HAVE to
make sure that program is audited, or I'm just being a dumbass and
waiting to be infected with a cheap worm some scriptkiddie wrote using a
build-your-own-virus program.

> 
> 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB7qvthDd4aOud5P8RAhbVAJ9Jdxp/mKByxWChjM1bQMVZaIN4JACfaJ1I
Rezv+g9BE7ezKwHB5UCvdnk=
=EEu/
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/