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

71–80 of 218 posts

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

#71

Post by necessity »

cm3 wrote: post #67

Since for any serious bug that's published, there's very likely a dozen private or not-yet-found, and also considering on how many networked devices the linux kernel is used, I would really like to see a better upgrade story for Android devices and any other linux-inside gear which doesn't have a distro package manager to apply the fix. As little as I like obstructing tech companies with more laws, especially since m…

That's assuming the distributor warranted you against vulnerabilities in his product (and I remember seeing a "Distro X GNU/Linux comes with ABSOLUTELY NO WARRANTY" on every device I've used...). Forcing said warranty is preposterous.

Concerning smartphones there are so many privacy and security issues that are far easier to exploit than something that involves kernel hacking... But anyway, isn't Google rolling out security updates for Android? I use CM and I know they don't. There are projects like Replicant which provide a mostly free distribution, but I don't think they're rolling out security updates either. If you're interested maybe contact them?

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

#72

Post by ivank »

winter_blue wrote: post #62
forbiddenlake wrote: post #55

Earlier quoted context omitted.

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

It looks like my kernel updates are being held back: ~ $ sudo apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: ffmpeg libva1 linux-generic linux-headers-generic linux-image-generic 0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded. The newest available version of linux-image-gene…

Note the "HWE" (hardware enablement) on that chart. Ubuntu 14.04 came with 3.13; if you want a 4.4 kernel, you have to install linux-generic-lts-xenial.

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

#73

Post by timtadh »

Jedd wrote: post #63
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.

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

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

#74

Post by amalcon »

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.

It depends on why you wouldn't give a user sudo. If you're worried that they might get bored and do an immature prank, or do something ill-advised (like changing the root password, or giving sudo to someone else) and render the system insecure/inoperable/unmaintainable, you probably can give them shell access. A good example here would be giving shell access to employees or the like, if their job is aided by it. The time and effort it takes to research a privesc vuln is usually sufficient to deter them, and if it isn't, you just revoke access and fire them if they do it.

If you're worried that someone might be trying to deliberately compromise your security, you can't give that person the ability to run code on your system.

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

#75

Post by orblivion »

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.

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

#76

Post by winter_blue »

justinsaccount wrote: post #70
winter_blue wrote: post #62

Earlier quoted context omitted.

It looks like my kernel updates are being held back: ~ $ sudo apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: ffmpeg libva1 linux-generic linux-headers-generic linux-image-generic 0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded. The newest available version of linux-image-gene…

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

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

#78

Post by cm3 »

necessity wrote: post #71
cm3 wrote: post #67

Since for any serious bug that's published, there's very likely a dozen private or not-yet-found, and also considering on how many networked devices the linux kernel is used, I would really like to see a better upgrade story for Android devices and any other linux-inside gear which doesn't have a distro package manager to apply the fix. As little as I like obstructing tech companies with more laws, especially since m…

That's assuming the distributor warranted you against vulnerabilities in his product (and I remember seeing a "Distro X GNU/Linux comes with ABSOLUTELY NO WARRANTY" on every device I've used...). Forcing said warranty is preposterous. Concerning smartphones there are so many privacy and security issues that are far easier to exploit than something that involves kernel hacking... But anyway, isn't Google rolling out s…

Are the system (not app) updates Google releases applicable to all Android devices?

It's true that there are a high number of bugs available just in mobile browsers, which do receive google play updates, if you have google play, but viewing the underlying code as verified to be correct would be naive.

If I know that a smart phone or smart fridge will not get software updates and be substantially limited in functionality by that, I wouldn't pay more than 100 bucks for it, because I expect to buy another one in probably 14 months.

However, if the update problem would be fixed properly, I wouldn't mind paying a premium.

It seems that this isn't just laziness by the vendors but also calculated into nudging customers to buy new appliances and gadgets although the hardware is capable and perfectly fine. No vendor would admit to that, but this is being investigated and called planned obsolescence. If the price would reflect the artificially limited lifespan of a device, then the problem goes away, and it's just a matter how much of the materials gets recycled.

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

#79

Post by winter_blue »

ivank wrote: post #72
winter_blue wrote: post #62

Earlier quoted context omitted.

It looks like my kernel updates are being held back: ~ $ sudo apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: ffmpeg libva1 linux-generic linux-headers-generic linux-image-generic 0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded. The newest available version of linux-image-gene…

Note the "HWE" (hardware enablement) on that chart. Ubuntu 14.04 came with 3.13; if you want a 4.4 kernel, you have to install linux-generic-lts-xenial.

Thanks, that answers my question! Installing linux-generic-lts-xenial should let me get the 4.4.x kernel on Ubuntu 14.04.

I might still switch to Arch Linux. It's been a hassle to get the latest releases of various packages (like python, gcc, etc). I've had to use third-party PPAs or manually install them. Ubuntu's freezing of packages makes it great as a base image for Docker containers and other reliably reproducible deployment scenarios, but that's not so great as a regular desktop user.

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

#80

Post by throwaway2048 »

qwertyuiop924 wrote: post #8
tptacek wrote: post #4

It's probably the most serious Linux local privilege escalation ever. Look, the Azimuth people have forgotten more about reliable exploit development than I have ever known, but, no, as stated, this is clearly not true. Not long ago, pretty much all local privesc bugs were practically 100% reliable. What I think they mean to say is that this is unusually reliable for a kernel race. I still think, though, that the rig…

You said it: If you are not explicitly on the business of providing external access to your machine, the privesc isn't your problem (it's a problem, and it's bad, though), it's the fact that anybody could exploit the privesc in the first place.

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