Slashdot Mirror
'Most Serious' Linux Privilege-Escalation Bug Ever Is Under Active Exploit (arstechnica.com)
Reader operator_error shares an ArsTechnica report: A serious vulnerability that has been present for nine years in virtually all versions of the Linux operating system is under active exploit, according to researchers who are advising users to install a patch as soon as possible. While CVE-2016-5195, as the bug is cataloged, amounts to a mere privilege-escalation vulnerability rather than a more serious code-execution vulnerability, there are several reasons many researchers are taking it extremely seriously. For one thing, it's not hard to develop exploits that work reliably. For another, the flaw is located in a section of the Linux kernel that's a part of virtually every distribution of the open-source OS released for almost a decade. What's more, researchers have discovered attack code that indicates the vulnerability is being actively and maliciously exploited in the wild.
"It's probably the most serious Linux local privilege escalation ever," Dan Rosenberg, a senior researcher at Azimuth Security, told Ars. "The nature of the vulnerability lends itself to extremely reliable exploitation. This vulnerability has been present for nine years, which is an extremely long period of time." The underlying bug was patched this week by the maintainers of the official Linux kernel. Downstream distributors are in the process of releasing updates that incorporate the fix. Red Hat has classified the vulnerability as "important."
"It's probably the most serious Linux local privilege escalation ever," Dan Rosenberg, a senior researcher at Azimuth Security, told Ars. "The nature of the vulnerability lends itself to extremely reliable exploitation. This vulnerability has been present for nine years, which is an extremely long period of time." The underlying bug was patched this week by the maintainers of the official Linux kernel. Downstream distributors are in the process of releasing updates that incorporate the fix. Red Hat has classified the vulnerability as "important."
Can I use this to root my Android phone? I just want to install an ad-blocking /etc/hosts file, so I don't need a permanent root. This sounds like just the sort of exploit to do the trick, but I haven't looked at the technical details. I just want to do this before the next security update patches it.
Hmm .. something just doesn't sound right here.
True. The thing that doesn't sound right is the belief that security is binary. Security is a continuum and sometimes a series of tradeoffs. It's not, never has been, and never will be 100%.
So no, finding a security bug in the linux kernel doesn't mean that linux is any less secure. We know these things happen. The idea is that it happens LESS often, and with less severity, and with fewer downsides than with Windows.
Why use Linux? Because as much as I love FreeBSD as a hardware barebones headless server for this and that, dealing with hardware driver issues for a fully featured desktop ranges between a pain in the ass and impossible. Otherwise I would be using the PC-BSD variant as a desktop productivity OS over Linux.
Brought to you by Carl's Junior.
So, how many security holes just as bad as this one has been silently plugged in Windows the last 15 years? How many equally serious security holes are being exploited in Windows right now? How many worse security holes are being exploited, or waiting to be found in Windows, right now?
I don't now. But I'm willing to guess the answer isn't "zero" to any of those questions. Nobody ever claimed Linux was bulletproof, the point is that it's better than the alternative.
Linux is less complex than Windows, bugs tend to be more public (no silent fixing of things while fixing other breakage), and get fixed faster than Windows. That's how it's more secure. Not because it's bulletproof.
It's also not a massive piece of spyware in itself.
Spam the mm from 2 threads. Wait for a read only page to be writeable before cow occurs.
Among the more serious exploits ive encountered, i must protest that "dirty cow" is not a sufficiently spooky enough name for this one. We all know Halloween approaches, so why not call it haunted cow? or zombie cow?
in addition, this exploit is far less severe than the shoulder surfing exploit of 2005 which resulted in direct root privilege access and a broken friendship, Margaret, that led me to conclude I could no longer trust you to use either the mini fridge or my Sriracha sauce anymore because friends dont just log in to anyones workstation Margaret, i trusted you and you deceived me.
Good people go to bed earlier.
For Linux, it's the most serious local privilege escalation ever.
For Windows, it's Friday.
"The in the wild exploit we are aware of doesn't work on Red Hat Enterprise Linux 5 and 6 out of the box because on one side of the race it writes to /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise Linux 5 and 6."
-- https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13
I found one of these "exploits in the wild":
https://github.com/dirtycow/dirtycow.github.io/blob/master/dirtyc0w.c
It works on the three Linux machines I first tested it on. /etc/secretfile.txt abcde
$ dirtyc0w
simply (over)writes abcde to the beginning of the file.
Fix seems to be available for none of the systems right now.
At least it requires a local account.... I mean, after all, it must be considered a security problem to allow web users to upload binaries or run arbitrary commands via a web server anyway. But if I was responsible for a students lab with hundreds of Linux computers I would be a little nervous.
Yep. Processes have memory. Memory is divided into pages. Some pages are shared by multiple processes. Initially some pages are marked read only. If the child writes to the page you get a page fault. The fault causes the kernel to make a copy of the page and maps the copy into to the original virtual address space.
Multiple processes may share that original readonly page, so if exploit the bug and write to it then you actually are writing to a page shared by multiple processes.