[lkml]   [2008]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] Add basic sanity checks to the syscall execution patch

    * Benjamin Herrenschmidt <> wrote:

    > > and that'd be because at the same time they patch the syscall table (remember,
    > > they already have to go to length to get around the read-only pages), they
    > > can't also patch this 'protection'? sounds really plausible, right :).
    > >
    > > [fixed hpa's address, .org bounces.]
    > Sure, they can :-)
    > It's just an idea I had on irc but I tend to agree that it wouldn't
    > have much effect in practice... regarding security, it will break some
    > existing rootkits ... until updated ones show up.

    at which point we are left with a change that has no relevance to
    updated rootkits (they circumvent it just fine), while the kernel
    syscall entry path is left with 2 cycles (or more) overhead, forever.

    Not a good deal.

    We introduced the read-only syscall table because it has debugging and
    robustness advantages, with near zero cost. This change is not zero cost
    - it's ~1% of our null syscall latency. (which is ~100 nsecs, the cost
    of this check is ~1 nsec)

    The other, more fundamental problem that nobody has mentioned so far is
    that the check returns -ENOSYS and thus makes rootkit attacks _more
    robust_ and hence more likely!

    The far better solution would be to insert uncertainty into the picture:
    some sort of low-frequency watchdog [runs once a second or so] that
    tries to hide itself from the general kernel scope as much as possible,
    perhaps as ELF-PIC code at some randomized location, triggered by some
    frequently used and opaque kernel facility that an attacker can not
    afford to block or fully filter, and which would just check integrity
    periodically and with little cost.

    When it finds a problem it immediately triggers a hard to block/filter
    vector of alert (which can be a silent alarm over the network or to the
    screen as well).

    that method does not prevent rootkits in general (nothing can), but sure
    makes their life more risky in practice - and a guaranteed livelihood
    and risk reduction is what typical criminals are interested in
    primarily, not whether they can break into a particular house.

    If we implement it then it should not be present in distro .config's,
    etc. - it should be as invisible as possible - perhaps only be part of
    the kernel image section in some unremarkably generic manner.

    [ It would be nice to have a 'randomize instruction scheduling' option
    for gcc, to make automated attacks that recognize specific instruction
    patterns less reliable. ]

    A good benchmark for such a silent alarm facility would be whether an
    experienced kernel developer could reliably tell it via a kgdb session
    and full access to memory and system symbols that such a silent alarm is
    running on a box. If he cannot do it reliably then there's probably no
    good way for an attacker either.

    And of course all the other layers of security play a bigger role: an
    attacker should not get to (native) kernel level access to begin with.


     \ /
      Last update: 2008-09-05 13:45    [W:0.025 / U:91.136 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site