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: 4, Funny) by Runaway1956 on Friday October 21 2016, @05:40PM

    by Runaway1956 (2926) Subscriber Badge on Friday October 21 2016, @05:40PM (#417331) Journal

    I'll bet the dirty cow doesn't have super cow powers.

    Starting Score:    1  point
    Moderation   +2  
       Funny=2, Total=2
    Extra 'Funny' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4