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."
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.
Quidquid latine dictum sit, altum videtur
Any word if any of these vulnerabilities affect Linux or other Unixes as well?
My blog
Offensive Technology
Microsoft Windows?
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...
...Only two remote holes in the default install, in more than 10 years!
It's unfortunate too tho, considering that OpenBSD is heralded as one of the most secure *nix's around. Looks like it's patch time for many.
This is not the greatest
The article says that vendors have been given 6 months - several years notice.
Does anyone know what OpenBSD has done, or what individuals who use OpenBSD should
do in light of this article? Specific instructions please!
I'm not worried about a vuln. in sudo; I always log in as root and don't have sudo running :). Remember, Real Programmers log in as root. Take that h4x0rz!
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
The tremors that you are feeling are from the sounds of the collective users of OpenBSD all simultaneously shouting "Fuck!" in exasperation.
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.
on local user/software exploits? my domains have over a thousand users, but no one logs into an account on the machine.
... 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.
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
It appears he's removed the code from the presentation (though it still says it's present, I don't see it). Good.
www.voiceofthehive.com - Beekeeping and Honeybees for those who don't.
Sweet justice! My Win98 boxes have finally protected me against a hole. I am invinci*^&#%
$#%#^&&!#$@$
[CONNNECTION LOST]
Well, there's spam egg sausage and spam, that's not got much spam in it.
Theo DeRaadt goes on a rampage in 5... 4... 3... 2...
Mmmm.... fanboys.
I want to lick them all over.
anyone know how or when these things are supposed to be fixed ?
as usual I would assume *bsd to put out fixes quite timely...
...and he's also one of the most important FreeBSD hackers.
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)
Site is slashdotted, anyone got a copy of the article?
--- "When you gotta do something wrong. You gotta do it right. (Fighter)"
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?
Curiosity was framed, Ignorance killed the cat.
This is frickin' stupid. Nice try at ripping off the CARRIER LOST template, but you should at least copy and paste it if you don't understand where it came from.
Would you be talking about this?
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.
In other news, no but middle managers cares what Netcraft has to say about OS usage.
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!
I know what supposed to be behind this roof!
It's a view of my City!
I'm not kidding, picture taken from http://en.wikipedia.org/wiki/Chillon looking at my City http://en.wikipedia.org/wiki/Montreux
It's freakin' Swiss Day on slashdot or what ? next article is going to be about a red cross on a white flag... oh wait
USENIX Workshop On Offensive Technology spells umm... woot?
;)
*checks the date*
well, it's not April 1st
Failure during Cern magnet test :-)
I thought the beauty of open source was that the code was constantly reviewed by a million eyes so that bugs like this would either never occur or would be discovered quickly (rather than years after the fact). I guess that was complete bullshit.
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.
Correct. I only found the link after surfing to his web site.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
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
http://op59.net/
hey could someone do me a favor and tell me if m0n0wall or Pfsense ... are vulnerable to this?
actually I am happy to see you, however that is in fact a banana in my pocket.
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.)
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?
For a second on reading that, I saw "psychologists" instead of "physicists." Gave a very different meaning...
Thank God for evolution.
I see, very interesting... and what does this inkblot look like to you?
Curiosity was framed, Ignorance killed the cat.
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.
So... how do you patch your system without escalating from a normal user?
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Hey, asshat! In case you missed it, the vulnerability affects Windows anti-virus products, too.
This race bug was known for ages. It's even hinted in the man page. Stop the FUD.
It would be nice if the parent comment (or a link to it) was placed in the article summary. The sudo application and the above comment dismissing concern over current releases is probably important enough to warrent this.
:)
Thanks
umeboshi (not logged in)
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.
Somewhere in a lonely hospital room, *BSD is dying.
"BSD? It's dead, Jim . . . "
Sweet justice! My Win98 boxes have finally protected me against a hole. I am invinci*^&#%
$#%#^&&!#$@$
[CONNNECTION LOST]
...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.
Working in a DevOps shop is like playing in a band made up entirely of keytarists.
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.
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.
I posted a blog entry about how this applies in Java, with source code, examples of exploits, and an explanation of how Java generally avoids this problem, and another idea of how it could be avoided outside of Java.
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.
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.
Do you even lift?
These aren't the 'roids you're looking for.
Well, to be entirely honest, because it's the only way we know how. If we knew a better, cheaper, or faster way, we'd use that, I'm sure. That's not to say that I don't think there is something cool about building the next generation of bigger and more complex detectors, but the conventional wisdom is that after CMS and ATLAS, no one would fund another generation of even bigger accelerator rings and accompanying detectors, so if particle physics has anything left to figure out, they'll have to try one of the newer techniques (wakefield accelerators? ::shrug::).
Or CLIC or ILC etc. Well, I ain't complainin', it's a great way to spend government money. And the way I see it, not only does it keep us all in jobs, it's more money that the Illuminati will never be able to use to further immanentise the eschaton.
Its not a whopper of a hole. Systrace isn't used by anything by default, its a tool you have to configure specifically on a per app basis for that app. And this "vulnerability" has been documented in the systrace man page for years. Systrace isn't supposed to be used for a false sense of security, its supposed to be used for things like stopping poorly written configure/make messes from writing things to places they shouldn't while working on ports.