Or “Washing Dirty COWs”… ( “dirty”, or not very well done, Copy On Write bug)
Basically, all you need to do on Linux is swap in a patched kernel.
Now there’s lots of potential hair on that dog. For example, under Debian, the patch is in the kernel in Jessie 8 but may or may not be in Wheezy 7 or earlier, I just can’t tell yet. Retrofitting a kernel that is built for a very newer major release sometimes “has issues” with older releases (libraries are different, expected services and interfaces might change). So for very old releases, it is best to make a brand new kernel from source, adding the patch, and compiling with the right libraries. Because being a “kernel developer” is generally thought to be “not easy”, most folks just do an entire operating system update / upgrade. Since I’m very unkeen on SystemD I’m trying to avoid that, and stay on Wheezy to avoid it. For this reason, many of my older Fedora, Ubuntu, and Debian images will be harder to update, and / or I’ll just not bother.
The Upgrade / Update Path
So, mostly, this top posting is going to be for folks who are going ahead and doing the update / upgrade process and ending up with Debian Jessie and a new patched kernel on a Raspberry Pi, or folks running Arch (like my Daily Driver) that does have SystemD in it, but not in too obnoxious a way. I’ll come back to the harder cases later when I’ve got a couple of usable chips cleanly patched / upgraded.
For those running the most recent Jessie / Raspbian as your system, the fix is nearly trivial:
You may have seen the news recently about a bug in the Linux kernel called Dirty COW – it’s a vulnerability that affects the ‘copy-on-write’ mechanism in Linux, which is also known as COW. This bug can be used to gain full control over a device running a version of Linux, including Android phones, web servers, and even the Raspberry Pi.
You don’t need to worry though, as a patch for Raspbian Jessie to fix Dirty COW has already been released, and you can get it right now. Open up a terminal window and type the following:
WARNING! THIS KILLED MY BerryBoot Chip!
It is generic Raspbian NOOBS only! Until proven otherwise
And even that has not been tested by me…
and people wonder why I have 60 system images on a dozen chips
with backups of each…
sudo apt-get update sudo apt-get install raspberrypi-kernel
Once the install is done, make sure to reboot your Raspberry Pi and you’ll be Dirty COW-free!
Yup, that’s all it takes. Two lines run via ‘sudo’ or you can become root and just type the parts after sudo…
It will likely take some testing and or FM (“Friendly” Magic…) to make the newest kernel work with Wheezy, so that’s going to be for “another day”. As several of my multi-boot chips have a Jessie image on them, my first pass will just be doing that on them. At that point I’ll have several Raspbian images on chips that I can boot and run without Dirty COW worries. THEN I’ll come back and work on the Jessie issue and some time after that, the Ubuntu (that ought to be about the same) and Fedora (who knows what) fixes.
FWIW, this bug was only introduced in 2007, so older kernels will not have it. Digging Here! into just when it arrived:
PostPosted: Sat 22 Oct 2016, 05:20 Post subject:
Maybe not moot
Slacko5.7 by default has settings of -rwxr-xr-x for a great majority of files.
Group and World read-only priveledges can be changed with this bug. and in addition, its a kernel bug since 2.6.22.
So if 2.6.21 or smaller, you are OK (some of those very old systems of mine in the garage, or some old live CDs…) but if newer than that, it’s a problem. What number is fixed?
#2 2016-10-24 17:43:40
From: Asteroid B-612
Re: [SOLVED] Status of CVE-2016-5195 (“Dirty COW”)?
It was fixed for kernel 4.8.3 and Arch is now on 4.8.4 so you’re covered wink
All well and good if you have kept updating regularly or have autonomous updating turned on. If not, how do you know your kernel level? “man uname” is your friend…
UNAME(1) User Commands UNAME(1) NAME uname - print system information SYNOPSIS uname [OPTION]... DESCRIPTION Print certain system information. With no OPTION, same as -s. -a, --all print all information, in the following order, except omit -p and -i if unknown: -s, --kernel-name print the kernel name -n, --nodename print the network node hostname -r, --kernel-release print the kernel release Manual page uname(1) line 1 (press h for help or q to quit)
Soo… what’s my status?
chiefio@ARCH_pi_64:/boot$ uname -r 4.1.19v7-aufs chiefio@ARCH_pi_64:/boot$
Oh Dear… Looks like I need an update…
How to do it? Very similar to Debian, but with “pacman” instead of “apt-get”.
sudo pacman -Syy sudo pacman -Su
Unfortunately, when I did that, I ended up with “issues”. First off, it complained about a file being in the way, so I moved it out of the way and the upgrade proceeded.
-rw-r--r-- 1 root root 369577 Oct 11 08:30 brcmfmac43430-sdio.bin -rw-r--r-- 1 alarm alarm 309681 Mar 1 2016 brcmfmac43430-sdio.bin.old -rw-r--r-- 1 alarm alarm 1076 Mar 1 2016 brcmfmac43430-sdio.txt -rw-r--r-- 1 root root 488193 Apr 19 2016 brcmfmac43455-sdio.bin chiefio@ARCH_pi_64:/usr/lib/firmware/brcm$
So you can see the .old and the replacement that the upgrade put in just below it.
But then, when rebooted post update, some things had a systemd “failed” to start at boot time and now it also refuses to do the update again (looks like networking is broken).
The good news is that I had a ‘fall back’ system image on the same chip (named “Arch Chiefly Built” from which I’d cloned the working copy.) Then there’s the fact that my working directory is on its own file system, so it transports to the other images. What have I lost? At most, whatever I installed on the Chiefly image Clone but didn’t note anywhere and didn’t make a new system save image. (Don’t know what that would be, but hey, not a big deal to install ‘whatever’ again…)
Oh, and the kernel didn’t update to a new value either. So looks like “needs work” on the Arch upgrade procedure…
More later as I work through this… (this will be a ‘living document’ for the duration of the updates…)