Last updated at Wed, 30 Aug 2017 01:06:01 GMT

Hi folks! Sorry about the delay on this week's blog post. I've been responding to a few concerns about this week's Android revelations about the no-patch policy from Google with regard to nearly a billion in-use Android handsets, and incidentally, caught a face cold that's been floating around Rapid7's delightful open-space office model. I'm back online and fully functional, now, so I'll try to summarize here what I saw and responded to this week.

Pre-Jelly Bean Android WebView Patches

by used under CC-BY")If you somehow missed it, I published a blog post earlier this week about how Google now is telling vulnerability researchers (at least, a couple that I know) that they will no longer be providing patches for pre-Jelly Bean Android. This ended up getting some pickup from such esteemed media outlets as the Wall Street Journal, Forbes, and Taylor Swift, which generated a few thousand comments spread all over the Internet. I'll take a stab at summarizing the critical reaction here, and I promise I'm being sincere when characterizing these sentiments fairly. If I screw it up, please tell me.

OEMs don't patch anyway, so who cares?

It's true that the security patching for Android is, at best, quite broken. I wrote a post back in November about this issue, and this rejoinder is totally valid.

My problem, though, is that we're talking about two different things. One, Google is (now) not interested in working up patches for Android for issues before KitKit (4.4), and two, downstream vendors are very slow on picking up patches from Google (if ever). They're related, to be sure. However, I don't think you can solve the latter problem without solving the former, and there are two problems here for sure.

With the second problem, you can easily argue that downstream OEMs, carriers, and retailers are dropping the ball by not applying patches for old, publicly reported vulnerabilities. However, if you consider that Google isn't producing patches any more for shipping and for-sale devices, I feel like there's no longer even a ball to drop for those OEMs. Moreso, I feel like this change in attitude from Google makes it very easy for vendors to shrug and disclaim any responsibility for old vulns on their devices. You can argue this legally, ethically, technically or otherwise and there's room for disagreement, but Google walking away from patches, in my mind makes this state of affairs much worse.

Now, with all that said: Today, we can test this! We have two Metasploit modules shipping today that breaks the security model for pre-4.4 WebView: one is fixed upstream, and one remains unfixed. I'm /very/ interested in figuring out which, if either, of these vulnerabilities sees a downstream patch on pre-4.4 handsets. It's a pretty ideal test case, since they were discovered and reported so close to each other.

If you keep tabs on downstream devices and patch adoption versus patch creation, I would love to hear from you. Let's work together to see what the practical effects of this policy shift is.

Jelly Bean is legacy, so who cares?

While it's true that Jelly Bean is two named revisions back, and KitKat adoption is ticking up nicely, it's not like everyone gets to automatically upgrade for free. There are hardware costs, time and convenience costs, the carriers often limit choices or penalize customers for upgrading, people don't know how to upgrade, etc. There's a whole host of reasons, some good, some not, to stick to Jelly Bean.

Let's remember that Ice Cream, Gingerbread, and Froyo together account for nearly 15% of tracked Android devices, and these guys are three, four, and five versions back! Heck, if I had an exploit that worked reliably on these phones, and I was the sort to go popping randoms who visit my evil website and snagging personal usernames and passwords, I'd be pretty thrilled to know that 15% of my target base is guaranteed vulnerable. After all, Windows XP accounts for about 18% of the total desktop market share today, and I know for a fact that there's an active criminal and government (and criminal government) marketplace for security bypasses on XP. 15% is good enough for plenty of shady applications.

Now, consider that when you add in Jelly Bean, you're talking about nearly half (46%) of all Android phones just by itself. Add to that the way-downrev versions, you come to way over half of all Android phones. So, where 15% is good for bad guys, 60% is way more than four times better. The value for bad guys is exponentially related to the install base.

Consider, too, that WinXP went end-of-life for security patches 12 years after initial release. Google's apparent attitude shift about patching WebView became apparent only 2 years (technically, 28 months) after Jelly Bean's release.

WebView isn't part of the Android OS anymore, so who cares?

Yes, Google took a great leap forward by decoupling WebView from Android as of the Lollipop (5.0) release. I'm thrilled for this, and in five years, I expect the majority of in-use phones will be Lollipop or later.

In five years, we'll also be shaking our heads in bewilderment over all those people stuck on KitKat at below, thanks to the above-mentioned broken patch distribution model for handsets. Or not? I hope not. That's just too depressing to consider. Let's move on.

It's just WebView, not Jelly Bean, so who cares?

If I'm an attacker, and I had to choose one component of Android to focus my exploit efforts on, it'd be WebView, hands down. WebView is the one component that's used in virtually every ad-enabling library to remind me that I still don't care about Clash of Clans, and is used when you don't click "open link in browser" in every web-rendering app.

It's even used in the About Phone license page (which itself can lead to exploitation, thanks to some crafty keystrokes from friend-of-the-show Jgor).

The fact that Google will patch AudioPlayer, but not WebView, in a pre-4.3 context is frankly baffling. Why they would choose to abandon the best exploit vector an attacker has makes absolutely no sense to me.

I use Chrome, not AOSP Browser, so who cares?

Chrome (and other browsers, like Firefox and Dolphin), do not use the WebView component, so switching to these browsers for your day-to-day is a great mitigation step. If you're using the bundled AOSP browser on Jelly Bean or prior, stop it. If you're using your carrier's skinned browser, it's almost certainly using WebView as well, so stop that, too.

That said, though, the underlying WebView component is still exposed via apps and ad networks. TrendMicro took a look at a bunch of aftermarket browsing, messaging, and other apps, and found that a bunch are still vulnerable.

And that's it..?

I really do hope that I've captured the criticism here accurately, in an (unironic) fair and balanced way. If I've misstated your favorite argument, or if you have another that I haven't captured here, please comment below, or pick a fight with me on twitter.

New Modules

While I'll happily talk all day about Android security, this wrapup is intended to cover the changes in Metasploit over the last three weeks and change, and we celebrated HaXmas in there, it's a little outsized. We have 11 new exploits, and 8 new auxiliary modules this week, for a total of 19 new usable modules to kick off 2015. Among those are, suprise, a new Cookie Theft module from Joe Vennix and Rafay Baloch that affects, double surprise, Android Jelly Bean. Will it be patched, ever?

Exploit modules

Auxiliary and post modules