DirtyCOW

I go on leave for three weeks, and this happens.

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.

Fake, inflated self importance aside, the joke I was attempting to make regarded the timescale. Linus’ (Linus’s?) initially observed the issue back in 2007, according to the kernel commit logs. And it’s impacted most distributions since, specifially:

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.

This flaw allows an attacker with a local system account to modify on-disk binaries, bypassing the standard permission mechanisms that would prevent modification without an appropriate permission set.

The key is it’s a local privilege escalation attack; one would need access to the target first. Once a nefarious user is in though, they may as well be running as root for all practical purposes.

I could gloat as a FreeBSD guy, but we had our own nasty issue recently too. One could include any manner of extra files in a package, and it would still pass verification and install.

The lesson here is (to poorly paraphrase an old lecturer and friend): software is like Swiss cheese. Holes are inevitable; it’s when they line up when issues arise.


Imprint

This is one of about 5000 posts on Rubénerd. View the home page for the latest, or related posts also tagged with:

If you liked this post, feel free to buy me a coffee, leave me a comment on Twitter, or email me at weblog2017@rubenschade.com. Thanks :).