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
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...
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.
I'm scared when something complex has no patches. Then again I'm more scared when something complex has a LOT of patches.
Why didn't you just say "I'm scared." ?
I hate printers.
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...
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...
Because sometimes I guess the patch level is "just right"?
Curiosity was framed, Ignorance killed the cat.
...and he's also one of the most important FreeBSD hackers.
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.
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.
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.
Exactly, why would anyone want to put a computer on the internet? That's just stupid!
Would you be talking about this?
Why? Isn't that what multiuser networked operating systems are for?
Give me Classic Slashdot or give me death!
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.
Then choose a better FTP server - it's not OpenBSD's fault you installed pr00tme-ftpd.
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 top 5.
Website Hosting
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!
[Fuck Beta]
o0t!
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.
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)
OpenBSD auditing isn't the god of all auditing you think it is.
This is just another piece of audited code that roots you.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
actually, no, if you're providing services for untrusted users. the user authenticates to and uses a service, but never to machine account to possibly run code on the machine. Local users ALWAYS can mess up a machine, there's no end to the ways they can do it.
It's a marketing slogan, of course it's silly. "Only two remote holes in the default install, in more than 10 years!" means about as much as "99 44/100 percent pure."
Give me Classic Slashdot or give me death!
If someone has need for a local account on a machine or any ability to run arbitrary code you're in the same realm as company hiring employee and trying to verify if they are trustworthy or not. Local user can always cause problems if they so choose. Just like anyone with physical access can cause even more problems.
The workaround is very complex. Send your IP and root password to pwnd@dodgeit.com and I'll take a look at your system to help make recommendations.
Check out my lame java blog at www.javachopshop.com
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.)
"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"
It'll be interesting to see what the tradeoff is: does the system become more vulnerable overall by using the vulnerable software, or less? Has the layer of security it was supposed to add become another exploit path that's worse than what it was supposed to protect against?
My off-the-cuff inexpert guess is that it will still be valuable for some limited situations, but that in many cases it'll reduce the overall security of the system. I'm looking forward to hearing more from the various teams involved.
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
Just because you are not paranoid does not mean they are not out to get you.
That's one of the things that bugs me about OpenBSD: the ludicrous distinction between local and remote root exploits.
... but that's okay, this is just a local hole, right?
Yeah, maybe you've got some ultra-locked down OpenBSD machine that doesn't actually do anything, but for most users, that latest phpBB bug that you ignored? It just effectively made the latest local kernel exploit a remote hole. For almost all users, the differentiation between local and remote holes is blurry at best. Minor vulnerabilities can and will be chained together to create a big problem.
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.
Well, if I'm understanding the exploit properly, and the purpose of systrace, I can see both for and against. It's essentially there to allow an application to run at least privileges unless it wants to access a specific resource, and then to only be promoted for the duration of that request. The alternative to this is to run an application with elevated (normal in the case of most applications, few require root) privileges all the time. Now, depending on how the privilege escalation is implemented, this is either harmless, or very dangerous. If they promote to a level required to access a resource based on the initially granted status, this isn't bad as the program would only have permissions to access what it normally would be allowed to anyway, you just get less warning because you won't get a popup if it tries to access something it still has permission to, but which is unexpected based on its access policy. If on the other hand, it's promoted to maximum privilege whenever the request is approved this is very dangerous because it could for instance request permission to modify some innocuous file, then change it after the fact to modify /etc/passwd.
Curiosity was framed, Ignorance killed the cat.
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.
In other words... it's in your list of the 5 best OSS projects.
(sorry) Mod parent up! In security related topics nitpicking is encouraged. No apology needed.
PS: Can we have the list please? They are always interesting and provide good flamewar material.
well-played old chap.......... ;)
Website Hosting
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.
...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.
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.
Change is certain; progress is not obligatory.
You ruined his build up!
It's not just in the top thousand OSS projects. It's not only in the top hundred. It's not even just in the top ten OSS projects. It's in the TOP FIVE! Not only does it have ls, cat, grep and sed, if you order within the next 5 minutes we'll even throw in openssh free!
If I have seen further it is by stealing the Intellectual Property of giants.
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.
Let's be reasonable about this for a moment.
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.
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.
One could write a virus in Java too.
Not quite, but certain very common anti-virus software is quite intensive.
Most resident scanners scan for patterns against their virus databases in active memory. It's rare that heuristic scanning picks up unique viruses.
The anti-virus scanner can block known viruses. The Sun JVM doesn't have such functionality. In theory Java is great, because the user gets a dialog on applets/webstart applications to run the application. However, there have been many certificate vulnerabilities with the JVM, there have been vulnerabilities related to executing unsigned java code by the use of certain java bytecode etc.
Well, this isn't a direct comparison since the code in both of these programs is substantially different but, just looking at some well known programs like utorrent + anti-virus verses Sun JVM + Azuerus, kdevelop (the recent kde related port) verses Sun JVM + netbeans etc. I find the java applications slower responding.
In what cases can I see it's slower? I can see the UIs redrawing, I can see the mouse clicks aren't being handled instantly, I can see the application just freezes somewhat unlike my other applications.
That said, I have seen benchmarks that show reads and writes are faster in Java compared to a C application, but in reality, that's just a small thing for me.
If I find that I can run things like utorrent, kdevelop (with all those kde libs) and anti-virus software without noticing these issues verses the java applications alone, with the anti-virus software disabled... I still notice all the redrawing, latency in my clicks. That in my opinion is not good enough.
Can't say the experience has been the same for me. I've messed with Java since 1.1 to 6, I've used various jdks, messed with native java compilers (including those that convert java source to .net bytecode). The alternatives to Sun JDK are always too far behind to run the best/popular java applications I've come across... Freenet, Azureus, Netbeans (although notably, netbeans doesn't run too bad on Sun JVM -- I just notice the UI redrawing).
Memory arguments are somewhat pointless, I could write software to compress data in memory to keep the memory usage smaller, but the side effect is that the application could behave much slower due to this. While unnecessary things shouldn't be in memory, responsiveness on consumer hardware from the interface is far more important.
Too often I see other Java developers, who tell users that their applications are not slow and there is nothing wrong with them, they get these results on their beefed up machine (quite normal for a developer, but bad for testing certain cases if your end user are common people who have 256MB ram, windows xp, crappy intensive anti-virus and who knows what else).
Even now, I look at one of my little side projects under the latest Sun jvm6, verses Sun jvm1.4... I can see clearly there is a lower framerate with i
Change is certain; progress is not obligatory.
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.
In other words... it's in your list of the 5 best OSS projects.
(sorry)
In other words ... it's at number 5. (If it was at number 4, he would have said is in the top 4, etc.)
JP