So the escalation is rw access to privileged files, are LXC and Docker container breakouts prevented then? Also does /proc access through lxcfs or Docker's handling of /proc make any difference?
“Most serious” Linux privilege-escalation bug ever is under active exploit
121–130 of 218 posts
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#122Earlier quoted context omitted.
>assume that code execution on your Linux systems equates to privesc Tell this to the container community. They would have you believe containers are as secure as VMs.
Given qemu's security track record, they're not necessarily wrong.
It's always a matter of increasing attacker cost. I am not sure that attacking QEMU, then finding a privilege escalation on the host that can break out of SELinux is much easier than just staying in the VM, hopping through the internal network until you find a host that lets you do what you want.
Chances are what you want is "simply" access to a shared folder rather than root.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#123CVE-2016-5195 This flaw allows an attacker with a local system account to modify on-disk binaries, bypassing the standard permission mechanisms that would prevent modification without an appropriate permission set. This is achieved by racing the madvise(MADV_DONTNEED) system call while having the page of the executable mmapped in memory. Excellent example why mounting partition with system binaries (such as /usr) rea…
As others have pointed out, mounting read-only wouldn't have helped here. What would have helped: * Block ptrace() syscall using seccomp. * Don't mount /proc, or mount it read-only. As I understand it, those steps would close all attack vectors for this bug. FWIW, the Sandstorm.io sandbox blocks ptrace() and doesn't mount /proc at all, so I think the bug has never been exploitable by Sansdtorm apps. (Disclosure: I am…
* don't let network services mmap (or even open!) random executables through mandatory access control (SELinux)
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#124>However that's hard to do when the vast majority of kernel bugs come from vendor drivers, not the upstream Linux kernel, Stoep said. Doesn't this actually validate Andrew Tannenbaum's argument[1] over 25 years ago when he said monolithic operating systems are inherently insecure and a rethink is required. [1] https://groups.google.com/forum/m/?fromgroups#!topic/comp.os...
Looks like you are quoting from: http://arstechnica.com/security/2016/09/linux-kernel-securit... While it's true that vendor drivers living in kernel space is horrible for security... that's somewhat offtopic here. This particular bug is in the memory management system, which is one of those things that kind of has to be in the kernel. A microkernel architecture seemingly would not have helped in this particular case…
seL4 does not have these kinds of errors. By shrinking the TCB, you make it possible to do hardcore verification. The challenge is in extending to larger systems and composition.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#125Earlier quoted context omitted.
It's sad actually that this is the perfect type of exploit to block with SElinux, a simple write to unauthorized files. But since no one uses the user contexts of selinux then no one blocks this. Your shell runs unconfined because your user role is unconfined. Any process you might start will therefore run unconfined, unless stated otherwise in a policy. So this exploit will run unconfined and will be allowed writes…
> Your shell runs unconfined because your user role is unconfined. Any process you might start will therefore run unconfined, unless stated otherwise in a policy. I am actually surprised that sane and safe defaults are ignored and left to user's discretion. Most users think Linux is secure by default. It's interesting to see Windows going into other direction and locking down more and more by default.
Well it's an ongoing effort in Fedora too. Every release of fedora or centos show some improvement around the user of SElinux.
I only wish I had the competence to help out because I think it's a very important effort.
Sad to say that in Fedora 23 I was able to easily put my user into the staff_r role, and thereby confining it. But in fedora 24 there seem to be only three default user contexts defined. Not sure what happened but that likely means I have to define my own user context and then I can't know how well supported it is in the policy.
It's impossible for ordinary users to do any of this.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#126Cool, this will be great for rooting Android phones to fix this and other security bugs!
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#127>However that's hard to do when the vast majority of kernel bugs come from vendor drivers, not the upstream Linux kernel, Stoep said. Doesn't this actually validate Andrew Tannenbaum's argument[1] over 25 years ago when he said monolithic operating systems are inherently insecure and a rethink is required. [1] https://groups.google.com/forum/m/?fromgroups#!topic/comp.os...
While it is in part true, no amount of band-aid solutions will fix the issue of using C.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#128Earlier quoted context omitted.
>assume that code execution on your Linux systems equates to privesc Tell this to the container community. They would have you believe containers are as secure as VMs.
Given qemu's security track record, they're not necessarily wrong.
That's a bit unfair since:
1. Most users won't be affected by all the exploits (you don't stuff in a VM all models of network cards, SCSI controllers, etc)
2. Many deployments of QEMU (through Xen or Libvirt) are protected by AppArmor/SELinux. This would at least forbid access to /proc/self/mem but I can't say if this is enough to prevent evasion. IMO, this is likely to make the task quite harder.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#129It's probably the most serious Linux local privilege escalation ever. Look, the Azimuth people have forgotten more about reliable exploit development than I have ever known, but, no, as stated, this is clearly not true. Not long ago, pretty much all local privesc bugs were practically 100% reliable. What I think they mean to say is that this is unusually reliable for a kernel race. I still think, though, that the rig…
I agree. There have been far easier local exploit in the past. For example CVE-2006-2451 whose exploitation was quite simple and not using any race condition. Also CVE-2009-2692 or CVE-2010-3049. Browsing exploit-db makes it easy to find them.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#130Earlier quoted context omitted.
A link would be appreciated. The text is truncated at N columns on mobile.
https://github.com/dirtycow/dirtycow.github.io/wiki/Vulnerab... and scroll up a bit. If you have an iPhone you can scroll horizontally even if it doesn't look like you can (though I am also annoyed by HN truncating the text)
It's not that you can't scroll, it's just very tedious to scroll back and forth each and every line.