That's why I like the Linux file system so much. Knowing that _everything is a file_ makes everything so much easier. And consistent. Everything can be treated as text. Thinking back I had to write a driver for my laptop backlight be the default didn't work well. It only meant creating a text file with few parameters like max and current brightness. Pressing backlight keys means updating the file with a new value, that gets pushed to the display. It's such an elegant solution to any hardware. Keyboard, temperature sensor or usb dongle, anything.
To be everything can be treated as bytes, and those bytes can be easily translated to ascii text. Unfortunately this means that there are unreadable stuff passing through, and you can be confident that all files are within readable ascii text. So theoretically, it is text but I want to stay with the idea that everything is just a pointer and that the files are just pointers to the real device/process.
An interesting aspect I noticed about the exploit (I tried cowroot specifically) is that the changes to the file remain only in cache - the changed file doesn't get actually written back to disk, even if I call „sync”. If I then tell the kernel to drop caches („echo 3 > /proc/sys/vm/drop_caches”), I get the original file back.
IKR :D BTW, I love the intuitive way you make your videos. Could you make a video about the video making process? To show which tools you use and how you use them e.g.
Am I getting this right? Normal situation: 1. You read from file. Page table points to original file 2. You request write. 3. copy created 4. page table points to copy 5. you write 6. file isn't saved because it was read-only Race condition: 1. You read from file. Page table points to original file 2. You request write. 3. copy being created 4. You write. ouch.... page table wasn't updated yet. write happened on original file 5. page table points to copy 6. copy isn't saved because it was read-only. But anyway we have modified the original file.
pretty much 2. you request write 3. copy being created 4. before the write is done, madvasie(DONTNEED) in the other thread caused a throwing away of the copy, 5. memory manager only has the original mapping, thus the write goes there to the original file.
Excellent overview of this and much appreciated! I am NOT a Linux guru by any means but videos like this are simple to understand versus those useless written articles that assume all of us admins are expert Linux users and automatically know about every single Linux file....some of us actually wear more than one hat and have many more responsibilities than just patching Linux....Windows is bad enough :-) Thanks again and I will share this with colleagues...very interesting exploit...
Wow, this is incredibly approachable! It's more verbose than I was really (personally) looking for, but I really like how you're thorough enough that almost anyone with a little programming experience can probably follow it. Good show!
Amazing video! Everytime I watch your videos it gets a little clearer to me. (just a little).It's amazing that this has been widespread for 9 years. Also, I think full disclosure is probably the best. As a security professional, your job isn't to worry about less skilled admins, or hackers. Not to mention, someone could have already discovered this and is waiting to use it. The faster the information is out, the better (just my opinion)
I thought about doing exploit walkthroughs for a while now. The AngularJS series was basically a first experiment of that. Not sure if I will cover heartbleed. But generally I like the concept of making videos about CVEs.
Recently I have started digging deeper into Reverse Engineering and a friend of mine gave me a link to your channel. I really appriciate your videos. Especially the background information on how and why things work in a certain manner. This is really something unique to your channel and which is something I really really like about your way of working. Thanks for all the video's already, and I hope there are many more to come! Keep up the great work and enjoy your weekend!
Thanks for the neat and awesome explanation. So many concepts also you covered in small time.!! Can I have couple of clarifications? 1)It is said in video that: "mmap doesnt copy the file into memory but it maps it to memory", what is the difference between the both? 2)"if we write to the mmaped file, will this never reflected into underlying file" when is this applicable? If we use these flags PROT_READ,MAP_PRIVATE ? Or in every case we use mmap?? 3) what do we mean physically by "creating a copy"?? Does it mean writing to cache or allocating main memory for it? or.? 4)" mapping a file is different from reading it through a file descriptor.", any explanation for this statement? Thank you
+anthony balaraju 1) copy a file into memory means you read the bytes from disk and put them in RAM. And then you work on the data in ram. When you directly map the file into memory, and you write to it, you write directly to the file on disk. I think the word "memory" is a problem here. You should not thing of memory as your RAM. But generally anything that could be data. All data can be addressed with a memory address. For example 0x040010. A computer program can access this memory address, but where the data for this address is coming from, can be different things. In most cases it's probably something in RAM, but when you mmap a file on disk, you access directly the disk. This is all down by the memory management layer in the kernel. Maybe swap files are easier to understand. If you run low on memory, the operating system might put some data in a swap file on disk. And when a program wants data, that got stored on disk in a swap file, the program doesn't know about this all. The kernel just handles this for you. It's all magic. 2) obviously when you map a file with write permissions you could also write to it. If you map it read only you can't write to it. But if it is mapped as private, and you write to it, a copy is created and you can write to the copy of it. 3) Where this copy is stored I actually don't know, maybe a cache or RAM. I assume it stores it in RAM. But not sure to be honest. 4) reading a file means, you use the syscall read to read from a filedescriptor, which probably refers to a file you opened before with the open syscall. And when you read from the file you read the bytes somewhere into your programs memory, which is RAM. The mmapped file behaves like as if you already put the file content somewhere in memory, because you simply access a certain address, and the Linux memory manager will make sure to deliver you the data from the underlying file. Sounds like i should make a video about thi
Haha.. Really, it sounds like you can make another 3 min video to explain this .!! Never mind, your explanation here is as clear and good as in video .. Thank you for that.!! :) 2)so it means PROT_READ flag is not required!! I will ask one more and last question probably, What I understood is: private_write: 1)update pages (page table), 2)write to newly allocated private page/file madvice: throw away allocated/updated private page/file I seriously tried hard to understand why the data is directly written to actual page when race occurs!! If madvice discard that page, then still data has to be written to same address. ! I meant to say actual file and private copy, the addresses assigned will be different! so how could it be written to actual file due to race!!May be I am missed something!!
I just tried this and first I thought it didn't work because the program never stops (and just uses 100% CPU). But it turns out it did work and you can stop the program manually with Ctrl+C.
"... because I'm a hypocrite" - haha! Nah, that's just your ethics trying to do the right thing. I also feel information should be open and free, however some times we should take careful steps when you share information. I'm stuck in a loop of watching your videos, they are amazing and well done! Even though I read a lot about these vulnerabilities when they came out, I still value your point of view on them and I can use your videos to help explain these issues to others; thanks!
can you make a video just showing strategies for privilege escalation? like "look after files that have root privilege and try to write in them some commands" etc. I mean, just a video about different privilege escalation strategies to look in a linux system, without any help from a framework like metasploit, just raw hacking
I still miss the point in the race condition. How come one manages to bypass the mapped memory and write directly into read-only file? Shouldn't the write always spawn a copy of such a file?
> Shouldn't the write always spawn a copy of such a file? Yes it does. But there is this bug that we exploit, madvise(DONTNEED) will always throw away the page again. So while the write triggers a new copy, if we throw the copy away before we get to write, we write to the original mapped memory. edit: the concept of file permissions is enforced by the kernel. And this is a bug in the kernel. The read-only mapped memory causes a copy. But because of the race condition of throwing it away, we perform the write to the original mapped file, thus basically bypassing the read-only property.
I get your point. Still, it looks a bit odd to me because the Write writes on /proc/self/mem + map (that is where the copy of the file should be mapped in the process memory), not on the actual file. I mean, even if you free that page, I would have expected that you write in a meaningless part of the process memory where the file was mapped. Instead, it happens that you write to a file that wasn't even addressed by the file pointer f (which referred to /proc/self/mem ). What am I missing? :\
> (that is where the copy of the file should be mapped in the process memory), not on the actual file. no. this is where the real file is mapped to. As read_only. You directly read from that file. BUT when you write to it, you create a copy. And then the kernel's memory manager updates the page table and points to the copy. And that age table update is what you race. There is an alternative version of this exploit where you don't write with /proc/self/mem, but with ptrace(). Maybe that makes more sense to understand. So as you probably know, ptrace is used for debugging. So you can attach to a process, you can read memory from it, you can single step through the execution and so forth. Now ptrace also supports writing to the memory, because when you set a "breakpoint" with ptrace, you have to write a 0xCC (int 3) instruction to the code segment (code segment is also not-writeable memory). So in the alternative exploit, you ptrace your own process and write to that not-writeable memory. That feature has to be there for debugging purposes as explained above. BUT obviously you don't want to propagate changes to mapped read-only files. So in this case you trigger a copy-on-write and ptrace writes to this copy. Now because of that throwing away (madvise(DONTNEED)), you exploit a race condition, that the memory manager just updated the page table to point to the original file and you write to it before it could create a new copy and update the page table again.
I don't think the /proc/self/mem file (or /dev/mem for that matter) is really intended to be written using lseek(2)/write(2) so that part of the code can be just written haphazardly. Most of the time those files are immediately mmap(2)'d after open(2)'d.
Hey LiveOverFlow loved this video! I was trying to walk through this on my own, quick question which kernel version did you use when demonstrating the exploit?
Thanks for responding! No worries, I was able to figure it out. For anyone else looking to reproduce this video I was able to follow along by installing linux kernel 4.3.6 generic onto my ubuntu 16.04 LTS VM.
The fix was summarized in the commit message: "' "yes, we already did a COW" rather than play racy games with FOLL_WRITE" They explicitly flag the memory as being worked on for the time it takes to copy that file. The next time the copy is tried, it sees "oh, already tried this" and stops.
So this exploit is simply about the cow creation not being thread safe? As it doesn't block thread executing write() before it properly finished so write() works with the old pointer
there is an exploit for either the xbox 360 or one of the play station consoles where access to the low level stuff for modding or something can be done by repeatedly rapidly resetting the cpu to exploit the very small window between power on and hypervisor kicking in to inject some code. is that an example of a race condition?
Hi LiveOverflow!,First thanks about the fantastic video secondly i have couple questions< the madvise tells the kernel the map part isnt neded so the kernel must remove the contents of map (even if it's dirty) however what you said is the kernel removes the COWed that the procselfmem was writing to?!!! how would that happen (i dont know about if kernel code removes the map and it's copies if it's advised to remove ! is that the case? the second question , processor just do what we say so if i told the processor to calculate 1+1 biion time its not going to be tricked and answer 1 at any of them
Hi, I have query about Linux privilege. Escalation, if the code is in .c format, and victim machine not having gcc installed, if I convert .c to executable in my kali machine and run that elf in victim system means will it works?
docker blocks the ptrace system call in the default seccomp profile. How did you get around this? I am unable to reproduce this with that profile in place. I am having to add --security-opt seccomp=unconfined.
+LiveOverflow I created a version that uses /proc/self/mem to get around this and works with any vDSO. I'm still curious about seccomp though? Is that in your docker-compose.yml file?
Someone caught me watching this... "Wow, you really are a geek" I felt ashamed, up until they broke out laughing at the ending, "But I practice ethical .. because .. I'm a hypocrite" Just goes to show, even geeks, don't geek out on everything. Including explanations behind their ethics =D
thanks @LiveOverflow..I'm wondering something..I'm using debian 8.5 on a thinkpad e431, with 4gb of ram 128gb ssd; & the last presidential debate, I tried streaming it from youtube, found it sluggish toggling from full screen, & back, after 15minutes into the stream the graphics threw a fit, the screen got a tv static - like appearance, then went to into some color checking mode, I attempted to hard reboot, but got a black screen..After hard rebooting 3-4 times, I successfully got into the desktop, & attempted to stream the debate again, only to repeat the hard reboot(s) after another color checking mode, until I was successfully back into the desktop..I thought it was failing hardware, but checked the updates, I had kernel headers, & kernel updates waiting...After updating I haven't had an issue since;could this have been related to the dirty cow exploit?forgot to mention, I had tcpdump running in bash while streaming, with was a root process..
I am confused about how you said that 'mapping' the file was reading directly from disk. Are you sure? I thought the only difference that MAP_PRIVATE made was that when writes occur, they are not committed to the original file (fd) but instead are made local/private to new pages. What makes you say that the file is read 'directly'? I don't see that in any of the mmap documentation.
how is "reading from the real file from disk" in any conflict to "writing is not committed to the original file" ;) it's copy-on-write MAP_PRIVATE: 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.
ahh.. I think there is a small misunderstanding. what do you think "mapping to memory" means? Do you think the kernel performs a memcopy from the HDD into RAM? "The basic idea of memory mapping is to map a byte range of a file to a range of process addresses. [...] mapping is made, but no copying is done. Instead when one or the other process requires the data, a page fault occurs and at that time a single copy is obtained off disk," - www.cs.uleth.ca/~holzmann/C/system/mmap.html
What is the the "rare condition". How does the discretionary access control system actually get violated by mmap and the page table? I feel like this "explanation" video left out the punchline.
The discretionary access control is not violated directly; this is not where the vulnerability lies. The file mapped into memory must be readable by the executing process. The exploit works but reading in a suid root file and attempting to trigger a race condition in the kernel that allows you to write to the underlying file and flush the changes to disk before triggering a copy-on-write. This works due to the latency between the moment when a write syscall is requested and when the page table for the current process is updated. So, under certain circumstances the write is executed with a "non-updated" page table while the copy-on-write is being executed. Eventually the page table is updated, but you have already made changes to the underlying file. It's not entirely clear how the changes are flushed to disk, though. The patch just makes sure the copy-on-write operating has completed before allowing the write operation to complete.
im not a hacker, im a developer and i learnt a lot about Os and intricate details of the system.Thanks for the video. However, I would still like to know how this race condition is causing this to happen,..i mean the root cause.
Some time ago I found a pretty serious exploit in a hosting website (I won't name anything) and told them exactly how I did it and how I would take care of the issue. Only thing I got in response was "We will look into this with our team. By doing this, you ware voilating our ToS. Your account may be banned blablabla" :3
why are you writing to /prop/self/mem. correct me if I am wrong , the mem contains the whole process memory. so how only mapped page is affected and why are you not using the returned file descriptor of mmap() to write to the file.
1. mmap doesn't return a file descriptor, mmap returns the address where the file was mapped to. So it's some address in the process memory. We don't write there, because we are not allowed to write to that file. But we keep spamming the madvise on that memory area. 2. we open /proc/self/mem and seek (go to) the address where the file was mmaped to. And then we keep writing to that.
The answer to your question could be found at the below link. From what I understand it's because it simulates a page fault which only happens if /proc/self/mem was used. chao-tic.github.io/blog/2017/05/24/dirty-cow
+I2obiNtube that is not true. That would be a huge security issue. Look at the permission of the file. It doesn't belong to root anymore after you w! it. And the reason why you were able to delete and write your user file instead is, because you are probably in your home directory which has your user permission. unix.stackexchange.com/questions/58880/how-does-vim-steal-root-owned-files
sudhakar verma LiveOverflow superuser.com/questions/900888/vi-can-write-to-file-despite-file-being-read-only Have a weird suspicion it's just this. Tested a few more times with non rw'd directories and it didn't work. Probably missing something (pretty sure my kernel is vuln, but could be wrong). try mkdir test, chown root:root, chmod 0404 the directory and a file in there and chown it to root:root
Great job on this video. Even with my near zero Linux knowledge, I could follow it enough to be interested and understand at least the key concepts. You put in a lot of work to explain, illustrate and make it entertaining. Much appreciated.
godammit! I didn't fade out the music in the beginning. It's super loud. It will stop a few seconds later. Sorry about that.
Ok
The music is also only playing on the right channel. With headphones that is quite irritating to listen to. Anyway, nice explanation!
Anyway, it even added additional awesomeness for your fast actions in terminal & movie in general :P
that was a dirty trick....and we love it!
I guess you have to give the credit for the music, or this fine explanation might get DMCA-banned :-(
Take care!
That's why I like the Linux file system so much. Knowing that _everything is a file_ makes everything so much easier. And consistent. Everything can be treated as text. Thinking back I had to write a driver for my laptop backlight be the default didn't work well. It only meant creating a text file with few parameters like max and current brightness. Pressing backlight keys means updating the file with a new value, that gets pushed to the display. It's such an elegant solution to any hardware. Keyboard, temperature sensor or usb dongle, anything.
What exactly parses the file content and send to the hardware?
@@EvilSapphireR ioctls, I would guess.
To be everything can be treated as bytes, and those bytes can be easily translated to ascii text. Unfortunately this means that there are unreadable stuff passing through, and you can be confident that all files are within readable ascii text. So theoretically, it is text but I want to stay with the idea that everything is just a pointer and that the files are just pointers to the real device/process.
It's criminal that more folks have not seen your video of the exploit. Perfect!
you can help sharing it :)
10:05 "...according to the patch author" which just so happens to be Linus Torvalds. I'd trust him on that one.
lonus teh tips is gey
@@realcartoongirl linus torvalds as in the linux guy
@@realcartoongirlr/woosh
sorey i was made bad joke i am opologise
An interesting aspect I noticed about the exploit (I tried cowroot specifically) is that the changes to the file remain only in cache - the changed file doesn't get actually written back to disk, even if I call „sync”. If I then tell the kernel to drop caches („echo 3 > /proc/sys/vm/drop_caches”), I get the original file back.
This exploit even works on a file system that has the 'ro' option set, probably because of the cache behaviour.
> EO"F"
OH WOW! What a missed opportunity
IKR :D BTW, I love the intuitive way you make your videos. Could you make a video about the video making process? To show which tools you use and how you use them e.g.
you are not the first one to ask. Infact I have already started with a video about that :)
meta ...
I've been trying to understand the exact nature of this race condition for a class, and your video finally made the "aha" light come on - thank you!!
Am I getting this right?
Normal situation:
1. You read from file. Page table points to original file
2. You request write.
3. copy created
4. page table points to copy
5. you write
6. file isn't saved because it was read-only
Race condition:
1. You read from file. Page table points to original file
2. You request write.
3. copy being created
4. You write. ouch.... page table wasn't updated yet. write happened on original file
5. page table points to copy
6. copy isn't saved because it was read-only. But anyway we have modified the original file.
pretty much
2. you request write
3. copy being created
4. before the write is done, madvasie(DONTNEED) in the other thread caused a throwing away of the copy,
5. memory manager only has the original mapping, thus the write goes there to the original file.
LiveOverflow Thanks!
This is beautiful and I learnt a lot! I love the little animations and everything! I look forward to more videos like this :)
"Mad cow. Am I right?" Lol Subbed.
Excellent overview of this and much appreciated! I am NOT a Linux guru by any means but videos like this are simple to understand versus those useless written articles that assume all of us admins are expert Linux users and automatically know about every single Linux file....some of us actually wear more than one hat and have many more responsibilities than just patching Linux....Windows is bad enough :-) Thanks again and I will share this with colleagues...very interesting exploit...
Thank you for the explanation. I watched the Computerphile take a month ago and didn't fully understand what was going on. Now I get the COW.
Wow, this is incredibly approachable! It's more verbose than I was really (personally) looking for, but I really like how you're thorough enough that almost anyone with a little programming experience can probably follow it. Good show!
Amazing video! Everytime I watch your videos it gets a little clearer to me. (just a little).It's amazing that this has been widespread for 9 years. Also, I think full disclosure is probably the best. As a security professional, your job isn't to worry about less skilled admins, or hackers. Not to mention, someone could have already discovered this and is waiting to use it. The faster the information is out, the better (just my opinion)
"file" Makes me laugh every time :)
Thanks for the explanation. Very well produced and explained, subbed!
Very nice. I like the way you present it, switching from the code to diagram make it clear and didactic. Thank you very much for this video :).
I'm so happy this was posted on Engadget. Been a fan for a while. Hopefully it gets more and more views
Very informative, thanks for breaking it down for us!
Excellent video write up! This helped fill me in real quickly on what was up with this exploit while I couldn't get to my machine.
Very cool vid,! Can You make a video series of those walk-trough CVE's? Heartbleed maybe?
I thought about doing exploit walkthroughs for a while now. The AngularJS series was basically a first experiment of that. Not sure if I will cover heartbleed. But generally I like the concept of making videos about CVEs.
If it contains simple PoCs (like no full exploit, only a PoC that shows how to overwrite the EIP for example ...) it would be really awesome.
LiveOverflow I would LOVE to watch those videos.
This was seriously great, please keep it going. The "file" bit cracked me up bad.
Thank you very much for explanation through animation. Very easy & interesting to understand...
What a great explanation. Such clarity.
You need to make a lot more such videos. Kudos.
Amazing explanation, a thousand thanks !!
Wow this video brought you over 1500 subs! Your work is just awesome!
Recently I have started digging deeper into Reverse Engineering and a friend of mine gave me a link to your channel. I really appriciate your videos. Especially the background information on how and why things work in a certain manner. This is really something unique to your channel and which is something I really really like about your way of working.
Thanks for all the video's already, and I hope there are many more to come!
Keep up the great work and enjoy your weekend!
Thanks for the explanation :)
Nice video, well presented and at just the right level of detail. FYI, Engadget embedded your video.
You earned yourself a new subscriber
Thanks for the neat and awesome explanation. So many concepts also you covered in small time.!!
Can I have couple of clarifications?
1)It is said in video that: "mmap doesnt copy the file into memory but it maps it to memory", what is the difference between the both?
2)"if we write to the mmaped file, will this never reflected into underlying file" when is this applicable? If we use these flags PROT_READ,MAP_PRIVATE ? Or in every case we use mmap??
3) what do we mean physically by "creating a copy"?? Does it mean writing to cache or allocating main memory for it? or.?
4)" mapping a file is different from reading it through a file descriptor.", any explanation for this statement?
Thank you
+anthony balaraju
1) copy a file into memory means you read the bytes from disk and put them in RAM. And then you work on the data in ram. When you directly map the file into memory, and you write to it, you write directly to the file on disk.
I think the word "memory" is a problem here. You should not thing of memory as your RAM. But generally anything that could be data. All data can be addressed with a memory address. For example 0x040010.
A computer program can access this memory address, but where the data for this address is coming from, can be different things. In most cases it's probably something in RAM, but when you mmap a file on disk, you access directly the disk.
This is all down by the memory management layer in the kernel.
Maybe swap files are easier to understand. If you run low on memory, the operating system might put some data in a swap file on disk. And when a program wants data, that got stored on disk in a swap file, the program doesn't know about this all. The kernel just handles this for you. It's all magic.
2) obviously when you map a file with write permissions you could also write to it. If you map it read only you can't write to it. But if it is mapped as private, and you write to it, a copy is created and you can write to the copy of it.
3) Where this copy is stored I actually don't know, maybe a cache or RAM. I assume it stores it in RAM. But not sure to be honest.
4) reading a file means, you use the syscall read to read from a filedescriptor, which probably refers to a file you opened before with the open syscall. And when you read from the file you read the bytes somewhere into your programs memory, which is RAM.
The mmapped file behaves like as if you already put the file content somewhere in memory, because you simply access a certain address, and the Linux memory manager will make sure to deliver you the data from the underlying file.
Sounds like i should make a video about thi
Haha.. Really, it sounds like you can make another 3 min video to explain this .!!
Never mind, your explanation here is as clear and good as in video ..
Thank you for that.!! :)
2)so it means PROT_READ flag is not required!!
I will ask one more and last question probably,
What I understood is:
private_write: 1)update pages (page table), 2)write to newly allocated private page/file
madvice: throw away allocated/updated private page/file
I seriously tried hard to understand why the data is directly written to actual page when race occurs!! If madvice discard that page, then still data has to be written to same address. !
I meant to say actual file and private copy, the addresses assigned will be different! so how could it be written to actual file due to race!!May be I am missed something!!
I just tried this and first I thought it didn't work because the program never stops (and just uses 100% CPU). But it turns out it did work and you can stop the program manually with Ctrl+C.
That was very interesting and cognitive explaination, thank you very much!
Hi LiveOverflow! Our lecturer just shared your video in class! :)
That’s awesome! What school/Uni is that?
Awesome review! Looking forward for more videos like these, thanks!
"... because I'm a hypocrite" - haha! Nah, that's just your ethics trying to do the right thing. I also feel information should be open and free, however some times we should take careful steps when you share information. I'm stuck in a loop of watching your videos, they are amazing and well done! Even though I read a lot about these vulnerabilities when they came out, I still value your point of view on them and I can use your videos to help explain these issues to others; thanks!
can you make a video just showing strategies for privilege escalation? like "look after files that have root privilege and try to write in them some commands" etc. I mean, just a video about different privilege escalation strategies to look in a linux system, without any help from a framework like metasploit, just raw hacking
This exploit is so overpowered yet it was forgotten, this was used in many malware's and server break in's
Very nice explanation. You sir have earned a subscriber. Thank you!
Great video, thanks for posting.
Loved the Dr. Evil drawing.
Great video! Keep going!! Your channel is awesome! Off to try it myself!
This is fantastic; thank you for posting this!
Great explanation. I'll keep watching these videos if you keep making them :)
Excellent explanation. Thanks!
I still miss the point in the race condition. How come one manages to bypass the mapped memory and write directly into read-only file? Shouldn't the write always spawn a copy of such a file?
> Shouldn't the write always spawn a copy of such a file?
Yes it does. But there is this bug that we exploit, madvise(DONTNEED) will always throw away the page again. So while the write triggers a new copy, if we throw the copy away before we get to write, we write to the original mapped memory.
edit: the concept of file permissions is enforced by the kernel. And this is a bug in the kernel. The read-only mapped memory causes a copy. But because of the race condition of throwing it away, we perform the write to the original mapped file, thus basically bypassing the read-only property.
I get your point. Still, it looks a bit odd to me because the Write writes on /proc/self/mem + map (that is where the copy of the file should be mapped in the process memory), not on the actual file.
I mean, even if you free that page, I would have expected that you write in a meaningless part of the process memory where the file was mapped. Instead, it happens that you write to a file that wasn't even addressed by the file pointer f (which referred to /proc/self/mem ). What am I missing? :\
> (that is where the copy of the file should be mapped in the process memory), not on the actual file.
no. this is where the real file is mapped to. As read_only. You directly read from that file. BUT when you write to it, you create a copy. And then the kernel's memory manager updates the page table and points to the copy. And that age table update is what you race.
There is an alternative version of this exploit where you don't write with /proc/self/mem, but with ptrace(). Maybe that makes more sense to understand.
So as you probably know, ptrace is used for debugging. So you can attach to a process, you can read memory from it, you can single step through the execution and so forth. Now ptrace also supports writing to the memory, because when you set a "breakpoint" with ptrace, you have to write a 0xCC (int 3) instruction to the code segment (code segment is also not-writeable memory). So in the alternative exploit, you ptrace your own process and write to that not-writeable memory. That feature has to be there for debugging purposes as explained above. BUT obviously you don't want to propagate changes to mapped read-only files. So in this case you trigger a copy-on-write and ptrace writes to this copy.
Now because of that throwing away (madvise(DONTNEED)), you exploit a race condition, that the memory manager just updated the page table to point to the original file and you write to it before it could create a new copy and update the page table again.
Great, thanks you a lot!
The github page also has a trace of the exact functions: github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails#analysis
Amazing video, thank you!
I don't think the /proc/self/mem file (or /dev/mem for that matter) is really intended to be written using lseek(2)/write(2) so that part of the code can be just written haphazardly. Most of the time those files are immediately mmap(2)'d after open(2)'d.
Great explanation! Thanks
Very good video, thank you.
Amazing! Really helpful for newbie sysads :)!
Hey LiveOverFlow loved this video! I was trying to walk through this on my own, quick question which kernel version did you use when demonstrating the exploit?
+Connor Schwalm unfortunately I don't remember. And I'm stupid for not having done a uname when recording.
Thanks for responding! No worries, I was able to figure it out. For anyone else looking to reproduce this video I was able to follow along by installing linux kernel 4.3.6 generic onto my ubuntu 16.04 LTS VM.
The fix was summarized in the commit message: "' "yes,
we already did a COW" rather than play racy games with FOLL_WRITE"
They explicitly flag the memory as being worked on for the time it takes to copy that file. The next time the copy is tried, it sees "oh, already tried this" and stops.
So this exploit is simply about the cow creation not being thread safe?
As it doesn't block thread executing write() before it properly finished so write() works with the old pointer
This video is so good omg
Perfect explanation....!!!
Excellent explanation.
This is useful for rooting android devices!
Just see this drawing at the Dockercon Austin on Intel expo, they use this picture to demonstrate their clear container technology.
My drawing is a copy of the logo here: dirtycow.ninja/
Does a link to the slides/recording/photo exist?
Man that "file" joke got real annoying real fast.
Other than that, excellent explanation and extremely instructional as always
awesome walk through!
another great video ! thumbs up !
would larger files that need more bandwidth be easier to cause race conditions with? since they easily could take more time than the dumping?
there is an exploit for either the xbox 360 or one of the play station consoles where access to the low level stuff for modding or something can be done by repeatedly rapidly resetting the cpu to exploit the very small window between power on and hypervisor kicking in to inject some code.
is that an example of a race condition?
sehr gut! danke!
Hi there, i have linux kernel version of 2.6.393 will it be vulnerable to dirty cow vulnerability? the Kernel version is derive from nmap
Great explanation
Hi LiveOverflow!,First thanks about the fantastic video secondly i have couple questions<
the madvise tells the kernel the map part isnt neded so the kernel must remove the contents of map (even if it's dirty) however what you said is the kernel removes the COWed that the procselfmem was writing to?!!! how would that happen (i dont know about if kernel code removes the map and it's copies if it's advised to remove ! is that the case?
the second question , processor just do what we say so if i told the processor to calculate 1+1 biion time its not going to be tricked and answer 1 at any of them
Hi, I have query about Linux privilege. Escalation, if the code is in .c format, and victim machine not having gcc installed, if I convert .c to executable in my kali machine and run that elf in victim system means will it works?
docker blocks the ptrace system call in the default seccomp profile. How did you get around this? I am unable to reproduce this with that profile in place. I am having to add --security-opt seccomp=unconfined.
+LiveOverflow I created a version that uses /proc/self/mem to get around this and works with any vDSO. I'm still curious about seccomp though? Is that in your docker-compose.yml file?
My bad. This has already been addressed here: github.com/scumjr/dirtycow-vdso/issues/4
Someone caught me watching this... "Wow, you really are a geek"
I felt ashamed, up until they broke out laughing at the ending, "But I practice ethical .. because .. I'm a hypocrite"
Just goes to show, even geeks, don't geek out on everything. Including explanations behind their ethics =D
Jo man, wo hast du das alles gelernt? Hast du Studiert? Ich will unbedingt mal sowas können wie du!
er hat studiert, sieht man gleich
thanks @LiveOverflow..I'm wondering something..I'm using debian 8.5 on a thinkpad e431, with 4gb of ram 128gb ssd; & the last presidential debate, I tried streaming it from youtube, found it sluggish toggling from full screen, & back, after 15minutes into the stream the graphics threw a fit, the screen got a tv static - like appearance, then went to into some color checking mode, I attempted to hard reboot, but got a black screen..After hard rebooting 3-4 times, I successfully got into the desktop, & attempted to stream the debate again, only to repeat the hard reboot(s) after another color checking mode, until I was successfully back into the desktop..I thought it was failing hardware, but checked the updates, I had kernel headers, & kernel updates waiting...After updating I haven't had an issue since;could this have been related to the dirty cow exploit?forgot to mention, I had tcpdump running in bash while streaming, with was a root process..
sounds unrelated to this exploit. I still suspect slow hardware failure.
I am confused about how you said that 'mapping' the file was reading directly from disk. Are you sure? I thought the only difference that MAP_PRIVATE made was that when writes occur, they are not committed to the original file (fd) but instead are made local/private to new pages. What makes you say that the file is read 'directly'? I don't see that in any of the mmap documentation.
how is "reading from the real file from disk" in any conflict to "writing is not committed to the original file" ;) it's copy-on-write
MAP_PRIVATE: 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.
@@LiveOverflow I'm not saying it's conflicting. I'm asking where it says that it reads straight from disk, without mapping it into memory.
ahh.. I think there is a small misunderstanding.
what do you think "mapping to memory" means? Do you think the kernel performs a memcopy from the HDD into RAM? "The basic idea of memory mapping is to map a byte range of a file to a range of process addresses. [...] mapping is made, but no copying is done. Instead when one or the other process requires the data, a page fault occurs and at that time a single copy is obtained off disk," - www.cs.uleth.ca/~holzmann/C/system/mmap.html
What is the the "rare condition". How does the discretionary access control system actually get violated by mmap and the page table? I feel like this "explanation" video left out the punchline.
race condition not rare, google it and you'll get the punchline maybe
The discretionary access control is not violated directly; this is not where the vulnerability lies. The file mapped into memory must be readable by the executing process. The exploit works but reading in a suid root file and attempting to trigger a race condition in the kernel that allows you to write to the underlying file and flush the changes to disk before triggering a copy-on-write. This works due to the latency between the moment when a write syscall is requested and when the page table for the current process is updated. So, under certain circumstances the write is executed with a "non-updated" page table while the copy-on-write is being executed. Eventually the page table is updated, but you have already made changes to the underlying file. It's not entirely clear how the changes are flushed to disk, though. The patch just makes sure the copy-on-write operating has completed before allowing the write operation to complete.
So you're saying that by default, the page table points to the original file, which the write syscall then uses?
by default the memory mapped memory points to the original file. And when we trigger a write, the memory is copied, and we write to that copy.
You are gifted
What program do you use to make such great videos like this one on Linux?
I actually edit everything on Windows with Sony Vegas and making the graphics by hand with a graphics tablet and photoshop.
Your drawings are very good, such as the cow in this video!
I cheat. Have a look at the dirtycow.ninja cow. I simply trace it ;) still work though
LiveOverflow seemed like it. Anyways great videos mate!
Well explained! Keep it up!
madvice() has to modify the translation of the map pointer back to the physical location where the real file is loaded. Is it right?
great video!
im not a hacker, im a developer and i learnt a lot about Os and intricate details of the system.Thanks for the video.
However, I would still like to know how this race condition is causing this to happen,..i mean the root cause.
Some time ago I found a pretty serious exploit in a hosting website (I won't name anything) and told them exactly how I did it and how I would take care of the issue. Only thing I got in response was "We will look into this with our team. By doing this, you ware voilating our ToS. Your account may be banned blablabla" :3
Nice illustration & animations
Very niceeee!
awesome videos . i'm subscribing :)
Nice explanation..
why are you writing to /prop/self/mem. correct me if I am wrong , the mem contains the whole process memory. so how only mapped page is affected and why are you not using the returned file descriptor of mmap() to write to the file.
1. mmap doesn't return a file descriptor, mmap returns the address where the file was mapped to. So it's some address in the process memory. We don't write there, because we are not allowed to write to that file. But we keep spamming the madvise on that memory area.
2. we open /proc/self/mem and seek (go to) the address where the file was mmaped to. And then we keep writing to that.
Thanks man! +1
when music on wrong sdie
you were on the hacker news!!!
The answer to your question could be found at the below link.
From what I understand it's because it simulates a page fault which only happens if /proc/self/mem was used.
chao-tic.github.io/blog/2017/05/24/dirty-cow
thanks!
Unexpected End Of File:
File Meme Not Over
Good work. :-)
You should equalize the video music, its only playing in my right side
thanks
does this work on s5 at&t marshmallow ?
Which language is used to code dirty cow ??
This exploit was used by kingroot in wild to root phone
Thing is I can still write to the root file anyway with vim/vi if I just use w! or qw!, I couldn't get it to work on say the sudoers file in Debian 8
thats not how the permissions work on linux. Observe carefully the user who owns the file and what the permissions are for other users.
+I2obiNtube that is not true. That would be a huge security issue. Look at the permission of the file. It doesn't belong to root anymore after you w! it. And the reason why you were able to delete and write your user file instead is, because you are probably in your home directory which has your user permission. unix.stackexchange.com/questions/58880/how-does-vim-steal-root-owned-files
sudhakar verma LiveOverflow superuser.com/questions/900888/vi-can-write-to-file-despite-file-being-read-only
Have a weird suspicion it's just this. Tested a few more times with non rw'd directories and it didn't work. Probably missing something (pretty sure my kernel is vuln, but could be wrong).
try mkdir test, chown root:root, chmod 0404 the directory and a file in there and chown it to root:root
Great job on this video. Even with my near zero Linux knowledge, I could follow it enough to be interested and understand at least the key concepts. You put in a lot of work to explain, illustrate and make it entertaining. Much appreciated.