lkml.org 
[lkml]   [2005]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: thoughts on kernel security issues
    -----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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:2.542 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site