Skip to main content

Android Patch For High-Severity 'Dirty COW' Linux Kernel Flaw Delayed For At Least Another Month

Google published its November security bulletin describing all the recent patches for vulnerabilities in Android, but a major one seems to be missing. The Linux kernel vulnerability, called “Dirty COW,” affects all Linux and Android devices that use kernel version 2.6.22 or newer and is a "High-Severity" bug that allows remote privilege escalation and can’t be mitigated by existing OS protections.

Linux Bug Of The Decade

Dirty COW has been considered one of the most serious Linux bugs of recent years, not just because it allows privilege escalation (something many bugs are capable of doing), but also because it affects all Linux and Android devices from the past decade. Worse yet, because it's such an old bug, it may also be under active exploitation (or if it hasn't been so far, it certainly will be now that it's public). This bug gives attackers around a billion and a half targets, unless those devices are patched soon, something that's much easier said than done for Android.

Dirty COW has been so named because the bug affects the Copy On Write (COW) resource management mechanism. An unprivileged local user could gain write access to what would otherwise be read-only memory and then increase their privilege on the system.

The bug was first discovered in May, but it was revealed to the public just last month after a coordinated effort by security researchers to create a fix before everyone, including potential attackers, learned about it.

Why A Dirty COW Patch Isn’t Yet Available For Android

Linux users have already started applying the Dirty COW patch to their systems, but Android users won’t be as fortunate. As Google makes new patches for Android vulnerabilities a month after they’ve been given to the OEMs, the Dirty COW patch couldn’t land in the November security update. This process exists so Google can coordinate with OEMs, so they can release the patches for their own devices roughly around the same time as Google makes them public.

The coordinated release also ensures that at least some devices get fixed for the vulnerabilities that are made public. However, those that get no updates (or won't get any for some time) may still remain exposed to new attacks that take advantage of the new software flaws.

Other Serious Flaws Fixed In The November Update

The Android team found only two critical vulnerabilities in the latest version of Android itself, which is an improvement from the previous two months. However, one of those flaws is related to the mediaserver library once again. Despite the sandboxing of various mediaserver library components in Android 7.0, the team is still able to find more critical or high-severity bugs in it almost every month.

Other high-severity and moderate flaws were also found in this library, as well as in the graphics, Bluetooth, OpenJDK, System UI, Android Runtime, and even the BoringSSL crypto components of the operating system. Google also found multiple critical and high-severity bugs in Qualcomm’s crypto and camera drivers, as well as in Nvidia’s GPU drivers.

Google’s monthly security bulletins and patches have been a step forward for the security of the Android ecosystem, but it also showed just how vulnerable unpatched Android devices could be--Google finds dozens of new critical-, high-, and moderate-severity Android bugs every month.

Google may still be able to protect the majority of users against these attacks through its anti-malware service (“Verify Apps”), but this likely doesn’t work as well for targeted attacks against individuals or even against small-scale (sub-100,000 users) infections that may harder to identify quickly in the wild.

  • alextheblue
    Just like I said in the article where Google gave MS 7 days before going public. They've known about this since May and it's just being talked about, and still not patched. Oh and when they do patch it 90% of Android devices will remain vulnerable for an unknown amount of time, many will never get patched.

    Oh and if you look around it IS being exploited in the wild and has been for some time. It's actually quite an old bug (years old), and the people exploiting it sure aren't talking about it. So who knows how far back abuse of the flaw goes. But I think 7 days should be enough, right Google?
    Reply
  • ZolaIII
    It's fair to say we made a RAM stakes from this one long time ago on Android. The ports of original Linus patch for variety of kernel versions used on Android (from 3.4 up) is available for quite some time. I know for sure it's officially merged in CM 14 along with various costume kernel builds. At least to say that a this one will be patched on most Android devices that still have running development thank to its popularity. For a devices that come DOA or didn't have maintenance for long periods of time answer is simple don't buy from that brand ever again.

    Thing that passes me most is that their is a lot of similar security flaws that don't get any press attention. On open platform with such a much eye's put on it (code) at least flaws are quickly spotted & patched & that is something we simply can't say for any other closed source one.
    Reply
  • extremepenguin
    7 Days Google, that was your limit you have now had 7 Months and there is still no patch. Hippocrite much?
    Reply
  • Nolonar
    What I'd like to know is how this bug is exploitable.
    Do attackers simply need to discover my device on the network?
    Do they need me to install an app?
    Is physical access necessary?
    Reply
  • mxttie
    My nvidia shield was patched for dirty cow last week
    Reply
  • techy1966
    Dirty Cow who names these? Also was it not Google that says 7 days is enough time so where is the patch Google and are you going to force Phone makers release it to both new and older phones so they are not exposed to the exploit after all you were quick to fault MS for taking 7 days for not posting a patch for the flaw you exposed to the world with Windows.

    Also what is wrong with Toms Hardware page? I use Firefox and on 3 different systems with different hardware spec the Toms hardware page seems to make Firefox stop responding on those 3 systems I use after being on the page for a bit. I would think it has something to do with one of the ad's on the page not playing nice with either your page code or Firefox itself it probably is time to take a look at it. This has been happening for about 2 weeks now so there is the time frame as to where to look at what has changed on these pages. Thanks
    Reply
  • chicofehr
    I'm a Blackberry 10 user and curios about side loading the OS or updates for unsupported devices. Is that possible? I'm just used to getting perpetual support for old devices sort of similar to the iphone. I'll have to switch to Android eventually as BB10 will cease to get updates in about a year but want to continue to get updates for 3-5 years like before.
    Reply
  • ddpruitt
    it may also be under active exploitation (or if it hasn't been so far, it certainly will be now that it's public)

    The bug was first discovered in May,

    Jesus Christ, don't you guys actually do any journalism anymore before posting stuff? Both of these statements are wrong and misleading. The bug was found because it was under active exploitation. and it was not discovered in May. CVEs (like Hurricane names) are allocated in batches ahead of time May was when the CVE was first reserved
    Phil Oester discovered the flaw on October 13th and it was patched upstream by October 21st. The patch hasn't made it downstream to Android yet. Due to the kernel version that it was discovered in its likely that most older devices will never receive the patch since it would require changes on older kernels where the fix will be different and it might break things.

    Giving out bad information is far worse than giving out no information. 30 seconds of reading would have prevented this dangerously inaccurate information from being published.
    Reply
  • alextheblue
    Looks like Torvalds discovered it years ago, actually.

    https://lkml.org/lkml/2016/10/19/860
    Reply
  • bit_user
    18844918 said:
    What I'd like to know is how this bug is exploitable.
    It's a privilege escalation bug. So, they'd either need to login to your box/device as a non-root user, or they'd have to remotely exploit a bug in a program (such as a web browser or media player) to execute code which can then get root and do whatever it wants.

    So, if your box or device is otherwise well-secured, then the risk isn't terribly high. But security holes in Java, web browsers, and the libraries they use are being discovered all the time. So, I think it's fair to say there's some risk to client devices like phones and desktops.

    Of course, if you install & run untrusted apps, they might be trojans/malware that can more easily exploit this to take over your device and add it to a bot net, etc.

    18846118 said:
    Dirty Cow who names these?
    The article says:
    Dirty COW has been so named because the bug affects the Copy On Write (COW) resource management mechanism.
    The word "dirty" refers to the way the virtual memory management system tags memory pages as being "dirty", when they contain modifications.

    I don't know if this is any sort of official name, or just how the kernel developer community is informally referring to it.
    Reply