Stories
Slash Boxes
Comments

SoylentNews is people

posted by on Friday October 21 2016, @05:37PM   Printer-friendly
from the don't-have-a-cow-man dept.

"Dirty COW." That is what researchers are calling a recently discovered security-elevation exploit recently found in the Linux Kernel and is now being seen in the wild.

A new Linux kernel vulnerability disclosed on Wednesday allows an unprivileged local attacker to escalate their privileges on a targeted system. Red Hat said it was aware of an exploit in the wild.

The vulnerability, discovered by Phil Oester, was sarcastically dubbed by some people "Dirty COW" due to the fact that it's caused by a race condition in the way the Linux kernel's memory subsystem handles copy-on-write (COW) breakage of private read-only memory mappings.

The security hole, tracked as CVE-2016-5195 , allows local attackers to escalate their privileges on the targeted system by modifying existing setuid files, Red Had said in its advisory.

"An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system," the company explained.

Red Hat, which classified the flaw as "important," said it was aware of an exploit leveraging this technique in the wild, but the company has not shared any other information. A fix has already been developed and Linux distributions have started releasing updates.

[...] The people who created the Dirty COW website, logo and Twitter account have admitted that this vulnerability is not as serious as others and they claim to have branded it to make fun of branded flaws. They even created a shop that sells "Dirty COW" mugs and t-shirts for thousands of dollars.

(You can get a much better deal on SoylentNews-branded mugs and T-shirts.)

Coverage at The Register provides a quite-readable description of how the exploit works:

[Continues...]

Copy-on-write is used to streamline the memory management in an operating system. Among other things, it allows running programs to share common data in memory until one of them wants to privately alter that data. At that point the kernel copies the data to another page in memory so just that one process can affect it – hence the name, copy-on-write (CoW).

The exploit works by racing Linux's CoW mechanism. First, you have to open a root-owned executable as read-only and mmap() it to memory as a private mapping. The executable is now mapped into your process space. The executable has to be readable by the process's user to do this.

Meanwhile, you repeatedly call madvise() on that mapping with MADV_DONTNEED set, which tells the kernel you don't actually intend to use the memory.

Then in another thread within the same process, you open /proc/self/mem with read-write access. This is a special file that allows a process to access its own virtual memory as if it was a file. Using normal seek and write operations, you then repeatedly overwrite part of your own memory that's mapped to the root-owned executable. The overwrite shouldn't affect the executable on disk.

So now, your process has the read-only binary mapped in as a private read-only object, one thread is spamming madvise() on that read-only object, and another thread is writing to that read-only object. Writing to that memory object should trigger a CoW: the touched page of the executable will be altered only in the process's memory – not the actual underlying root-owned file that's mapped in.

However, due to the aforementioned bug, the kernel performs the CoW operation but then allows the process to write to the read-only mapped executable anyway. These changes are committed to disk by the kernel, which is bad news.

This happens because, due to a race with madvise(), the kernel does not fully break the executable from the process's private memory. The process writes to the read-only object, triggers a page access fault, and the fault is handled by allocating a new page containing a copy of the underlying file and privately mapping it into the process. So far, so good.

However, madvise() tells the kernel to discard the pages holding the mapped area. Calling this while writing to /proc/self/mem will eventually lead to an inconsistent state where the pages holding the mapped executable are removed and a write is attempted to the memory area. Eventually, the write that should go to the private pages will instead alter the mapped object. These changes are committed by the kernel to storage.

This can be exploited to alter a root-only setuid binary so that it, for example, spawns a root-owned shell. It is possible to combine this exploit with ptrace to make it more reliable, although it is not essential.

The fix – which changes just two lines and introduces a single-line inlined function – sets a flag that signals a CoW operation has occurred, preventing the underlying page holding the executable from being unlocked and written to.

Perhaps the greatest risk of this exploit is that Linux is used in so many devices that will never see an update. Old routers, WiFi base stations, even Android phones are based on Linux. Might put a dent in the used device market?

Relevant Links:
Affected kernel versions
RedHat advisory
RedHat bug tracker
RedHat mitigation details
Debian bug tracker
Canonical information
Additional vulnerability details
Exploit
CVE database entry (2016-5195) [Currently reserved, but unpopulated]


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by frojack on Friday October 21 2016, @07:50PM

    by frojack (1554) on Friday October 21 2016, @07:50PM (#417391) Journal

    Mamma told me these were bad...

    --
    No, you are mistaken. I've always had this sig.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 1) by Francis on Saturday October 22 2016, @01:28PM

    by Francis (5544) on Saturday October 22 2016, @01:28PM (#417567)

    It doesn't appear that the problem here is setuid, the problem is that they screwed up their filesystem. Unfortunately, I'm not seeing anywhere in the article or summary any mention of what filesystem they're talking about. In my experience, the people writing filesystems need to just stop before they fuck things up any more than they already are.

    As much as I dislike MS, I've never had the frequency of filesystem corruption issues that I've had with Linux. The only times I've ever had a filesystem in Windows go bad were from either a disk going bad or repeated aborted boots. I've had Linux repeatedly destroy entire installs even when properly shutting the computer down.

    Setuid, is a completely different matter as it appears they've screwed up their COW implementation.

    • (Score: 2) by pe1rxq on Saturday October 22 2016, @02:00PM

      by pe1rxq (844) on Saturday October 22 2016, @02:00PM (#417572) Homepage

      You don't see any mention of a filesystem in the article because you are wrong.
      It has nothing to do with the filesystem. It is a bug in the memory management. The setuid file could be on any filesystem type.

      • (Score: 1) by Francis on Saturday October 22 2016, @03:10PM

        by Francis (5544) on Saturday October 22 2016, @03:10PM (#417587)

        That's part of the filesystem. If it applies to all of the filesystems on Linux, then fine, but the memory allocation is a part of the filesystem. It was likely a memory related problem that led to so many of my Linux installs going tits up as well, things being stored, but not properly written to disk.

        But, I think the whole idea that memory allocation is separate from the program is an idea that should have died years ago. If you're writing low-level code, you can't just ignore the memory allocation as if it's not part of the program. I can't blame them for giving up on exploiting the bug at that time, but perhaps if there were fewer unnecessary filesystems they wouldn't need to be as spread thin in testing the filesystems and related infrastructure.

        • (Score: 2) by pe1rxq on Saturday October 22 2016, @03:19PM

          by pe1rxq (844) on Saturday October 22 2016, @03:19PM (#417590) Homepage

          Memory allocation is a part of the filesystem? Have you ever looked at the kernel sources?

          • (Score: 1) by Francis on Saturday October 22 2016, @03:47PM

            by Francis (5544) on Saturday October 22 2016, @03:47PM (#417594)

            Yes, it is a part of the filesystem for all practical purposes. The whole attitude that it's technically not my code, so it's not my problem is a huge problem. Any code that you're depending upon is your problem and it doesn't make any sense to expect that the folks writing those dependencies are going to be able to secure things for you. They can make sure their API is enforced faithfully and that the code is generally free of showstopping bugs, but predicting what their code is going to do when mixed with random other software is asking a bit much. Especially, when you consider that fixes for one buggy interaction may well have issues with other software interactions.

            The solution is to just realize that the memory allocation and related are effectively a part of the process and need to be considered. Especially when you're talking about low level functions like filesystems and drivers.

            Granted, this is all easier said than done, but if there weren't so many largely pointless filesystems, there'd be more energy and developer time for proactively looking for things like this.

    • (Score: 0) by Anonymous Coward on Saturday October 22 2016, @04:58PM

      by Anonymous Coward on Saturday October 22 2016, @04:58PM (#417604)

      As much as I dislike MS, I've never had the frequency of filesystem corruption issues that I've had with Linux. The only times I've ever had a filesystem in Windows go bad were from either a disk going bad or repeated aborted boots. I've had Linux repeatedly destroy entire installs even when properly shutting the computer down.

      you're a moron and now everyone knows it.