| |||||||||||||
Remote root hole in SambaRemote root hole in SambaPosted Apr 11, 2012 12:11 UTC (Wed) by euske (subscriber, #9300)In reply to: Remote root hole in Samba by loftsy Parent article: Remote root hole in Samba
OpenSSH people try to contain this kind of bugs by outsourcing a complex part to a chroot jail, though I'm not sure if the same technique can apply to this case here.
(Log in to post comments)
Remote root hole in Samba Posted Apr 11, 2012 15:45 UTC (Wed) by raven667 (subscriber, #5198) [Link]
Samba has a similar separation, there is a root daemon but each authenticated user gets their own fork of the process running as their own user ID. A security issue in that part would only allow them to access their own account. It also allows samba to use the host systems permission infrastructure natively since the OS knows who the file access is for, different than say Apache which has to maintain its own internal idea of users and permissions above the OS.
Clearly there is still a significant amount of SMB which needs to be run as root though.
Remote root hole in Samba Posted Apr 11, 2012 16:00 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
chroot jails are leaky and insecure, even in OpenBSD. If you manage to start arbitrary code in a chroot jail then you practically own the machine anyway.
Remote root hole in Samba Posted Apr 11, 2012 16:15 UTC (Wed) by cmccabe (guest, #60281) [Link]
> chroot jails are leaky and insecure, even in OpenBSD. If
> you manage to start arbitrary code in a chroot jail then > you practically own the machine anyway.
I've never heard anyone say this before. What makes you think that chroot jails are insecure in OpenBSD? Especially when the process being jailed does not run as root.
Remote root hole in Samba Posted Apr 11, 2012 16:20 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Programs in OpenBSD chroot have access to all the syscalls. Probably at least several of them are vulnerable.
It's just that nobody really cares about OpenBSD a lot to search for vulnerabilities there.
Remote root hole in Samba Posted Apr 11, 2012 16:49 UTC (Wed) by drag (subscriber, #31333) [Link]
> Programs in OpenBSD chroot have access to all the syscalls.
You'd have to use systrace in conjunction with chroot in OpenBSD to properly sandbox applications. That way you can restrict what type of syscalls can be used.
Remote root hole in Samba Posted Apr 11, 2012 17:17 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Systrace (as all other generic syscall wrappers) is vulnerable to concurrent attacks.
Remote root hole in Samba Posted Apr 14, 2012 20:37 UTC (Sat) by andres (guest, #83358) [Link]
Your last two posts in this thread clearly show you have no idea what you're talking about.
systrace is only "vunerable" to TOCTOU/TOATOU if your policy involves checking pointer arguments.
systrace policies such as ssh's block entire syscalls outright; they don't check arguments. As such, those policies are not vulnerable.
Remote root hole in Samba Posted Apr 11, 2012 23:42 UTC (Wed) by cmccabe (guest, #60281) [Link]
If you have proof that any of the system calls in OpenBSD (or Linux, for that matter) are vulnerable, then you should post it. If not, I'm afraid this is starting to sound like FUD.
Remote root hole in Samba Posted Apr 12, 2012 0:03 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
I'm absolutely sure that at least some of them are buggy. I can bet you $1000 that there'll be new local Linux kernel exploits within 2 years.
Remote root hole in Samba Posted Apr 15, 2012 17:23 UTC (Sun) by cmccabe (guest, #60281) [Link]
First of all, we were talking about OpenBSD, not Linux. Secondly, if you're so sure that "some of them are buggy", you should find out which ones. I'm sure that the reward will be a lot greater than $1000.
I think what may be confusing you is the fact that there have been a lot of privilege escalations in Linux over the years (although not in OpenBSD, which is what we were talking about-- remember?). However, most of those privilege escalations didn't involve insecure system calls. In fact there's only one that I can think of which did (maybe others can think of more).
Remote root hole in Samba Posted Apr 15, 2012 20:58 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>First of all, we were talking about OpenBSD, not Linux. Secondly, if you're so sure that "some of them are buggy", you should find out which ones. I'm sure that the reward will be a lot greater than $1000.
I'm absolutely sure that Linux right now has multiple exploitable local vulnerabilities.
>However, most of those privilege escalations didn't involve insecure system calls. In fact there's only one that I can think of which did (maybe others can think of more).
Whut?
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0029
It's like a clockwork! At least one local exploit a year.
Remote root hole in Samba Posted Apr 15, 2012 23:48 UTC (Sun) by spender (subscriber, #23067) [Link]
Don't forget perf_counter() ;)
Remote root hole in Samba Posted Apr 19, 2012 20:46 UTC (Thu) by cmccabe (guest, #60281) [Link]
Let's look at the orignial post that started this thread.
> Programs in OpenBSD chroot have access to all the syscalls.
Now we've digressed into looking at a bunch of Linux (NOT OpenBSD) security flaws. How does this help you prove that OpenBSD is insecure?
Secondly, privilege separation, BSD jails, SELinux, ASLR, etc are still useful technologies even if they don't block 100% of exploits. I think most system administrators would consider being vulnerable to one exploit per year a VERY good record, for any of the major three platforms.
Remote root hole in Samba Posted Apr 11, 2012 16:42 UTC (Wed) by drag (subscriber, #31333) [Link]
> I've never heard anyone say this before. What makes you think that chroot jails are insecure in OpenBSD? Especially when the process being jailed does not run as root.
I don't think that using chroot adds any insecurity over just running the process as a user, but it's important to keep in mind that chroot was never intended or designed to be a security mechanism.
Saying that chroot in OpenBSD is insecure is a bit like saying that home made cardboard gas tanks for cars have inadequate protections against leaks and fires. Sure both statements are absolutely true, but that is only because they are being used in ways never intended to by their original designers.
This is why we have BSDJails, Solaris containers, and LXC to do things properly.
|
|||||||||||||