Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

131–140 of 218 posts

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

#131

Post by patio11 »

tptacek wrote: post #89
throwaway2048 wrote: post #80

Earlier quoted context omitted.

no, because a bug like this turns any code execution exploit into remote root...

The point is that code execution is almost always remote root, because lots of bugs like this exist. Also: most engineers overestimate the relative value of root vs. simple inside-the-VPC code execution, which is almost always gameover anyways.

Thomas has elaborated on this a few times over the years, but to elaborate for people who weren't around for those conversations: if you can make an HTTP request from inside the firewall, which probably doesn't require root, you can pivot the attack to a variety of internal services which are not designed with security in mind. That could let you e.g. reconfigure networking appliances, grab credentials to internal or external services from DevOps-y credential stores, grab all manner of business secrets, pivot to direct SQL access to the DB laundered through e.g. internal analytics dashboards or admin tooling, etc.

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

#132

Post by pas »

vbernat wrote: post #128
mjg59 wrote: post #33

Earlier quoted context omitted.

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.

To be fair, Docker now defaults to using AppArmor and seccomp too. And the defaults seem to be not completely toothless either (I had to "disable" seccomp to get things running multiple times. For example, you can't just ptrace() in a container.)

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

#133

Post by drieddust »

kentonv wrote: post #114
drieddust wrote: post #109

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

Yeah not sure what happened. Somehow I ended up looking at wrong article.

I am not very good at theory of Operating Systems but since Memory Management is separated from kernel it would have been difficult for a memory bug to impact other subsystems.

Another argument is modularity which would have allowed better testing hence lesser chances of bugs.

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

#134

Post by sheer_horror »

drieddust wrote: post #133
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…

Yeah not sure what happened. Somehow I ended up looking at wrong article. I am not very good at theory of Operating Systems but since Memory Management is separated from kernel it would have been difficult for a memory bug to impact other subsystems. Another argument is modularity which would have allowed better testing hence lesser chances of bugs.

Despite your erroneous reply, you still hit 4th most upvoted comment thanks to the pro-open source sentiment here.

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

#135

Post by jabl »

tptacek wrote: post #91
timtadh wrote: post #40

Earlier quoted context omitted.

I'm confused, how is SSH an example of defense in depth? It is an access method. You should absolutely harden your SSH configuration. Fail2Ban is useless on a properly configured SSH server (no root, no passwords, no kerberos, only keys). Managing the keys at scale, well that is a different story. I agree with you that ASLR, NX, and CFI are the most important system level defenses to employ.

SSH is fine. Stacking extra stuff on top of SSH to create a defense-in-depth stack for it SSH is what's silly. Just disable passwords and use SSH.

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..

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

#136

Post by frederikvs »

The github page [0] states that "The In The Wild exploit relied on using ptrace." Now, I'm wondering what purpose ptrace serves, aside from debuggers? Why don't we just disable this by default on production systems (where you shouldn't be debugging anyhow)?

[0] https://github.com/dirtycow/dirtycow.github.io/wiki/Vulnerab...

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

#137

Post by CUViper »

frederikvs wrote: post #136

The github page [0] states that "The In The Wild exploit relied on using ptrace." Now, I'm wondering what purpose ptrace serves, aside from debuggers? Why don't we just disable this by default on production systems (where you shouldn't be debugging anyhow)? [0] https://github.com/dirtycow/dirtycow.github.io/wiki/Vulnerab...

See the SELinux boolean "deny_ptrace", and/or the sysctl "kernel.yama.ptrace_scope", and have at it.

It's not just for debugging, but for any tool that needs some measure of process control. Probably the next most common ptrace-caller I know is "strace".

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

#138

Post by nixos »

tptacek wrote: post #91
timtadh wrote: post #40

Earlier quoted context omitted.

I'm confused, how is SSH an example of defense in depth? It is an access method. You should absolutely harden your SSH configuration. Fail2Ban is useless on a properly configured SSH server (no root, no passwords, no kerberos, only keys). Managing the keys at scale, well that is a different story. I agree with you that ASLR, NX, and CFI are the most important system level defenses to employ.

SSH is fine. Stacking extra stuff on top of SSH to create a defense-in-depth stack for it SSH is what's silly. Just disable passwords and use SSH.

sshd can have vulnerabilities which port-knocking can (temporarily) block.

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

#139

Post by pmuk »

ontoillogical wrote: post #58

At Appcanary, we're thinking about opening up our vulnerability database to be browsable and searchable by the public. If you're not sure which version has the patch for this vulnerability in your distro, here's what we know: Ubuntu - https://appcanary.com/vulns/45984 Debian - https://appcanary.com/vulns/45983 Amazon Linux - https://appcanary.com/vulns/45992 Centos - no patch yet If you found this useful, please let…

If you wanted to create a useful tool to promote yourselves you could make something for CentOS that allows a user to apply critical security updates only. yum-security doesn't seem to work on CentOS as the repos don't have the correct meta data. Currently that requires a satellite subscription.

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

#140

Post by nixos »

hueving wrote: post #52
mjg59 wrote: post #33

Earlier quoted context omitted.

Given qemu's security track record, they're not necessarily wrong.

Even if they break out of qemu, then the best case is they've reached the level of the container or user running it.

Which is mostly root. Rootless containers are still not widely deployed
Post reply on HN