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

51–60 of 218 posts

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

#51

Post by simcop2387 »

tptacek wrote: post #24
startling wrote: post #21

Earlier quoted context omitted.

> "In almost all cases, whether or not there's a known local privesc bug, assume that code execution on your Linux systems equates to privesc; this is doubly true of machines in your prod deployment environment. It depends. I've seen "oh well if someone has rce they probably have root anyway" used way too many times as an excuse to avoid defense-in-depth measures.

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…

I know what everything else is, but what is CFI? An attempt at googling came up with results that didn't make any sense right away.

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

#52

Post by hueving »

mjg59 wrote: post #33
hueving wrote: post #27

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

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

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

#53

Post by hannob »

simcop2387 wrote: post #51
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…

I know what everything else is, but what is CFI? An attempt at googling came up with results that didn't make any sense right away.

Control-Flow Integrity. It's a bit of the new hotness in exploit mitigation, however it's quite complicated and there are various solutions that have different advantages and disadvantages. clang docs: http://clang.llvm.org/docs/ControlFlowIntegrity.html

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

#54

Post by winter_blue »

If one's running an LTS version of Ubuntu like 14.04 or 16.04, can one can expect to get an update with the security patch for this?

I'm running Kubuntu 14.04 with the latest security updates, and I'm still on kernel version 3.13.0-98-generic.

    ~ $ lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description:    Ubuntu 14.04.5 LTS
    Release:        14.04
    Codename:       trusty

    ~ $ uname -a
    Linux anon-pc 3.13.0-98-generic #145-Ubuntu SMP Sat Oct 8 20:13:07 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
No idea why I haven't gotten an update to 4.x. Should I just switch to a rolling release distro like Arch to have the latest updates of everything?

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

#55

Post by forbiddenlake »

winter_blue wrote: post #54

If one's running an LTS version of Ubuntu like 14.04 or 16.04, can one can expect to get an update with the security patch for this? I'm running Kubuntu 14.04 with the latest security updates, and I'm still on kernel version 3.13.0-98-generic. ~ $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty ~ $ uname -a Linux anon-pc 3.13.0-98-gen…

Hours ago. apt-get update && apt-get upgrade.

https://www.ubuntu.com/usn/usn-3105-1/ http://people.canonical.com/~ubuntu-security/cve/2016/CVE-20...

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

#56

Post by alltakendamned »

pbhjpbhj wrote: post #41

If I'm reading this correctly it works only when there's already access to a user account on the system. So you need to have an existing vulnerability already [eg an untrusted user]. Interesting whether it will give new root exploits for Android as suggested in the comments.

Yes, that is exactly what a privilege escalation bug is.

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

#57

Post by h1d »

aji wrote: post #48
vesinisa wrote: post #15

Earlier quoted context omitted.

Gotta love the dedication with the Dirty COW "swag" web shop and all. Though something tells to me it's just a strange in-joke. Might be the prices? ($1,000 for a mouse pad .. oh, really?)

it's definitely a joke. everything in the store is overpriced, FAQ item "how can I uninstall linux" links to a video of a guy smashing a computer, etc. look at this FAQ item: What's with the stupid (logo|website|twitter|github account)? It would have been fantastic to eschew this ridiculousness, because we all make fun of branded vulnerabilities too, but this was not the right time to make that stand. So we created a…

Definitely not funny for all the admins that had an emergency task to handle. This site needs some good updating.

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

#58

Post by ontoillogical »

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 me know!

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

#59

Post by h1d »

geofft wrote: post #32
aexaey wrote: post #12

Earlier quoted context omitted.

And for earlier kernel versions, there is an STAP patch: 1) On the host, save the following in a file with the ".stp" extension: probe kernel.function("mem_write").call ? { $count = 0 } probe syscall.ptrace { // includes compat ptrace as well $request = 0xfff } 2) Install the "systemtap" package and any required dependencies. Refer to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux "SystemTap Beginne…

Doesn't this break Upstart (which uses ptrace for service activation), meaning you really don't want to use it on RHEL 6 or Ubuntu 14.04?

Above link says, it would not work on rhel 5 and 6. Doesn't mention about 7 though.

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

#60

Post by startling »

tptacek wrote: post #24
startling wrote: post #21

Earlier quoted context omitted.

> "In almost all cases, whether or not there's a known local privesc bug, assume that code execution on your Linux systems equates to privesc; this is doubly true of machines in your prod deployment environment. It depends. I've seen "oh well if someone has rce they probably have root anyway" used way too many times as an excuse to avoid defense-in-depth measures.

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.
Post reply on HN