Bad Binder: Android In-the-Wild Exploit | Hacker News Reader

Bad Binder: Android In-the-Wild Exploit

googleprojectzero.blogspot.com

139 pointsel_duderino52 comments

>The Original Discovery of the Bug

>This bug was originally found and reported in November 2017 and patched in February 2018. Syzbot, a syzkaller system that continuously fuzzes the Linux kernel, originally reported the use-after-free bug to Linux kernel mailing lists and the syzkaller-bugs mailing list in November 2017. From this report, the bug was patched in the Linux 4.14, Android 3.18, Android 4.4, and Android 4.9 kernels in February 2018. However, this fix was never included in an Android monthly security bulletin and thus the bug was never patched in many already released devices, such as Pixel and Pixel 2.

Yea, that's a very large number of active devices, for a bug that's believed to be actively exploited. Roughly 75% going by this: https://android.stackexchange.com/questions/51651/which-andr... plus https://developer.android.com/about/dashboards

Even my currently supported device (Moto x4) is vulnerable because it hasn't received the October 6 patch. It's more than halfway through November, and I'm still on the October 1st patch. The vendor patching system is pretty terrible with Android and ends up leaving many devices vulnerable to publicly known exploits most of the time.

You don't need this patched. moto x4 has had this patched since the release of pie.

You can check for yourself at the source code here: https://github.com/MotorolaMobilityLLC/kernel-msm/blob/MMI-P...

Most devices already have the patch from the upstream kernel: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

That's good news, thanks.

P0 has gotten a lot of unwarranted flak on HN recently for allegedly only disclosing vulnerabilities in competitors' systems.

This is a perfect counterexample of a really nasty privilege escalation in Google's own OS.

I'm interested in arguments as to how said flak could qualify as valid criticism.

Security research is inherently adversarial in nature, and it seems fitting to have competiting parties doing security research on one another's products.

Presumably, Android development involves some measure of security assessment?

If project zero never spent a day looking at Android, but all their competitors did, I don't see the issue.

If there aren't any/enough competitors, that seems very unlikely to be a security or security research related problem.

It goes back to they first time they publicised a Microsoft exploit after the 90 disclosure window, but before Microsoft had patched it. Microsoft went into full media blitz mode about how terrible P0 was, how insecure they were making everyone etc.

I basically stopped reading Peter Bright's articles on ArsTechnica because of how he spent a couple weeks writing uninformed articles about how responsible disclosure in general and P0 specifically were terrible.

> Security research is inherently adversarial in nature

Interesting. My perception is it's often based on bragging rights. Which is more about ego than about an adversary. According to that theory, what matters is how deeply you understand systems or how determined you are to go the extra mile to find issues.

This extends to organizations which want to bolster their image by being at the leading edge of research.

Anyway, having an adversary is part of the picture, but what you really care about is not the victory over that adversary but your superiority on the battlefield

Please read "the security mindset" by Bruce Schneier:

https://www.schneier.com/blog/archives/2008/03/the_security_...

Perhaps I was taking "adversarial" too literally, but to me it normally suggests an antagonistic or hostile attitude toward the other side. For example, if two next door neighbors don't get along and one of them reports any little infraction to their homeowners' association, they are adversarial. It's sort of the opposite of cooperative.

And this is not how I see the motivation and attitude of most security people. For them it is mostly about the satisfaction of (or other inclination toward) understanding how and where something might be vulnerable to exploit. It is a particular type of thinking related to creativity, thinking outside the box, and seeing things from a different perspective. (So basically what Schneier's essay says. Which fits with my point.)

There is nothing sophisticated or clever about a neighbor calling the homeowners' association. What they're interested in is the effect their actions will have on their adversary. But a security researcher doesn't usually care to actually exploit vulnerabilities. Or if they do, it is only to prove that the vulnerability exists, not to gain from it.

So, getting back to the original point, I just don't follow the reasoning that security researchers would prefer to avoid finding holes in their own employer's systems. If they viewed everything as us vs. them, then yes, they would want to take sides and protect their employer. Instead, I think that because what they really care about is understanding vulnerabilities, they would want to understand them wherever they see them, own employer's systems included.

To be precise, P0 is accused of focusing on finding bugs in competing products. This is a bug they were told about, not from original research.

... which is what vulnerability research teams are supposed to do, of course. Finding bugs in other people's products is, effectively, a donation to those projects. Google pays consultants many tens of thousands of dollars a pop to get the same work done for their own products.

To be even more precise, I don't care how P0 spend their time. If people don't like them blowing up their products, make better products.

But writing up an exploit that was basically handed to them is pretty weak evidence against the angry narrative.

Right, something like this page is better evidence against that narrative:

https://bugs.chromium.org/p/project-zero/issues/list?q=Produ...

The narrative seems to be both that p0 doesn't do research into Google's stuff, and that p0 doesn't post bulletins about vulns in Google's stuff. Both are untrue, but if you point out one, people flip to the other.

The amount of work they put into finding issues isn't relevant though, it's the benefit google might be getting from other companies bad PR. So this situation still seems like a counterexample to me.

It's only a donation if you assume the vulnerability is not cutting edge, otherwise it doesn't seem unfair to label the disclosure as corrosive to the current zeitgeist in terms of user safety. Just because you've managed to marry genuine research and politics doesn't mean that you've eliminated the more general bias produced by researching/disclosing information about opposing products more frequently than your own. At the same time, this also doesn't mean the system is bad, it could be entirely possible that the status quo of security without adversarial research is much worse for the end user.

I don't know what any of this means. The vulnerabilities exist no matter who discovers them, and vulnerability discovery is a service every major vendor pays dearly for. If the optics of discovery are bad for Apple or Microsoft, Apple or Microsoft should spend more to keep from being one-upped by P0.

From what you've said it seems like the difference is more an issue of framing. You're focused on the effects for the end user, which are the same no matter what in my opinion and I agree on that. At the same time, if you're publishing exploits that are cutting edge and primarily only apply to the competition then, because you (in this hypothetical) are a company, the overall effects of the research are self serving. Why not publish more vulnerabilities that apply to your own systems otherwise? Surely you (again, the hypothetical you) are in a better position than other entities to engage in introspective research that benefits the end user. Obviously there's a possibility that the explanation is "Because the competition has more flaws than our/my own product" but without evidence such is the case then there isn't a lot of reason for outside critics to give the benefit of the doubt. Also, I'm not a security researcher so I realize some of my points might not be accurate to the state of the industry. I'm moreso trying to highlight the lines of thinking that lead to criticism of P0 and why I don't think they're easy to refute without a certain degree of burden on Google's/Totallyrelatedbutnot-google's part.

I don't understand really any of this. Finding vulnerabilities in your competitors products is in fact a donation to those competitors and, more importantly, their users.

It sounds like the idea that it's a donation is the part where we fundamentally disagree then. If you expose an unpatched exploit and the number of people using that exploit goes up because of your publication then you've contributed to worsening the security landscape for whoever the relevant user is. If an exploit is years old, or if there's some other relevant context, then sure exposing a vulnerability mainly means that the parent company doesn't have to pay for the research. But it's not a favor they asked you to perform and if you have a competing product with that company then the question becomes "Why aren't you publishing more about yourself?" since surely no one is in a better position to do security research on your products than yourself or a contractor you hired. It's basically PR motivated research and when there's also a lack of transparency it leads to easy speculation that maybe you're holding back research on yourself purposefully or even simply not publishing the more damning research you discover about your own products.

There's no "agreement" or "disagreement" to be had here. Vulnerability researchers don't create vulnerabilities, they find and ultimately eliminate them. Vulnerability research at the level practiced by P0 commands huge daily rates, and Google's competitors actively pay those rates to other researchers. It is simply a fact that what Google is doing is a donation to other vendors and their users.

You can dispute their intentions, but I'm not all that interested in debating those. What you can't do is debate the effect, which is positive.

If you're not interested in debating their intentions then why frame it as a donation? That by itself is a normative judgement in this context, and the reason I brought up framing, since normally two primary characteristics of a donation are that it can be refused and that it is being offered in good faith.

This is the same general point that the original comment you had replied to was making which itself was an explanation of why people are distrustful of P0 even if the brass tax is positive for the end user. It's fine if you don't find that political side of it interesting but it's not as simple as just being a donation.

Google's competitors are getting a thing of great value at no cost. That's what a donation is.

If it's a great value then why isn't that effort being directed entirely towards google products? I get the argument you're making I think, that it's free valuable labor. But if that's true then what explanation is there for primarily publishing about competing products? Even if the argument was purely user safety then surely there would be no reason to publish unpatched problems publicly which has happened in the past and seems like the sort of thing that group like P0 could have chosen to handle in a more graceful fashion. Somewhere in the chain of command is a reason for why P0 focuses where it does and it doesn't seem likely that the reason is "Because we're rolling in gold and Apple and Microsoft could use the money."

There's no amount of axiomatic reasoning you're going to be able to generate to make your argument work. Vulnerability research is expensive. Google is giving it away to its competitors. Those competitors and, much more importantly and to a greater extent, their customers, benefit directly. Those aren't so much statements of opinion so much as they are simple facts.

Kind of relevant, a friend of mine posted his own writeup about exploiting this bug earlier this month.

https://dayzerosec.com/posts/analyzing-androids-cve-2019-221...

"NSO" is referred to in the article, but it's never expanded or explained.

Apparently this is the "NSO Group" [1], a private company in Israel that sells "Pegasus" [2] (also referred to in the article).

[1] https://en.wikipedia.org/wiki/NSO_Group

[2] https://en.wikipedia.org/wiki/Pegasus_(spyware)

It's not an article so much as a P0 blog post. The list of terms of art in this post that ordinary readers wouldn't grok is long indeed.

NSO is extraordinarily well known in the security field; they're one of the best known (but almost certainly not the largest or most effective) purveyors of mobile exploits and malware (to governments). For P0 (and Apple), NSO is "the adversary".

OK, I'm going to have to ask: who are the largest and most effective?

Cellebrite is a popular supplier for mobile forensics, which may require using vulnerabilities are not yet patched, i.e. finding or buying zerodays.

Different market and different product. Cellebrite customers have the devices in hand, and need to extract data for forensics. NSO customers compromise phones remotely and silently in order to spy on what the owner is doing.

How does NSO and/or it's customers steer clear of CFAA violations? Are they given some kind of perpetual amnesty?

Edit: Oh, they ran up against this just a few weeks ago according to their Wikipedia article. How about that.

In addition to the fact that they're not a US company, selling exploits doesn't actually violate CFAA.

Google could potentially sue them under civil CFAA if there was some unauthorized access to Google infrastructure needed to develop the exploits, but that's unlikely to be the case.

Using NSO tools against unwilling targets would violate US law, but that's not what NSO does.

According to recent articles I’ve read this may not be the case. Apparently at least one organization has accused NSO of doing the unlawful accessing.

Standby while I look for a source.

Yes, WhatsApp sued NSO under civil CFAA (among other things) for accessing their infrastructure in the process of building and running their tools.

Interesting that Google's syzbot found and publicized the flaw, possibly bringing it the awareness of bad actors. But at the time the flaw was not flagged as being security related and was thus not backported as a security patch.

If Google's syzbot had checked the kernel for the flaw before it was released instead of after, that also seems like it would have prevented the issue from going live in the first place.

Why does the Linux kernel project continue to release code with flaws like this that can be found with automated tools?

> Why does the Linux kernel project continue to release code with flaws like this that can be found with automated tools?

Because they have no other option, it's a fuzzer. Therefore, it may take a long time(up to universe heat death) for it to finally exercise the path that causes the issue. And the kernel has a pretty enormous footprint.

Fuzzers never really terminate, so it is not like you can plug it on a CI/CD system and wait for reports.

> The process of reproducing one crash may take from a few minutes up to an hour depending on whether the crash is easily reproducible or non-reproducible at all.

That's for one known crash. But otherwise it will be running 24/7 (across multiple VMs!) looking for issues.

More details here: https://github.com/google/syzkaller

Depending on what was meant by "like this", they do have the option of fixing this class of bugs (memory safety vulns), using mature tried and tested programming language practices and technology. It's a decades old debate between the C enthusiasts and the correctness/security enthusiasts. (Same problems and options are of course available Apple and Microsoft - it's not just Linux)

What technology would you have suggested be used here to catch this vulnerability early?

This is just a longer worded version of Rewrite It In Rust :-P

fulafel is not advocating catching the vulnerability, fulafel is advocating a more secure design. One possibility is Rust.

Well, Rust is not that mature, I agree today it would be an option worth considering. But people have been writing ring-0 code in safe languages for decades. And of course there are more dimensions to robust kernel design than chocie of programming language.

In the Linux kernel? Good luck…

It finds memory safety bugs, so it would be prudent to treat all findings as security bugs by default. The binder driver maintainers did get notified right away and it's a prominent part of android attack surface.

> Why does the Linux kernel project continue to release code with flaws like this that can be found with automated tools?

This was fixed by the next release.

What happened here is 100% on Googles android team who don't follow mainline kernel releases & patches.

> Hunt for bugs based on rumors/leads that a 0-day is currently in use. We will use our bug hunting expertise to find and patch the bug, rendering the exploit benign.

This is probably the most fundamental issue with Android security. Google patching the bug often doesn't render it benign. There are still far too many places in the Android update process where bugs can remain malign as hell on millions of devices even after Android itself has been patched and the user keeps their device to the latest available version.

Why can't google/blogspot ever work well on mobile!? Google hides sites that are not mobile friendly but they don't fix this? I bet it's their user-agent detection where they serve you different content based on the mobile browser you use (i.e.: if you don't use a popular browser, even if it uses webkit like chrome you get crappy content)

Works well in mobile Firefox for me.

My mobile browser is based on firefox and it doesn't for me. Which is my point about UA detection.

> On October 3, 2019, we disclosed...

> We reported this bug under a 7-day disclosure deadline rather than the normal 90-day disclosure deadline. We made this decision based on credible evidence that an exploit for this vulnerability exists in the wild and that it's highly likely that the exploit was being actively used against users.

It's now nearly two months since discovery of the bug and that it was being exploited in the wild, and my still-in-support Pixel still doesn't have the patch for this. What the hell Google. How is this even close to alright for a CVE such as this? Totally unacceptable.

Give me my damn PinePhone already!

Are you sure your Pixel is vulnerable? Looks like the patch for Pixel 1 & 2 was released October 7th.

https://source.android.com/security/bulletin/pixel/2019-10-0...

Reply on news.ycombinator.com