Slashdot Mirror


Cambridge Researcher Breaks OpenBSD Systrace

An anonymous reader writes "University of Cambridge researcher Robert Watson has published a paper at the First USENIX Workshop On Offensive Technology in which he describes serious vulnerabilities in OpenBSD's Systrace, Sudo, Sysjail, the TIS GSWTK framework, and CerbNG. The technique is also effective against many commercially available anti-virus systems. His slides include sample exploit code that bypasses access control, virtualization, and intrusion detection in under 20 lines of C code consisting solely of memcpy() and fork(). Sysjail has now withdrawn their software, recommending against any use, and NetBSD has disabled Systrace by default in their upcoming release."

16 of 194 comments (clear)

  1. SELinux and the same ... by Gopal.V · · Score: 5, Informative

    James Morris has put up an analysis of the same vulnerabilities.

    And pushing the system code down into lower echelons of execution (i.e kernel), the way SELinux does it, is a valid fix.

    1. Re:SELinux and the same ... by makomk · · Score: 2, Informative

      Just putting the validation code in the kernel is not, by itself, sufficient - it's important that any arguments are copied from userspace exactly once. If the validation code and the actual syscall code each do their own copy from userspace, this is a potentially exploitable security issue.

    2. Re:SELinux and the same ... by Jokkey · · Score: 2, Informative

      I wonder what the performance penalty would be for thunking to kernel space would on every such operation would be?

      What's being discussed here is system call wrapping, and system calls by definition go to kernel space anyway. No extra thunk to kernel space is required.

  2. Re:so much for... by ArwynH · · Score: 4, Informative

    And it still only has had two remote holes in the default install in more than 10 years. This isn't a remotely exploitable hole, it allows privilege escalation, which requires access to the system and thus is a local hole. It's still a whopper of a hole though...

  3. why give much of a crap by rubycodez · · Score: 2, Informative

    on local user/software exploits? my domains have over a thousand users, but no one logs into an account on the machine.

  4. No released version of sudo affected by millert · · Score: 5, Informative

    The sudo systrace support is part of an experimental feature ("monitor mode") not present in any of the real sudo releases (though the code is available via anonymous cvs). Given the deficiencies of systrace (and ptrace) it is unlikely that this feature will be present in any future sudo release.

      - todd

  5. "cambrige researcher"... by diegocgteleline.es · · Score: 3, Informative

    ...and he's also one of the most important FreeBSD hackers.

  6. Re:fix shedules ? by orclevegam · · Score: 3, Informative

    as usual I would assume *bsd to put out fixes quite timely...

    Well, the fix for now appears to be don't use the vulnerable software, but considering that the vulnerability allows you to break the software such that it behaves as if it wasn't running, I have to wonder if people should use it anyway and just accept that for now anyone that knows how can bypass that particular security check. Also, if it was something simple like a buffer overrun that would be trivial to patch, but because of the way this particular vulnerability functions (concurrency attack) there's not simple solution. Some have suggested pushing the code to kernel space, but as they've also pointed out, that's rather risky in its own regard. Short of some kind of provision in the kernel to prevent the attacks I'm not sure how this could be fixed (although I haven't seen to many details, just that it involves re-writing some args after they've already been scanned by systrace).

    --
    Curiosity was framed, Ignorance killed the cat.
  7. Re:Linux? by Noryungi · · Score: 2, Informative

    Yes, M. Watson also attacked equivalent programs (GSWTK) under Linux successfully.

    Read his blog post, as some of the techniques described are quite interesting. Too bad we can't read the full paper.

    --
    The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
  8. Re:Linux? by x_MeRLiN_x · · Score: 4, Informative

    Would you be talking about this?

  9. Re:fix shedules ? by TubeSteak · · Score: 3, Informative

    as usual I would assume *bsd to put out fixes quite timely... FTFA: All affected vendors received at least six months, and in some cases many years advance notice regarding these vulnerabilities.
    --
    [Fuck Beta]
    o0t!
  10. Re:Since NetBSD seems to be affected as well... by ratboy666 · · Score: 2, Informative

    Given that the vulerability exploited is a system call race, it may be that the "unwrapped" system calls may be exploited as well.

    Basically, wrapping the call (supposed to increase security) make the race more exploitable. It is NOT "sudo" that is at fault, specifically, because sudo (in its current release) does not do call wrapping.

    There is an easy solution available -- simply disallow all execution between the time the system call is invoked, and all parameters have been copied to system space. Alternatively, do not allow threading, and mapping of memory used for parameters in an active call (a bit more difficult).

    A security audited system call interface is needed, along with a prohibition on wrapping system calls expected by an application (because those wraps could be exploited by an attacking program).

    And you are right -- Windows is probably more vulnerable to this, simply because there are more system calls that use buffer pointers.

    But this entire class of exploit is "local only", which means that the system needs to be comprimised another way first; this can be used to obtain root, or use unauthorized resources.

    SELinux can be used to prevent much of the damage possible, as can Trusted Solaris. I don't know if there is a Windows eqivalent.

    --
    Just another "Cubible(sic) Joe" 2 17 3061
  11. OpenBSD's man page for systrace mentions this? by cgdae · · Score: 5, Informative

    OpenBSD's systrace manpage appears to mention this problem in the BUGS section:

    Applications that use clone()-like system calls to share the complete address space between processes may be able to replace system call arguments after they have been evaluated by systrace and escape policy enforcement.

    Or see http://www.openbsd.org/cgi-bin/man.cgi?query=systr ace&apropos=0&sektion=0&manpath=OpenBSD+Current&ar ch=i386&format=html

    --
    http://op59.net/
  12. Sysjail is really just one guy by raddan · · Score: 2, Informative

    Kristaps Dzonsons. And I'm not sure if he ever really intended for it to be for production use. I saw his talk at NYCBSDCon last year, and my impression was "here's a neat tool I'm working on guys, I'm still working out a lot of things, come play if you want". Not that this isn't an important vulnerability to address-- but I'd be surprised if anyone was currently using sysjail in an important production role.

  13. Undeadly coverage by zyche · · Score: 4, Informative

    Coverage on Undeadly.

    To answer some anti-OpenBSD bias from the summary above: systrace is really Niels Provos toy, OpenBSD just includes it in the base install just as NetBSD does; regarding sudo, it has been addressed in a comment above (not vulnerable in the actual released version); and by saying that NetBSD has disabled systrace that implies that OpenBSD has it still enabled. Except that it is a tool that isn't used by the default install at all - you have to enable and configure it yourself. And as the Undeadly post states: Since 2002, the systrace(1) man page included a warning in the BUGS section about the possibility of escaping the policy enforcement because of the behavior of certain system calls..

    Personally I have never liked the idea of systrace - leaves way to much to to me as a system administrator to fuck up.

  14. Systrace.org post on this alleged bug by widman · · Score: 2, Informative
    http://www.systrace.org/index.php?/archives/14-Eva ding-System-Sandbox-Containment.html

    At WOOT this year, Robert Watson presented a paper on how to evade popular system call interposition systems, including Systrace. For Systrace, Robert noticed that the arguments written to the stackgap could be replaced by a co-operating process after Systrace performed its policy check. The initial prototype of Systrace as described in the paper avoided this problem by using a look-aside buffer in the kernel. This imposes a slight performance penality but I hope that this obvious solution is going to be included in the OpenBSD and NetBSD kernel soon.
    Also check the comment by the "Cambridge Researcher", kind of acknowledging it's nothing new.