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

201–210 of 218 posts

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

#201

Post by lathiat »

winter_blue wrote: post #76
justinsaccount wrote: post #70

Earlier quoted context omitted.

..because you don't know the difference between upgrade and dist-upgrade. use dist-upgrade or just explicitly install those packages.

No, dist-upgrade would be 14.04 -> 16.04. I don't want 16.04; I want to stay on 14.04.

This is indeed a point of confusion. dist-upgrade basically allows adding new packages, or removal of old packages. upgrade does not, this includes the versioned kernel packages. I suspect (possibly unfoundedly) that the command was originally named because this generally happened when doing such distrubution upgrades, but it's not what it actually does.

If you're always reviewing it manually it's ok to just use dist-upgrade, alternative if you want to install new packages but still not let it remove packages, you can use: sudo apt-get upgrade --with-new-pkgs

Personally I always just use dist-upgrade and it's not a problem as long as you check it before you hit go.

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

#202

Post by ifhs »

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…

Yup, you guys reinvented docker

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

#203

Post by pjmlp »

abysmallyideal wrote: post #200
pjmlp wrote: 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%.

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.

Ahah, I was doing systems programming in Pascal dialects and Modula-2 before having to know C was a requirement.

Of course one always has to validate security, but with C each line of executable line of code is a possibility exploit, which grows exponentially with the amount of developer touching the code and their respective skills and UB knowledge.

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

#204

Post by amscanne »

kentonv wrote: post #199
AstralStorm wrote: post #194

Earlier quoted context omitted.

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.

No, it requires only two threads to trigger the race. Two processes are not needed.

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

#205

Post by amscanne »

Hello71 wrote: 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.

Not sure if the race can be triggered with a single CPU.

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

#206

Post by mamon »

hhjkjhkjhhlkj wrote: post #187
mentat wrote: post #182

Earlier quoted context omitted.

Anyone who's actually operating Linux cares about security vulnerabilities more.

Exactly which bugs are those? Linus makes valid points that people then seem to ignore and change the meaning of. He thinks all bugs need fixing and how they are described is unimportant. Fixing the bugs is more important than how they are categorized.

I would say that the bugs for which known exploits exist definitely qualify as "security bugs". Treating them as any other bugs is just plain stupid.

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

#207

Post by Natanael_L »

ndesaulniers wrote: post #105
microcolonel wrote: post #99

Earlier quoted context omitted.

I think you just need more RAM, it's convenient having it all on one page instead of paginated.

Do you know any good sites where I could download some more? ;)

I think there's some FPGA code somewhere to emulate external RAM...

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

#208

Post by snvzz »

AstralStorm wrote: post #193
snvzz wrote: post #152

Earlier quoted context omitted.

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

Couple things here.

Firstly, as the MM daemon runs on its own process and is well-separated from other code, it is far easier to audit, debug and so on. Its interface is also entirely explicit. There's value in modular programming. It's far more reasonable to expect quality from such a MM daemon than the mess in a random monolith kernel.

Secondly, in seL4, physical pages are capabilities. There might be more than one MM daemon, owning separate sets of capabilities to physical pages. Security-critical memory might be managed by a MM daemon your vulnerable process has no capability to talk to.

Just my two cents.

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

#209

Post by hilop »

the_duke wrote: post #7

Seems to be fixed by this commit (in 4.8.3). commit 89eeba1594ac641a30b91942961e80fae978f839 Author: Linus Torvalds Date: Thu Oct 13 13:07:36 2016 -0700 mm: remove gup_flags FOLL_WRITE games from __get_user_pages() commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 upstream. This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix get_user_pages() ra…

This exploit is in the wild today because the fix was blocked by an obsolete hardware platform? Sigh.

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

#210

Post by hilop »

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…

SSH is a waste of time?
Post reply on HN