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

Post by aexaey » Thu, Oct 20, 2016, 9:26 PM UTC

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…

  1) On the host, save the following in a file with the ".stp" extension:

  probe kernel.function("mem_write").call ? {
          $count = 0
  }
  probe syscall.ptrace {  // includes compat ptrace as well
          $request = 0xfff
  }

  2) Install the "systemtap" package and any required dependencies. Refer
  to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux
  "SystemTap Beginners Guide" document, available from docs.redhat.com,
  for information on installing the required -debuginfo packages.

  3) Run the "stap -g [filename-from-step-1].stp" command as root.

Post by SysArchitect » Thu, Oct 20, 2016, 9:34 PM UTC

qwertyuiop924 wrote: post #11

aexaey wrote: post #2

CVE-2016-5195 This flaw allows an attacker with a local system account to modify on-disk binaries, bypassing the standard permission mechanisms that would prevent modification without an appropriate permission set. This is achieved by racing the madvise(MADV_DONTNEED) system call while having the page of the executable mmapped in memory. Excellent example why mounting partition with system binaries (such as /usr) rea…

Man, MADV_DONTNEED again? I mean, Linux's implementation is already weird (it behaves in a way counter to most other implementations of the call: you can see Bryan Cantrill's talk for the details). What is with that call?

Post by tcoppi » Thu, Oct 20, 2016, 9:50 PM UTC

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…

Post by rodgerd » Thu, Oct 20, 2016, 10:00 PM UTC

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…

Post by Senji » Thu, Oct 20, 2016, 10:04 PM UTC

kentonv wrote: post #17

vesinisa wrote: post #15

Earlier quoted context omitted.

Gotta love the dedication with the Dirty COW "swag" web shop and all. Though something tells to me it's just a strange in-joke. Might be the prices? ($1,000 for a mouse pad .. oh, really?)

It would appear that the creators of the web site are not even affiliated with the people who found or fixed the bug. "Dirty COW is a community-maintained project for the bug otherwise known as CVE-2016-5195. It is not associated with the Linux Foundation, nor with the original discoverer of this vulnerability. If you would like to contribute go to GitHub." Seems fishy.