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

SELinux and the same ...

James Morris has put up an analysis [livejournal.com] 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.

Re:SELinux and the same ...

I wonder what the performance penalty would be for thunking to kernel space would on every such operation would be? If it was well implemented I would guess it would be minimal since you could just pass the call off to the called kernel object directly. I also wonder what if any security vulnerabilities would be exposed by moving that extra code in kernel space. I know for the TrustedBSD tools it would be minimal due to their strict code checking policies, but for other systems having this much extra code in kernel space might be a risk.

Linux?`

Any word if any of these vulnerabilities affect Linux or other Unixes as well?

Re:Linux?

Would you be talking about this [watson.org]?

Re:Linux?

The presentation covers it pretty well. At least the GSWTK attack.

(It's a straight forward time-of-use vs. time-of-check attack. And we were at least partially aware of it when we wrote GSWTK. The problem is that the original system calls require memory in the processes space, so you can't just copy in the string after you validate it to keep the process from changing it. I wrote some methods for Linux that allocated extra pages in the processes memory space so we could copy in the string, but that just makes the attack harder via obscurity. It doesn't address the fundamental issue at all.)

Since NetBSD seems to be affected as well...

are other UNIX-based Operating Systems vulnerable as well? Systrace and especially Sudo are very common in nearly all UNIX-like Systems, so maybe Linux and MacOS X users should also be concerned? And what about Windows, since commercially availabe anti-virus systems are also afflicted? That seems like a very serious vulnerability to me...

Re:I'm not worried

You know the old saying... "you get what you stay for". As long as you're logging in as root you will damage your system. It's a known fact. Anyone who logs in as root eventually dostoyevsky's their system. Logging in as root is dangerous. Even using 'su -' is dangerous. 'sudo' provides some level of security and accountability but even that is dangerous. I can't tell you how many times I've seen people type 'sudo bash' and then tool around doing everything as root all the time. The only way to really be safe is to never use any super user abilities whatsoever. The way I've handled it is that any time I run into something that I need root access for, I just give up. So I don't have any new users other than the ones I originally set up when I installed Ubuntu. I also don't have any access to the CD-RW drive built into the system, but that's OK since I'm not an illegal music and software pirate (only pirates use CD-R/CD-RW). I can't use the attached scanner that once worked in Windows 98 but that's OK since there is no need to scan photos or anything in Linux since there are no apps with which to work on them anyway. Whenever the system pops up asking me for the root password I just cancel out and stick with whatever settings the system had. Basically for me, a request for the root password is a threat to the security of my PC, myself and possible the nation or even global security. So in short DO NOT EVER USE root access of ANY kind. It's very dangerous and best left to the experts (bearded and bald scientists in dusty university halls).

Re:I'm not worried

Thank God! A user that finally gets security! Look at those pigs wizzin by...

No need for alarm!

The tremors that you are feeling are from the sounds of the collective users of OpenBSD all simultaneously shouting "Fuck!" in exasperation.

Re:No need for alarm!

The tremors that you are feeling are from the sounds of the collective users of OpenBSD all simultaneously shouting "Fuck!" in exasperation.

All twelve of them. :)

I like the thought of openbsd, though, having never used it. I'm sure everything will be fine.

Re:No need for alarm!

All twelve of them. :)

We yell really loud.

(And I actually yelled "Wow!". We're not a homogenous lot.)

why give much of a crap

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

Re:why give much of a crap

Local exploits are only a phpBB vulnerability from being a remote exploit. If you're running a hosting service, and you're not treating local vulnerabilities as seriously as remote ones, it's only a matter of time before your machine is pwned and becomes a spam zombie. I've seen it happen.

If you allow scripting on your server, then you've essentially given your users shell access, anyway.

OpenBSD Security

... now if only this would lead to a little ego deflation and humility among OpenBSD developers.

As long as I'm dreaming, I also want a pony.

No released version of sudo affected

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

Code isn't up (thank goodness)

It appears he's removed the code from the presentation (though it still says it's present, I don't see it). Good.

Ha Ha

Sweet justice! My Win98 boxes have finally protected me against a hole. I am invinci*^&#%
$#%#^&&!#$@$

[CONNNECTION LOST]

Brace for impact...

Theo DeRaadt goes on a rampage in 5... 4... 3... 2...

"cambrige researcher"...

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

Article?

Site is slashdotted, anyone got a copy of the article?

problem affects a variety of software

This class of problem potentially affects a variety of software. Systrace (which runs on Linux, NetBSD, OpenBSD, Darwin, etc) was given as one example of software that is affected. Even Sun's Dtrace might be vulnerable.

This is exactly why I love OpenBSD!

The very fact that the OpenBSD project makes itself such a huge target for would-be hackers is what makes it almost certain that any vulnerabilities will be found and patched. No handwringing is necessary here, though quite a lot of recoding may be involved. We can all look forward to an even more secure OpenBSD very soon. Keep up the good work, everyone!

Am I missing something?

Am I missing something?

Isn't it well known that you should not validate some data that the user might still be able to modify? That's security 101.

What's the problem with copying parameters to some memory space that the user can't reach, like the system heap? Surely moving a few bytes isn't going to be a big performance hit, compared to the time it takes to validate parameters.

OpenBSD's man page for systrace mentions this?

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 [openbsd.org]

m0n0wall /pfsense?

hey could someone do me a favor and tell me if m0n0wall or Pfsense ... are vulnerable to this?

The quick explanation

This is actually a long-known kernel problem, namely that once you have threads, you can't rely on user buffers to remain constant. So you MUST copy the buffers into kernel space ONCE, and validate and trust only the copy.

If you validate and trust the user buffer, a second thread sharing the same address space can change the buffer between the two steps, leading to trusting invalid data, which leads to Bad Things.

But some applications are trying to "wrap" system calls, validating the parameters before letting the system call proceed, and they're running into the same problems. It's more of a challenge for a wrapper, because there's no "safe" place to copy the parameters to.

In any case, this is not a kernel vulnerability, but an overoptimistic application vulnerability.

OpenBSD record: Good

The only meaningful bug they had lately was the IPV6 mbuf. And even that one obviously affected only people using IPv6.

This race bug was known for ages. It's even hinted in the man page. Stop the FUD.

Sysjail is really just one guy

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 [nycbsdcon.org] 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.

Don't use dev tools as security tools...

...that's essentially what the presenter is saying. The 'chroot' style jail is essentially a fake system root designed for development purposes, so you can have a little fake clean-room environment in which to build. Later, this concept was adapted for security purposes -- hence systrace, sysjail... What he's suggesting is that this userland approach is easily circumvented, and the best approach would be to use a mandatory access control approach at the kernel level, ala SELinux. To me, it's not so much that these programs are vulnerable as they are ineffective as security tools. I'm glad this is getting some publicity and opening a few eyes. Not to say that SELinux is the do-all end-all be-all of security, rather that false security is sometimes worse than no security.

Undeadly coverage

Coverage on Undeadly [undeadly.org].

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.

Systrace.org post on this alleged bug

http://www.systrace.org/index.php?/archives/14-Eva ding-System-Sandbox-Containment.html [systrace.org]

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.

Re:so much for...

I'm scared when something complex has no patches. Then again I'm more scared when something complex has a LOT of patches.

Re:so much for...

Why didn't you just say "I'm scared." ?

Re:so much for...

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

Re:so much for...

On my list of the 10 best OSS projects, OpenBSD is in the top 5.

In other words... it's in your list of the 5 best OSS projects.

(sorry)

Re:fix shedules ?

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

Re:fix shedules ?

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.

Re:Why???

Why is everyone so hell bent on BREAKING things? Can't we all just try to get along for an instant?

Because the fastest way to learn about something is to break it. Why do you think physicists spend all that time and money on particle accelerators?

Re:no

What if you can get a user shell by using an exploit in (firefox|x-chat|bind|apache|ftp|ssh|sendmail|ntp|w hatever open port)?
Guess you get what you deserve when you put a machine on the internet.

Sure it is only an unprivileged local user, what could you do with that.

Oh, wait. You could get root if you had a local user using an other exploit.

Re:no

Exactly, why would anyone want to put a computer on the internet? That's just stupid!

Re:no

Why? Isn't that what multiuser networked operating systems are for?

Re:no

these are exploits for a local user on system, anyone who puts a machine on the internet and lets people log into actual Unix accounts deserves what they get.

Unless of course they did it because they live in the real world and actually practical requirement needing that to be done.

While we're disabling any form of shell access for any reason whatsoever, why not stop all those HTTP servers as well and the SMTP, DNS and all that crap as well. After all anybody who dares expose such a system on the internet when history tells us that there will be new vulnerabilities found in those software is obliviously an idiot.

Re:What should individual users do

The workaround is very complex. Send your IP and root password to [e-mail] and I'll take a look at your system to help make recommendations.

Rumours of *BSD Death Premature

Hi,

The rumours of the death of *BSD systems are overblown and premature. The so called facts from the above "anonymous coward" are not facts at all but simply an opinion expressed by someone with an agenda.

If you don't use *BSD why would you care if it's living or dying? Why would you care if it's increasing in market share or declining?

The "anonymous cowards" opinions are irrelevant and likely incorrect anyhow. OpenBSD, NetBSD and FreeBSD are viable systems that have user communities that use them. It's not relevant how large those communities are.

In fact the so called Linux community isn't one community after all since there are reportedly over 300 distributions of systems that use the Linux kernel. So it's really *Linux and each of those distributions would break down to similar small groupings of users.

If your system works for you use it. If it doesn't, then adapt it or choose one that is better suited.

Re:How vulnerable are Java apps, and why?

Let me know when Java applications under the Sun JRE will run as responsive as C, Delphi, C++ applications do or better on the current people's commodity hardware -- WinXP + 256MB RAM + Resource intensive anti-virus software.

And before anyone mentions, no, I'm not interested on benchmarks done on multicore, 12GB RAM machines.

Re:The beauty of open source

That only works up to the exact number of users who are both able to read code, and understand it, which is a smaller number than the total user count probably by quite a bit.

The advantage is that users are ABLE to find things like security problems if they look, because the source is open. That doesn't guarantee they will find things, but you can see that it is at least possible.

Re:The beauty of open source

Speaking only for myself, access to source code has let me identify new vulnerabilities a lot faster than black box testing. Easier discovering? Yes. But that doesn't mean the bugs will be reported (I gave up -- too many arrogant programmers that aren't as smart as they think they are), the code fixed, or the users updated.