“Most serious” Linux privilege-escalation bug ever is under active exploit • Hacker News Board

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#191

Post by snvzz » Fri, Oct 21, 2016, 4:02 PM UTC

pjmlp wrote: post #178

snvzz wrote: post #171

Earlier quoted context omitted.

> C, due to arrays, strings, arithmetic operations and memory allocations requiring unsafe code leads to 100% unsafe code across the existing code. Imply is just slightly too harsh. Writing safe C code is very possible, as proven by projects such as seL4 or engineers such as djb.

Those projects had to constrained themselves to having 100% of the code available, no binary libraries and lock the compiler versions being used. Since the early 90's I keep hearing that it is possible to write safe C code, yet outside in the real world, unless constrained by processes like MISRA-C and Frama-C, which isn't really C anymore, it never works. The proof is the amount of CVE exploits, that get reported al…

OSX is pretty bad as they go.

MACH based hybrid kernel garbage.

A shame, considering Apple actually has the resources for doing a proper rebase of XNU on L4 and with actual pure microkernel multiserver architecture.

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#192

Post by AstralStorm » Fri, Oct 21, 2016, 5:12 PM UTC

startling wrote: post #60

tptacek wrote: post #24

Earlier quoted context omitted.

Those people might be right. Defense in depth is a legitimate tactic, but that's all it is, and it's often an excuse for people to waste time layering stupid stuff on top of real security controls. ASLR, NX, and CFI would be an example of a defense in depth stack that is meaningful. SSH, Fail2Ban, and SPA would be an example of a defense in depth stack that basically just wastes time. I would be more comfortable with…

Sure, it can go either way. But in the absence of a kernel 0-day, segregating services on the same host is useful.

And if a kernel 0-day is available, putting the services in a VM might help. Depending on whether an exploitable bug in the hypervisor exists.

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#193

Post by AstralStorm » Fri, Oct 21, 2016, 5:17 PM UTC

snvzz wrote: post #152

kentonv wrote: post #114

Earlier quoted context omitted.

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…

> This particular bug is in the memory management system, which is one of those things that kind of has to be in the kernel. Not really. L4 family (the post-Liedtke world) and Minix3 both have MM out of the kernel.

A privilege escalation in MM daemon would still allow you to write and read any user memory. Just not kernel memory or execute anything not covered by memory access capabilities. For nearly all intents and purposes, it is root.

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#194

Post by AstralStorm » Fri, Oct 21, 2016, 5:20 PM UTC

kentonv wrote: post #115

aexaey wrote: post #2

CVE-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…

Ptrace is not needed for an exploit, you only need to be able to mmap a file. Does not even have to be writable.

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#195

Post by jabl » Fri, Oct 21, 2016, 5:53 PM UTC

dozzie wrote: post #175

jabl wrote: post #135

Earlier quoted context omitted.

A HPC center (that is, lots of users coming in via ssh) I know about disabled key logins IIRC due to some incident where an attacker had got hold of a password-less key. Too bad that sshd can't enforce use of password-proctected keys on the server side..

You got the thing backwards. It's not "too bad that sshd can't enforce keys" of some property that happened to be missing in the key attackers got their hands on. It's "too bad the HPC center staff didn't have tools good enough to manage their servers". CFEngine and Puppet being two examples of such tools the staff missed (or didn't know how to put into use in this case).

The problem, AFAIU, was that some user had a password-less key stored on some external system (their personal home computer, for all I know). That system was hacked, and allowed the attacker to access the HPC system. I don't see how the HPC center staff getting the Puppet-gospel could have prevented that person from using a password-less key. Well, except by disabling key-based logins (which, AFAIU, they could have used Puppet/cfengine/whatever for).

My point is that in general it would be better to disable password auth and only use key based auth, but only if you could somehow guarantee that the users wouldn't do crazy things like use password-less keys. But as you can't do that on the server-side, what other options do you have?

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#196

Post by dozzie » Fri, Oct 21, 2016, 6:10 PM UTC

jabl wrote: post #195

dozzie wrote: post #175

Earlier quoted context omitted.

You got the thing backwards. It's not "too bad that sshd can't enforce keys" of some property that happened to be missing in the key attackers got their hands on. It's "too bad the HPC center staff didn't have tools good enough to manage their servers". CFEngine and Puppet being two examples of such tools the staff missed (or didn't know how to put into use in this case).

The problem, AFAIU, was that some user had a password-less key stored on some external system (their personal home computer, for all I know). That system was hacked, and allowed the attacker to access the HPC system. I don't see how the HPC center staff getting the Puppet-gospel could have prevented that person from using a password-less key. Well, except by disabling key-based logins (which, AFAIU, they could have u…

> I don't see how the HPC center staff getting the Puppet-gospel could have prevented that person from using a password-less key.

It's about reaction of the staff to key leak:

>> A HPC center [...] disabled key logins IIRC due to some incident where an attacker had got hold of a password-less key.

This reaction seems just silly.

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#197

Post by JdeBP » Fri, Oct 21, 2016, 6:26 PM UTC

qwertyuiop924 wrote: post #156

i336_ wrote: post #97

Earlier quoted context omitted.

-F vs -f: -F figures out the new inode if the file is deleted (*notify are inode-based, if you see DELETE_SELF for a file you'll never get any more events)

...which actually does handle truncation properly. For some reason.

It's because IN_MODIFY covers both writing and truncation, so the code path for such an event has to handle both anyway.

Ironically, given that you mention M. Cantrill, GNU tail does not really handle truncation properly, and gives up for almost the very case that M. Cantrill did: when the truncation doesn't decrease the size, or is very closely followed by a write that ends up not decreasing the size.

Of course, truncation is not the best way to organize writing log files in the first place. daemontools family style log management (in cyclog, multilog, et al.) starts a fresh file whenever there is a rotation, so these problems of truncation never arise.

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#198

Post by qwertyuiop924 » Fri, Oct 21, 2016, 8:53 PM UTC

JdeBP wrote: post #197

qwertyuiop924 wrote: post #156

Earlier quoted context omitted.

...which actually does handle truncation properly. For some reason.

It's because IN_MODIFY covers both writing and truncation, so the code path for such an event has to handle both anyway. Ironically, given that you mention M. Cantrill, GNU tail does not really handle truncation properly, and gives up for almost the very case that M. Cantrill did: when the truncation doesn't decrease the size, or is very closely followed by a write that ends up not decreasing the size. Of course, tru…

What I was actually referring to was Cantrill's talk about tail -f on Solaris, and how he improved it (so that it at least handled some cases). He looked at the GNU behavior, and determined that truncation was noted, but nothing was done about it. This is true if you use -f. However, if you use -F, truncation is handled properly.

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#199

Post by kentonv » Fri, Oct 21, 2016, 10:27 PM UTC

AstralStorm wrote: post #194

kentonv wrote: post #115

Earlier quoted context omitted.

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…

Ptrace is not needed for an exploit, you only need to be able to mmap a file. Does not even have to be writable.

No, it's more complicated than that. You need one process to mmap a file, and then you need a second process to be writing into the first process's address space while the first process triggers the COW. You can't do it with one process attacking itself.

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#200

Post by abysmallyideal » Sat, Oct 22, 2016, 2:51 AM UTC

pjmlp wrote: post #164

snvzz wrote: post #161

Earlier quoted context omitted.

Sorry, can you restate that question? I'm not sure what you're asking.

A small TCB -> around 10% unsafe code. C, due to arrays, strings, arithmetic operations and memory allocations requiring unsafe code leads to 100% unsafe code across the existing code. A security minded person will pick those 10%.

haha, that safety stuff is just training wheels. You can't delegate security. Even if you use some baby-proof "programming language", as a security engineer you still have to verify that the safety works in the condition(s) you're programming for.