4 ms·

No, it requires only two threads to trigger the race. Two processes are not needed.

by amscanne 10y ago

kentonv 10y ago
https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13 https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13 > Please note that this mitigation disables ptrace functionality which debuggers and programs that inspect other processes (virus scanners) use and thus these programs won't be operational. > 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. Is everyone barking up the wrong tree here? EDIT: All of the PoCs here use ptrace() or /proc/self/mem. Why would they do that if they didn't need to? https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
- kentonv 10y ago
  I just talked to amluto who explained that the race can only be triggered by a write that uses the "force" flag to get_user_pages() (a kernel function). /proc/pid/mem and ptrace() do this but regular writes and process_vm_writev() do not.
kentonv 10y ago
Update: We talked to Andy Lutomirski who was involved in reverse-engineering the original exploit and tracking down the bug. He says the code path is not triggered by regular memory writes; you have to go through ptrace() or /proc/self/mem. Details in this blog post: https://sandstorm.io/news/2016-10-25-cve-2016-5195-dirtycow-mitigated https://sandstorm.io/news/2016-10-25-cve-2016-5195-dirtycow-... Of course, if you have evidence to the contrary, we'd all like to know about it! (You are technically correct that the writes can come from another thread rather than another process, but the important part is that it has to go through one of those interfaces.)

4 ms·

No, it requires only two threads to trigger the race. Two processes are not needed.

by amscanne 10y ago

No, it requires only two threads to trigger the race. Two processes are not needed.

kentonv 10y ago
https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13 https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13 > Please note that this mitigation disables ptrace functionality which debuggers and programs that inspect other processes (virus scanners) use and thus these programs won't be operational. > 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. Is everyone barking up the wrong tree here? EDIT: All of the PoCs here use ptrace() or /proc/self/mem. Why would they do that if they didn't need to? https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
- kentonv 10y ago
  I just talked to amluto who explained that the race can only be triggered by a write that uses the "force" flag to get_user_pages() (a kernel function). /proc/pid/mem and ptrace() do this but regular writes and process_vm_writev() do not.
kentonv 10y ago
Update: We talked to Andy Lutomirski who was involved in reverse-engineering the original exploit and tracking down the bug. He says the code path is not triggered by regular memory writes; you have to go through ptrace() or /proc/self/mem. Details in this blog post: https://sandstorm.io/news/2016-10-25-cve-2016-5195-dirtycow-mitigated https://sandstorm.io/news/2016-10-25-cve-2016-5195-dirtycow-... Of course, if you have evidence to the contrary, we'd all like to know about it! (You are technically correct that the writes can come from another thread rather than another process, but the important part is that it has to go through one of those interfaces.)