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.
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?
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.
Do attackers simply need to discover my device on the network?
Do they need me to install an app?
Is physical access necessary?
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
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.
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.
The article says: 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.