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

101–110 of 218 posts

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

#101

Post by empath75 »

flukus wrote: post #84
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…

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.

It sounds like it wasn't realistically exploitable until recently.

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

#103

Post by empath75 »

ams6110 wrote: post #43
tcoppi wrote: post #16

Earlier quoted context omitted.

> 2. 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. I think this goes for any mainstream OS, Linux is not particularly special here.

So basically, if you wouldn't give a user sudo, they shouldn't have login access at all? Certainly works for some scenarios, but not practical for many others.

the main reason you don't give users sudo is so they don't do anything stupid, not so much to prevent them from acting maliciously.

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

#104

Post by stass »

orblivion wrote: post #75
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…

It's sad that security information and news is so confusing as it is, but thank you for trying to improve it. I'll try to remember your site.

Some operating systems like FreeBSD and (I think) Debian have this functionality built in without the need for external service. So it depends on what you are using. RedHat had a similar functionality as well AFAIR.

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

#105

Post by ndesaulniers »

microcolonel wrote: post #99
ndesaulniers wrote: post #95

Earlier quoted context omitted.

Do you keep track of Android releases? edit: https://appcanary.com/vulns made my browser crawl. Please fix that page.

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? ;)

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

#106

Post by vacri »

peterwwillis wrote: post #46
ams6110 wrote: post #45

Earlier quoted context omitted.

OSX? How is that more secure by default than Linux?

Less published exploits. Okay, so "more secure" isn't exactly correct, maybe "more difficult for a 10 year old with Metasploit to own it"

Who'd've thought that an OS that is rarely used to serve remote content is more resilient against software focused on breaking into remote systems?

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

#107

Post by tytso »

timtadh wrote: post #73
Jedd wrote: post #63

Earlier quoted context omitted.

> Fail2Ban is useless on a properly configured SSH server (no root, no passwords, no kerberos, only keys). This assertion confuses me. I use fail2ban on boxes I have key-only ssh configured for. Are you aware fail2ban works for services other than ssh? If an attacker / script knocks unsuccessfully on my ssh door, other doors are then closed to them. I also get much (much!) cleaner logs thanks to fail2ban.

That is true and a good use case for fail2ban. Useless was probably a strong word, what I really meant was of limited utility in increasing the security of the SSH service.

The main reason I use fail2ban is I got tired of the log file noise/bloat. I use key-only access on my servers already, with the key stored on a hardware token (Yubikey).

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

#108

Post by INTPenis »

caf wrote: post #44
ryuuchin wrote: post #36

Earlier quoted context omitted.

Well another thing to keep in mind with this one in particular is that there is no way to mitigate it. grsecurity can't help with this kind of bug, nothing can so it may not just be about reliability of this exploit but the fact that there's no mitigation other than to update.

It seems like both SELinux and AppArmor could be configured to block access to /proc/self/mem which should mitigate it.

It's sad actually that this is the perfect type of exploit to block with SElinux, a simple write to unauthorized files. But since no one uses the user contexts of selinux then no one blocks this.

Your shell runs unconfined because your user role is unconfined. Any process you might start will therefore run unconfined, unless stated otherwise in a policy.

So this exploit will run unconfined and will be allowed writes everywhere on the system.

I once tried the staff_r role on a Fedora 23 system and it worked out of box but there were more errors and it would not be recommended for beginners.

I believe the same goes for apparmor since apparmor only defines "armor" for processes, not for users. How many use pam_apparmor today? [1]

1. http://wiki.apparmor.net/index.php/Pam_apparmor

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

#109

Post by drieddust »

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

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

#110

Post by problems »

tytso wrote: post #107
timtadh wrote: post #73

Earlier quoted context omitted.

That is true and a good use case for fail2ban. Useless was probably a strong word, what I really meant was of limited utility in increasing the security of the SSH service.

The main reason I use fail2ban is I got tired of the log file noise/bloat. I use key-only access on my servers already, with the key stored on a hardware token (Yubikey).

I guess the question then is why you're looking at failed Auth logs. Failed auths are boring, doubly so on a key only server. Successful auths are where the fun is at.
Post reply on HN