8 ms·

Bad Binder: Android In-the-Wild Exploit

139 points by el_duderino 7y ago

ogre_codes 7y ago
> 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.
gundmc 7y ago
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.
- tedunangst 7y ago
  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.
  - tptacek 7y ago
    ... 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.
    - tedunangst 7y ago
      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.
      - moyix 7y ago
        Right, something like this page is better evidence against that narrative: https://bugs.chromium.org/p/project-zero/issues/list?q=Product%3DAndroid&can=1 https://bugs.chromium.org/p/project-zero/issues/list?q=Produ...
      - joshuamorton 7y ago
        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.
      - p1necone 7y ago
        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.
    - deleted 7y ago
      [deleted]
    - 2804t3qwp 7y ago
      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.
      - tptacek 7y ago
        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.
        2804t3qwp 7y ago
        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.
- LMYahooTFY 7y ago
  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.
  - monocasa 7y ago
    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.
  - adrianmonk 7y ago
    > 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
    - panpanna 7y ago
      Please read "the security mindset" by Bruce Schneier: https://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html https://www.schneier.com/blog/archives/2008/03/the_security_...
      - adrianmonk 7y ago
kdbg 7y ago
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-2215-dev-binder-uaf/ https://dayzerosec.com/posts/analyzing-androids-cve-2019-221...
Groxx 7y ago
>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-android-runs-which-linux-kernel https://android.stackexchange.com/questions/51651/which-andr... plus https://developer.android.com/about/dashboards https://developer.android.com/about/dashboards
- bscphil 7y ago
  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.
  - sigmar 7y ago
    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-PPW29.69-26/drivers/android/binder.c 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.git/commit/drivers/android/binder.c?h=linux-4.14.y&id=7a3cee43e935b9d526ad07f20bf005ba7e74d05b https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
    - bscphil 7y ago
      That's good news, thanks.
wyldfire 7y ago
"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 https://en.wikipedia.org/wiki/NSO_Group [2] https://en.wikipedia.org/wiki/Pegasus_(spyware) https://en.wikipedia.org/wiki/Pegasus_(spyware)
- tptacek 7y ago
  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".
  - rafaelm 7y ago
    OK, I'm going to have to ask: who are the largest and most effective?
    - PeterisP 7y ago
      Cellebrite is a popular supplier for mobile forensics, which may require using vulnerabilities are not yet patched, i.e. finding or buying zerodays.
      - lawnchair_larry 7y ago
        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.
        hunter2_ 7y ago
        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.
badrabbit 7y ago
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)
- fulafel 7y ago
  Works well in mobile Firefox for me.
  - badrabbit 7y ago
    My mobile browser is based on firefox and it doesn't for me. Which is my point about UA detection.
markstos 7y ago
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?
- fulafel 7y ago
  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.
- outworlder 7y ago
  > 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 https://github.com/google/syzkaller
  - fulafel 7y ago
    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)
TheCraiggers 7y ago
> 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!
- Jwarder 7y ago
  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-01 https://source.android.com/security/bulletin/pixel/2019-10-0...

139 points by el_duderino 7y ago

> 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.

gundmc 7y ago

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.

tedunangst 7y ago
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.
- tptacek 7y ago
  ... 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.
  - tedunangst 7y ago
    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.
    - moyix 7y ago
      Right, something like this page is better evidence against that narrative: https://bugs.chromium.org/p/project-zero/issues/list?q=Product%3DAndroid&can=1 https://bugs.chromium.org/p/project-zero/issues/list?q=Produ...
    - joshuamorton 7y ago
      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.
    - p1necone 7y ago
      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.
  - deleted 7y ago
    [deleted]
  - 2804t3qwp 7y ago
    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.
    - tptacek 7y ago
      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.
      - 2804t3qwp 7y ago
        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.
LMYahooTFY 7y ago
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.
- monocasa 7y ago
  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.
- adrianmonk 7y ago
  > 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
  - panpanna 7y ago
    Please read "the security mindset" by Bruce Schneier: https://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html https://www.schneier.com/blog/archives/2008/03/the_security_...
    - adrianmonk 7y ago

kdbg 7y ago

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-2215-dev-binder-uaf/ https://dayzerosec.com/posts/analyzing-androids-cve-2019-221...

Groxx 7y ago

>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-android-runs-which-linux-kernel https://android.stackexchange.com/questions/51651/which-andr... plus https://developer.android.com/about/dashboards https://developer.android.com/about/dashboards

bscphil 7y ago
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.
- sigmar 7y ago
  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-PPW29.69-26/drivers/android/binder.c 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.git/commit/drivers/android/binder.c?h=linux-4.14.y&id=7a3cee43e935b9d526ad07f20bf005ba7e74d05b https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
  - bscphil 7y ago
    That's good news, thanks.

wyldfire 7y ago

"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 https://en.wikipedia.org/wiki/NSO_Group [2] https://en.wikipedia.org/wiki/Pegasus_(spyware) https://en.wikipedia.org/wiki/Pegasus_(spyware)

tptacek 7y ago
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".
- rafaelm 7y ago
  OK, I'm going to have to ask: who are the largest and most effective?
  - PeterisP 7y ago
    Cellebrite is a popular supplier for mobile forensics, which may require using vulnerabilities are not yet patched, i.e. finding or buying zerodays.
    - lawnchair_larry 7y ago
      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.
      - hunter2_ 7y ago
        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.

badrabbit 7y ago

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)

fulafel 7y ago
Works well in mobile Firefox for me.
- badrabbit 7y ago
  My mobile browser is based on firefox and it doesn't for me. Which is my point about UA detection.

markstos 7y ago

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?

fulafel 7y ago
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.
outworlder 7y ago
> 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 https://github.com/google/syzkaller
- fulafel 7y ago
  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)

TheCraiggers 7y ago

> 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!

Jwarder 7y ago
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-01 https://source.android.com/security/bulletin/pixel/2019-10-0...