OpenBSD Journal

Vulnerabilities in systrace

Contributed by merdely on from the falacious-race dept.

At the First USENIX Workshop on Offensive Technologies, Robert Watson gave a presentation outlining vulnerabilities in systrace which he summarizes in this blog post:

A paper on the topic of compromising system call interposition-based protection systems, such as COTS virus scanners, OpenBSD and NetBSD's Systrace, the TIS Generic Software Wrappers Toolkit (GSWTK), and CerbNG. The key insight here is that the historic assumption of "atomicity" of system calls is falacious, and that on both uniprocessor and multiprocessing systems, it is trivial to construct a race between system call wrappers and malicious user processes to bypass protections.

I demonstrated sample exploit code against the Sysjail policy on Systrace, and IDwrappers on GSWTK, but the paper includes a more extensive discussion including vulnerabilities in sudo's Systrace monitor mode.

The moral, for those unwilling to read the paper, is that system call wrappers are a bad idea, unless of course, you're willing to rewrite the OS to be message-passing. Systems like the TrustedBSD MAC Framework on FreeBSD and Mac OS X Leopard, Linux Security Modules (LSM), Apple's (and now also NetBSD's) kauth(9), and other tightly integrated kernel security frameworks offer specific solutions to these concurrency problems. There's plenty more to be done in that area.

Todd Miller (millert@) clarifies the impact with sudo:

"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."

The Sysjail project is recommending against using sysjail:

"Due to handling semantics of user/kernel memory in concurrent environments, the sysjail tools, in inheriting from systrace(4), are vulnerable to exploitation. Details available here. Many thanks to Robert Watson for discovering these issues! Until these problems have been addressed, we do not recommend using sysjail (or any systrace(4) tools, including systrace(1)). All versions are vulnerable on all architectures.

Specifically, the bind(2) and sysctl(3) (and possibly other) functions may have their arguments re-written after being examined by the sysjail. This, in effect, leads to a total bypass of the prison."

It should be noted that systrace "has been integrated into NetBSD, OpenBSD and OpenDarwin" and has been ported to GNU/Linux, Mac OS X and FreeBSD.

To protect yourself from the shortcomings of systrace, know and understand what it does for you and make sure that systrace is not your only line of defense.

Just so it is clear, systrace is just a tool included in the distribution. It is not used by anything in the base system by default but be wary of using this tool as it stands. There has been long-standing skepticism around the effectiveness of systrace, including the difficulty in writing effective policies (Theo: "Establishing solid policies for daemons is not actually trivial.") and the unpredictable consequences of changing the semantics of the Unix privilege model (Marc Espie). 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.

Robert's paper and presentation are available on his site.

(Comments are closed)


  1. By Anonymous Coward () on

    The sky is falling mos def

    1. By Anonymous Coward () on

      > The sky is falling mos def

      well it seems that provos has/had a solution to the problem in his initial systrace paper but which wasn't implemented due to a slight performance hit. I'd definitely take the performance hit over the deprecation of or removal of systrace.

      1. By Anonymous Coward () on

        > > The sky is falling mos def
        >
        > well it seems that provos has/had a solution to the problem in his initial systrace paper but which wasn't implemented due to a slight performance hit. I'd definitely take the performance hit over the deprecation of or removal of systrace.

        Yeah, he talked about it on his blog

        http://www.systrace.org/index.php?/archives/14-Evading-System-Sandbox-Containment.html

        1. By Rich () shopping1@jezitski.co.uk on

          Indeed. This would suggest that support for systrace is incomplete in OpenBSD. No?

          Can't really blame systrace in that case.

        2. By Anonymous Coward () on

          > > > The sky is falling mos def
          > >
          > > well it seems that provos has/had a solution to the problem in his initial systrace paper but which wasn't implemented due to a slight performance hit. I'd definitely take the performance hit over the deprecation of or removal of systrace.
          >
          > Yeah, he talked about it on his blog
          >
          > http://www.systrace.org/index.php?/archives/14-Evading-System-Sandbox-Containment.html
          >

          I'm curious, how much of a hit? Niels doesn't mention the magnitude of the performance drop.

  2. By Anonymous Coward () on

    What did de Raadt and Provos disagree about?

    1. By Anonymous Coward () on

      > What did de Raadt and Provos disagree about?

      Publishing OpenBSD Vulnerabilities.

      Provos said do it.

      Theo said no, keep it secret.

      1. By henning () on

        > > What did de Raadt and Provos disagree about?
        >
        > Publishing OpenBSD Vulnerabilities.
        >
        > Provos said do it.
        >
        > Theo said no, keep it secret.

        this is obviously bullshit.

          1. By tedu () on

            > Out of curiosity, from a security perspective, how does djb's "extreme sandbox" compare with the systrace approach?
            >
            > http://cr.yp.to/cv/activities-20050107.pdf (Section 9)
            >
            > 2007.04.27 talk, with sample source code

            they're entirely different?

            sandbox == chroot
            systrace != chroot

            1. By Anonymous Coward () on

              > they're entirely different?
              >
              > sandbox == chroot
              > systrace != chroot

              Compare and contrast, then, if you will. In the ogg123 example, which is the more efficient/effective approach to securing it? Just curious about opinions....

              1. By Marc Espie () espie@openbsd.org on

                > > they're entirely different?
                > >
                > > sandbox == chroot
                > > systrace != chroot
                >
                >
                > Compare and contrast, then, if you will. In the ogg123 example, which is the more efficient/effective approach to securing it? Just curious about opinions....


                As always, the best approach is *fixing the darn bugs* in the software you're using.

                1. By Anonymous Coward () on

                  > As always, the best approach is *fixing the darn bugs* in the software you're using.

                  Sure, but a lot of OpenBSD development effort has gone towards technologies to prevent existing bugs from being exploited: W^X, ProPolice, StackGhost, non-exec stack, privilege-separation/revocation. DJB's ``extreme sandboxes'' are just privsep taken a few steps further.

                  1. By Anonymous Coward () on

                    > > As always, the best approach is *fixing the darn bugs* in the software you're using.
                    >
                    > Sure, but a lot of OpenBSD development effort has gone towards technologies to prevent existing bugs from being exploited: W^X, ProPolice, StackGhost, non-exec stack, privilege-separation/revocation. DJB's ``extreme sandboxes'' are just privsep taken a few steps further.

                    No it isn't, it has nothing to do with privsep.

                    1. By Anonymous Coward () on

                      > No it isn't, it has nothing to do with privsep.

                      Look at some privsep code in OpenBSD (e.g., the ``Parent, drop privileges to _tcpdump'' block in http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/tcpdump/privsep.c?rev=1.25&content-type=text/x-cvsweb-markup) and then look at the sample extreme sandboxing code in http://cr.yp.to/talks/2007.04.27/extremesandbox.c.

                      If you still think they have nothing to do with one another, go back to step 1.

                      1. By Anonymous Coward () on

                        > > No it isn't, it has nothing to do with privsep.
                        >
                        > Look at some privsep code in OpenBSD (e.g., the ``Parent, drop privileges to _tcpdump'' block in http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/tcpdump/privsep.c?rev=1.25&content-type=text/x-cvsweb-markup) and then look at the sample extreme sandboxing code in http://cr.yp.to/talks/2007.04.27/extremesandbox.c.
                        >
                        > If you still think they have nothing to do with one another, go back to step 1.

                        Holy hell, this may as well be slashdot with all the ignorant bullshit getting posted and modded up. You go read the code. Privsep != chroot. Just because chroot requires you to drop privileges in order for it to do anything, doesn't mean it has anything to do with privsep, which splits privileged and non-privileged code into seperate processes that communicate back and forth to accomplish tasks that require privileges.

                  2. By Can Acar () canacar@ on

                    > DJB's ``extreme sandboxes'' are just privsep taken a few steps further.

                    The extremesandbox.c code is not privsep, it is just privilege
                    dropping (privdrop), already employed by many programs in base.

                    Privsep is the next step to privdrop where a program needs some
                    privileges to work. In privsep, the program maintains a connection
                    to a privileged process running a much smaller chunk of code that is
                    fully audited. The privileged process does the privileged work,
                    validating each request from the non-privileged process.

                    There is one chunk of code in DJB stuff that we don't do right now,
                    (when dropping privileges) which is setting process limits to
                    prevent the non-privileged process from forking. I will think
                    about it.

                    1. By Anonymous Coward () on

                      > The extremesandbox.c code is not privsep, it is just privilege
                      > dropping (privdrop), already employed by many programs in base.

                      Sorry, I know the difference between privilege separation and privilege revocation. I used the term ``privsep'' just because I didn't want to type out ``privilege revocation'' and didn't consider ``privdrop.''

                      > There is one chunk of code in DJB stuff that we don't do right now,
                      > (when dropping privileges) which is setting process limits to
                      > prevent the non-privileged process from forking. I will think
                      > about it.

                      extremesandbox() also gives a unique UID to every process so they can't send signals to one another.

                      1. By Anonymous Coward () on

                        > > The extremesandbox.c code is not privsep, it is just privilege
                        > > dropping (privdrop), already employed by many programs in base.
                        >
                        > Sorry, I know the difference between privilege separation and privilege
                        > revocation. I used the term ``privsep'' just because I didn't want to
                        > type out ``privilege revocation'' and didn't consider ``privdrop.''

                        But privsep is much more than just dropping privileges. It is a
                        custom designed protocol plus state machine for each application.
                        Child dropping privileges is just a small part of it.

                        > > There is one chunk of code in DJB stuff that we don't do right now,
                        > > (when dropping privileges) which is setting process limits to
                        > > prevent the non-privileged process from forking. I will think
                        > > about it.
                        >
                        > extremesandbox() also gives a unique UID to every process so they
                        > can't send signals to one another.

                        We prefer to have a different _user for each application. One may argue
                        that it is not granular enough, but in practice you will not have many
                        tcpdump instances with child processes signaling each other.

                        I do not like to see uid's on my systems that do not map to an actual user.

      2. By Anonymous Coward () on

        > > What did de Raadt and Provos disagree about?
        >
        > Publishing OpenBSD Vulnerabilities.
        >
        > Provos said do it.
        >
        > Theo said no, keep it secret.

        Where do you get this info from? Care to share?

        1. By Anonymous Coward () on

          > > > What did de Raadt and Provos disagree about?
          > >
          > > Publishing OpenBSD Vulnerabilities.
          > >
          > > Provos said do it.
          > >
          > > Theo said no, keep it secret.
          >
          > Where do you get this info from? Care to share?

          It is called the ass. No need to share, everyone has one.

  3. By Anonymous Coward () on

    Wasn't it Robert Watson who developed TrustedBSD MAC Framework and FreeBSD's Jails ?

    1. By tmclaugh () on

      > Wasn't it Robert Watson who developed TrustedBSD MAC Framework and FreeBSD's Jails ?

      Robert is one of the TrustedBSD developers. jail was written by Poul-Henning Kamp but Robert has contributed to that too.

  4. By Anonymous Coward () on

    So what's the OpenBSD Team gonna do?
    Nothing but recommenting to NOT use it? Then they could drop it from the Base System... :-/

    It would be great if either a Patch or another Solution would get provided for OpenBSD 4.2.

    I seriously don't know how to ensure the security at my systems right now. Chroots ok.. but "Jails" (notfBSD, Sysjail) always looked far better...

    So.. what's the OpenBSD Team gonna do?

    1. By Anonymous Coward () on

      > So what's the OpenBSD Team gonna do?
      > Nothing but recommenting to NOT use it? Then they could drop it from the Base System... :-/
      >
      > It would be great if either a Patch or another Solution would get provided for OpenBSD 4.2.
      >
      > I seriously don't know how to ensure the security at my systems right now. Chroots ok.. but "Jails" (notfBSD, Sysjail) always looked far better...
      >
      > So.. what's the OpenBSD Team gonna do?

      ok, so how did you 'ensure the security' of your openbsd systems before sysjail?

      1. By Anonymous Coward () on

        > > So what's the OpenBSD Team gonna do?
        > > Nothing but recommenting to NOT use it? Then they could drop it from the Base System... :-/
        > >
        > > It would be great if either a Patch or another Solution would get provided for OpenBSD 4.2.
        > >
        > > I seriously don't know how to ensure the security at my systems right now. Chroots ok.. but "Jails" (notfBSD, Sysjail) always looked far better...
        > >
        > > So.. what's the OpenBSD Team gonna do?
        >
        > ok, so how did you 'ensure the security' of your openbsd systems before sysjail?

        Simply used more Boxes for the Services?

  5. By Anonymous Coward () on

    The fact Robert points to something like Kauth in NetBSD as being the right way to do these things you have to wonder.
    We pay for what is suppose to be a secure OS when it is nothing more than a one man sandbox.
    Great ideas are not copied, but instead are laughed at. All in the name of making things "secure"
    but in the end it all falls short. Atleast djb offers $$ to back up his claims.
    And he does not even charge for his software...
    Elitism based on a false sense of security. "Because Theo says so"
    A lot of good work has been done, but in the end Theo just says no.
    Do cults charge for their propoganda?

    1. By Steve Shockley () steve@shockley.net on

      > Atleast djb offers $$ to back up his claims.

      Ask Guninsky about that...

      > And he does not even charge for his software...

      And yet, it's not free.

      1. By pete gilman () on http://p3t3.net

        > > Atleast djb offers $$ to back up his claims.
        >
        > Ask Guninsky about that...
        >
        > > And he does not even charge for his software...
        >
        > And yet, it's not free.

        don't feed the trolls.

    2. By Anonymous Coward () on

      > And he does not even charge for his software...
      > Elitism based on a false sense of security. "Because Theo says so"
      > A lot of good work has been done, but in the end Theo just says no.
      > Do cults charge for their propoganda?

      Yes. The propaganda, however, is /free/.

    3. By Lars Hansson (bysen) on

      <em>We pay for what is suppose to be a secure OS when it is nothing more than a one man sandbox.</em>

      I forget, when exactly are you forced to pay for OpenBSD?

      <em>Great ideas are not copied, but instead are laughed at. All in the name of making things "secure"</em>

      Laughed at? Surely, you can make up better lies than that?

      <em>And he does not even charge for his software...</em>

      Oh, yea mean rxactly like how Theo does not charge for OpenBSD?

      <em>Elitism based on a false sense of security. "Because Theo says so"
      A lot of good work has been done, but in the end Theo just says no.<em>

      Don't take his the wrong way but...you're being stupid.
      Seriously, do you people have nothing better to do with your lives than post moronic flamebait on forums?

    4. By I'm not Alan Cox () on

      > The fact Robert points to something like Kauth in NetBSD as being the right way to do these things you have to wonder.
      > We pay for what is suppose to be a secure OS when it is nothing more than a one man sandbox.
      > Great ideas are not copied, but instead are laughed at. All in the name of making things "secure"
      > but in the end it all falls short. Atleast djb offers $$ to back up his claims.
      > And he does not even charge for his software...
      > Elitism based on a false sense of security. "Because Theo says so"
      > A lot of good work has been done, but in the end Theo just says no.
      > Do cults charge for their propoganda?

      host 195.92.253.2
      host zeniv.linux.org.uk
      whois linux.org.uk

      Maybe you're too elitist to assume what you say Mr AC.

    5. By Anonymous Coward () on

      hahahaha that is really funny! systrace sucks shit; always has hence no one uses it. Now why are people up in arms about something that isn't used and is useful for that matter?

      As usual it is all blah blah blah.

    6. By Anonymous Coward () on

      > The fact Robert points to something like Kauth in NetBSD as being the right way to do these things you have to wonder.

      I wasn't aware that the subject of kauth being added to OpenBSD had come up ?

    7. By Anonymous Coward () on

      > The fact Robert points to something like Kauth in NetBSD as being the right way to do these things you have to wonder.

      Its from Mac OS X, NetBSD just re-implimented it.

  6. By Brynet (Brynet) on

    Does anyone know what's going on? CVS commits at marc.info have been quite for 2 days.. http://openbsd.org fails to connect..

    Can a developer please clarify the situation? is it at all related to this? if not.. please explain what the heck is going on already by posting a new undeadly topic???

    Please! - This situation needs clarity.. someone speak up..

    1. By Anonymous Coward () on

      > Does anyone know what's going on? CVS commits at marc.info have been quite for 2 days.. http://openbsd.org fails to connect..
      going to www.openbsd.org connects fine, but openbsd.org does not.

      1. By Brynet (Brynet) on

        > going to www.openbsd.org connects fine, but openbsd.org does not.

        Yes, But that appears to be a different server entirely..

        I'm asking about what's going on with openbsd.org (aka cvs.openbsd.org)..

        Again, don't leave us in the dark developers.. post an announcement or something already!

        1. By e4ea () on

          > > going to www.openbsd.org connects fine, but openbsd.org does not.
          >
          > Yes, But that appears to be a different server entirely..
          >
          > I'm asking about what's going on with openbsd.org (aka cvs.openbsd.org)..
          >
          > Again, don't leave us in the dark developers.. post an announcement or something already!

          I have seen a post from Theo that 4.2 was coming soon.
          May be that's the reason?

    2. By Matthias Kilian () on

      > is it at all related to this?

      No, it's just a network problem. Don't panic ;-)

      1. By Anonymous Coward () on

        > > is it at all related to this?
        >
        > No, it's just a network problem. Don't panic ;-)

        But it isn't related to the Cisco thing he got or? *ok, a sick joke* :-p

    3. By Anonymous Coward () on

      > Does anyone know what's going on? CVS commits at marc.info have been quite for 2 days.. http://openbsd.org fails to connect..
      >
      > Can a developer please clarify the situation? is it at all related to this? if not.. please explain what the heck is going on already by posting a new undeadly topic???
      >
      > Please! - This situation needs clarity.. someone speak up..

      Wow, paranoid much?

      Put the foil hat back on, everything will be OK.

      1. By Brynet (Brynet) on

        > > Does anyone know what's going on? CVS commits at marc.info have been quite for 2 days.. http://openbsd.org fails to connect..
        > >
        > > Can a developer please clarify the situation? is it at all related to this? if not.. please explain what the heck is going on already by posting a new undeadly topic???
        > >
        > > Please! - This situation needs clarity.. someone speak up..
        >
        > Wow, paranoid much?
        >
        > Put the foil hat back on, everything will be OK.

        Are you insulting my tin foil hat style? watch it buddy.. ;-)

        Really, I panicked.. I do that.. It's a medical thing.

  7. By Arach () on

    Remember, systrace is still useful for some privelege escalation (consider "as user/group" when probably all your "prison-bypassing" trick is about to get *less* privileges :). And the rule sets for privelege escalation can be really simple and short. Nothing is perfect, but that doesn't mean everything is totally useless. ;) For example, consider Samba's smbd as non-root without losing its functionality. With systrace, it Just Works (well, a little bit of port redirection is required to avoid privileged bind()s via systrace's "as root").

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]