“Most serious” Linux privilege-escalation bug ever is under active exploit
1–10 of 218 posts
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#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.
[EDIT] added "read-only"
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#3[deleted]
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#4It'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 right mental model to have regarding Linux privesc bugs is:
1. If there's a local privesc bug with a published exploit, assume it's 100% reliable.
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.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#5CVE-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…
Does this actually allow modifying the binary on disk, or just modifying the in-memory cached page? (i.e., is this a persistent attack that survives a reboot?)
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#6See also the dedicated page for this vulnerability, dubbed Dirty COW (for copy-on-write), aka CVE-2016-5195:
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#7Seems 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() race for write access") but that was then undone due to
problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").
In the meantime, the s390 situation has long been fixed, and we can now
fix it by checking the pte_dirty() bit properly (and do it better). The
s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
software dirty bits") which made it into v3.9. Earlier kernels will
have to look at the page state itself.
Also, the VM has become more scalable, and what used a purely
theoretical race back then has become easier to trigger.
To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
we already did a COW" rather than play racy games with FOLL_WRITE that
is very fundamental, and then use the pte dirty flag to validate that
the FOLL_COW flag is still valid.Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#8It'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.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#9CVE-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…
How does having /usr on a seperate partition (if I understood you correctly) change the bug/exploit?
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#10CVE-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…
How does having /usr on a seperate partition (if I understood you correctly) change the bug/exploit?
Good point, edited to clarify.