How Dirty COW works from the Linux kernel’s perspective
chao-tic.github.io
chao-tic.github.io
I can imagine someone looking at that code and the part where the kernel says one thing (I don't need write permissions) when that is not actually true and thinking that's a bad situation, that smells bad.
And the fact that the kernel does this is bad enough, but it's really just a symptom of an underlying problem. And that problem is the fact that the kernel code has to do this lying to prevent a loop, Which seems like bad code design (or the result of a hundred other factors that make it look, at first glance, like bad design). And the solution was done in a sloppy manner (dropping that write flag, instead of being honest and doing the little bit of extra work, which they did in the fix for the exploit with that extra flag).
And then maybe if you have experience with this stuff you might recognize that within this code there's that race condition.
And from those two things you might go see if other things nearby in the code can help you exploit it and it probably evolves from there into this very complex exploit.
The thing is, I think, one person looks at that code and is like, yeah the kernel lies a bit here, but whatever, sure it's grand. And in 99.999% percent of the time it is and you're fine with that and walk on.
And another person, who has Hacker Nature, might think like, a) this is bad as the tip of an iceberg is bad for a ship and more importantly b) I wonder what happens in the 0.001% of the time where this isn't fine...
Or, of course, maybe someone was standing on the edge of their toilet hanging a clock, the porcelain was wet, they slipped, hit their head on the sink, and when they came to they had a vision of this exploit. ;)
This exploit seems to lie at the intersection of several things that I guess might indicate a higher-than-average risk of exploitability: shared memory, special provisions for debugging access to running processes, complicated and unintuitive (if not broken) semantics, and concurrency.
[1] https://www.youtube.com/watch?v=bg6-LVCHmGM&feature=youtu.be...
I think this is a great general rule. Any one of these things is a reason to tread lightly. All of them at once? Here be dragons.
[1] https://github.com/kernelslacker/trinity [2] https://github.com/google/syzkaller/
Instead of the processor running into bogus instructions and dying it finds valid but malicious instructions.
Generally what happened here is that a piece of state got lost in the layers of abstraction. This combined with a race condition is enough.
To be clear, I'm just adding a bit of context around why a page in a read-only mapping is COWed when these debugging interfaces are used to write to it, rather than failing with an exception. The bug existed in the handling of this edge-case.