Live data from Hacker News

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

arstechnica.com

171–180 of 218 posts

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

#171
post #164
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%.

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

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

#172
post #77

Doesn't seem like it works on a $10 DigitalOcean droplet (1 vCPU) with grsec-patched 4.4.8. After running for quite some time (which I suspect a system administrator would notice) "cat foo" still outputs the same contents.

How much is "quite some time"? It ran for several minutes before eventually succeeding on my fast, modern desktop.

The loops finished.

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

#174

Earlier quoted context omitted.

Linux developers don't believe in security vulnerabilities: https://news.ycombinator.com/item?id=2539839

The link doesn't say what you say it does. It says that Linus thinks that security researchers want to put security at the expense of usability, which is a different thing entirely.

That, and that a bug is a bug is a bug. Any bug can potentially be a security vulnerability with the right approach. Thus putting people that find such bugs on a pedestal is counterproductive.

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

#175
post #135
post #91

Earlier quoted context omitted.

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

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

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

#176
Okay, I have no idea what to do. Not a security engineer, can't follow what this thing does but I do have a couple of VPS's running my blog and a few other things. Now maybe there's an argument that I shouldn't be doing this if I don't completely understand all the ins and outs, but what the hell, I like learning about Linux.

So my question is: is simply updating and upgrading enough to protect me from this MOST DANGEROUS BUG EVER IN THE WORLD OH MY GOD YOU'RE GOING TO END UP PART OF A BOTNET AND HURT LITTLE CHILDREN!!1!!1! Which is how this reads to even a semi-technical reader, I mean I know my way around the command line but I'm at a loss as to what to do here.

Help me out HN please!

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

#177

Earlier quoted context omitted.

Linux developers don't believe in security vulnerabilities: https://news.ycombinator.com/item?id=2539839

The link doesn't say what you say it does. It says that Linus thinks that security researchers want to put security at the expense of usability, which is a different thing entirely.

> The link doesn't say what you say it does

First you gotta tell me what do you think I'm saying. The link may not say it but if you check the thread that link resides in you'll see it's right on topic.

The context here is set by the parent:

> That sounds like a pretty serious issue with the QA and or bug tracking process.

My comment is exactly about "bug tracking process" Linux is not known to be a friendly upstream when it comes to widely accepted security procedures like marking security vulnerabilities as such, coordinating fixes with distribution vendors etc.

> So I personally consider security bugs to be just "normal bugs". I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special. (http://yarchive.net/comp/linux/security_bugs.html)

Just look at the damn commit that fixes this vulnerability. It doesn't even tell it is a serious local privilege escalation. I saw the changelog for 4.4.26 yesterday and didn't realized it was an urgent security update until I saw Debian bulletin later.

> For various reasons I needed to get a round of stable kernels out sooner (http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg...)

Yeah. "various reasons". There are only 2 commits and one is a huge vulnerability. In the mean time the fix (thus the vulnerability) was sitting in Linus' git tree for the last week because Linus doesn't believe in security vulnerabilities.

Whatever.

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

#178
post #171
post #164

Earlier quoted context omitted.

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

> 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 almost daily!

Just yesterday while reading some papers on Cyclone, I discovered this jewel:

"X El Capitan v10.11.6 and Security Update 2016-004" release notes

https://support.apple.com/en-us/HT206903

From 36 bug fixes, 31 are related C memory corruption issues!

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

#179
post #50

Earlier quoted context omitted.

Citation needed. That's certainly a goal, but I've never heard the claim.

http://thenewstack.io/thirteen-ways-containers-secure-virtua...

> will emerge > thin walls

This article is very hopeful and positively worded, but at its core it acknowledges that security parity is still a work in progress.

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

#180
post #84

Earlier quoted context omitted.

So it's been a known bug for 11 years? That sounds like a pretty serious issue with the QA and or bug tracking process.

Linux developers don't believe in security vulnerabilities: https://news.ycombinator.com/item?id=2539839

First you gotta tell me what do you think I'm saying

> Linux developers don't believe in security vulnerabilities

Post reply on HN