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."
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.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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.
Oolite: Elite-like game. For Mac, Linux and Windows
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!