Slashdot Log In
Cambridge Researcher Breaks OpenBSD Systrace
Posted by
kdawson
on Thu Aug 09, 2007 09:19 AM
from the without-a-trace dept.
from the without-a-trace dept.
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."
Related Stories
Submission: OpenBSD's Systrace broken by Cambridge researcher by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
SELinux and the same ... (Score:5, Informative)
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 ... (Score:5, Insightful)
Parent
Re: (Score:3, Informative)
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.
Re: (Score:3, Informative)
Linux?` (Score:3, Insightful)
Re:Linux? (Score:3, Informative)
Read his blog post, as some of the techniques described are quite interesting. Too bad we can't read the full paper.
Re:Linux? (Score:5, Informative)
Parent
Re:Linux? (Score:4, Interesting)
(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.)
Parent
No need for alarm! (Score:5, Funny)
Re:No need for alarm! (Score:5, Funny)
All twelve of them. :)
I like the thought of openbsd, though, having never used it. I'm sure everything will be fine.
Parent
Re: (Score:2)
The majority of my machines run Gentoo, but Gentoo can't really by used as a fire-and-forget platform like OBSD can be.
Re:No need for alarm! (Score:5, Funny)
We yell really loud.
(And I actually yelled "Wow!". We're not a homogenous lot.)
Parent
Re: (Score:2)
OpenBSD will never have the popularity or wide range of ports that FreeBSD has but it's a pretty solid system designed with a clear mandate. It's worth installing, even just to see the security decisions that have been taken so you can apply them to another Unix-like system. Like Dan Ost said, the documentation is excellent and the developers and mailing list users have been pretty helpful. The only thing I'm missing is WPA support.
why give much of a crap (Score:3, Informative)
Re:why give much of a crap (Score:5, Insightful)
If you allow scripting on your server, then you've essentially given your users shell access, anyway.
Parent
Re: (Score:2)
OpenBSD Security (Score:4, Funny)
As long as I'm dreaming, I also want a pony.
Re: (Score:3, Funny)
You mean like, put it in a convent [wikipedia.org] or something ? Oh no, I get it, you mean he should build a little chapel in memory of it, right ?
No released version of sudo affected (Score:5, Informative)
- todd
Code isn't up (thank goodness) (Score:2)
Ha Ha (Score:5, Funny)
$#%#^&&!#$@$
[CONNNECTION LOST]
Brace for impact... (Score:5, Funny)
Re: (Score:2)
"cambrige researcher"... (Score:4, Informative)
This is exactly why I love OpenBSD! (Score:5, Insightful)
OpenBSD's man page for systrace mentions this? (Score:5, Informative)
OpenBSD's systrace manpage appears to mention this problem in the BUGS section:
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]
Sysjail is really just one guy (Score:3, Informative)
Undeadly coverage (Score:4, Informative)
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.
I'm not worried (Score:3, Funny)
Re:I'm not worried (Score:5, Funny)
Parent
Re: (Score:2)
I prefer a boast like "Nothing to escalate" than "Secure by default"
Re:I'm not worried (Score:4, Funny)
Parent
Re: (Score:2)
Re: (Score:3, Informative)
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. Alternati
Re:so much for... (Score:5, 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...
Parent
Re: (Score:3, Insightful)
Once someone has the power to execute arbitary code on your system, then it is arguably only a matter of time before they can do what they please on it. Which is precisely why you don't use the same OpenBSD box for your firewall as you do for giving users a shell account on a Unix box.
Re: (Score:3, Insightful)
I can also publish a root password for my servers on digg. Does that mean it's OpenBSD's fault for that 'exploit' as well?
The purpose of the default install is a configuration that has been audtied by _the_ most anal development team on the planet. This is nothing but a good thing, and if people have a problem with Theo's attitude, feel free to fork the codebase.
On my list of the 10 best OSS projects, OpenBSD is in the t
Re:so much for... (Score:5, Funny)
In other words... it's in your list of the 5 best OSS projects.
(sorry)
Parent
Re: (Score:3)
This is just another piece of audited code that roots you.
Re:so much for... (Score:5, Funny)
Parent
Re: (Score:2)
Re: (Score:2, Insightful)
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 (Score:5, Funny)
Parent
Re: (Score:2)
Re: (Score:3)
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:fix shedules ? (Score:4, Informative)
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).
Parent
Re:fix shedules ? (Score:4, Informative)
Parent
Re:Why??? (Score:5, Interesting)
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?
Parent
Re: (Score:2)
Re: (Score:3, Funny)