
Google, Xiaomi, and Huawei affected by zero-day flaw that unlocks root access - lp001
https://thenextweb.com/security/2019/10/04/google-xiaomi-and-huawei-devices-affected-by-zero-day-flaw-that-unlocks-root-access/
======
typical182
To me, the biggest part of this story is:

1\. Over two years ago, this was apparently detected automatically by the
syzkaller kernel fuzzer, and automatically reported on its public mailing
list. [1]

2\. Over a year and a half ago, it was apparently fixed in the upstream
kernel. [2]

3\. It was apparently never merged back to various "stable" kernels, leading
to the recent CVE. [3]

So you might read that and think "Ok, probably a rare mistake"...

...but instead:

4\. This is apparently a _super_ common sequence of events, with kernel
vulnerabilities getting lost in the shuffle, or otherwise not backported to
"stable" kernels for a variety of reasons like the patch no cleanly longer
applies.

Dmitry Vyukov (original author of syzkaller fuzzer that found this 2 years
ago) gave a very interesting talk on how frequently this happens a couple
weeks ago at the Linux Maintainer's Summit, along with some discussion of how
to change kernel dev processes to try to dramatically improve things:

slides:
[https://linuxplumbersconf.org/event/4/contributions/554/atta...](https://linuxplumbersconf.org/event/4/contributions/554/attachments/353/584/Reflections__Kernel_Summit_2019.pdf)

video: [https://youtu.be/a2Nv-KJyqPk?t=5239](https://youtu.be/a2Nv-
KJyqPk?t=5239)

\---

[1]
[https://twitter.com/dvyukov/status/1180195777680986113](https://twitter.com/dvyukov/status/1180195777680986113)

[2]
[https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/android/binder.c?h=linux-4.14.y&id=7a3cee43e935b9d526ad07f20bf005ba7e74d05b)

[3]
[https://mobile.twitter.com/grsecurity/status/118005953923380...](https://mobile.twitter.com/grsecurity/status/1180059539233804288)

~~~
dmix
The failures of the Linux core team to properly prioritize security is quite
well known. A lot of people have poked the bear by trying to bring this up,
also with specific real examples, and got a tongue lashing from the team and
moved on to other things.

I'm amazed the GRSecurity people have managed to do it for so long. Even if
merging their stuff mainline legitimately wasn't practical, I've seen plenty
of snark and dismissiveness from the Linux team towards them and others. And
GRSEC does actively bring in CVEs into their kernel patches all the time and
get paid via sponsors to do so.

I'm sure going through old CVEs is a great way to find "zero days" and/or
relapses after old patches. Or even just following the work GRSec does there's
probably plenty of stuff for a highly motivated company like NSO to exploit.

~~~
dexen
_> The failures of the Linux core team to properly prioritize security_

Why even post this, when it has nothing to do the with the case GP & OP
described? It's misleading at best.

The failure here is in the way Google has set its Android development process.
They keep a separate "stable" kernel, and manually select certain patches to
backport to. In process they skip all kinds of patches - performance,
features, and yes, security ones. Given that only selected patches are
backported, the process is best described as _insecure by default_. It was
Google's decision to favor stable API over security here.

This is compounded by the fact other Android phone vendors are pretty slow at
releasing OS upgrade - and tend to stop releasing them altogether shortly
after the phone's no longer manufactured.

The mainline kernel, as released by the _Linux core team_ is up to date with
security. Hold to account people that decided to skip patches as a matter of
course, resulting in the _insecure by default_ process.

~~~
typical182
> _The mainline kernel, as released by the Linux core team is up to date with
> security. Hold to account people that decided to skip patches as a matter of
> course_

To me, the particulars of this exact case are not as interesting as the fact
that the entire Linux patching and backporting of security issues seems _very_
fragile, with things frequently getting "lost" for mundane reasons, and a key
part of the "why" it is so fragile is due to many of the core Linux
development processes.

This particular CVE is apparently one small example that happened to catch
some headlines out of _thousands_ of similar problems.

That talk linked above by Dmitry Vyukov is worthwhile for getting a sense of
the magnitude of the problem.

------
arusahni
After the recent disclosures about Apple vulnerabilities, I've seen a lot of
(unwarranted, in my opinion) criticism from HN of Project Zero, specifically
the accusation of non-Google bias. For those who hold this position, does this
affect your stance?

~~~
endorphone
Their release pattern with the Apple fault could effectively be called a PR
campaign, including a lot of editorial narrative about bad software
development processes, etc.

This one gets a bug tracker entry.

When Project Zero posts a lengthy analysis with lots of scurious claims about
the victims of the exploit, the window of exploitation, and narrative about
the poor development practices that led to it, then call it even.

If it follows the traditional pattern, they'll write a post blaming some
external party. No, seriously, when people point out all of the "Android"
faults they've found invariably it is some variation of "but it isn't really
Google's fault....".

Project Zero is brilliant, full of brilliant people, and is a remarkable
effort, but when your paycheque is signed off by someone, it is human nature
that you're really going to pussyfoot with them.

~~~
Thorrez
>This one gets a bug tracker entry.

For now. A comment from the reporter on the bug tracker entry:

>A more detailed explanation of this bug and the methodology to identify it
will be written up in a forthcoming blog post when I find the time.

~~~
oefrha
The iOS “deep dive” was a timed media push of a months-old problem right
before a major Android release. They didn’t even try to obfuscate the timing
or narrative. Blog post or not it’s pretty hard to top that.

~~~
panpanna
You are paranoid.

Apple has started multiple keynotes by talking about Android security issues.
Pointing fingers and ridiculing Google, Samsung and others.

Then a few weeks later, a Google keynote would demo something on an iPad and
praise its beautiful hi-def screen.

I have _never_ heard Google officially talk crap about Apple.

~~~
jsjohnst
> Apple has started multiple keynotes by talking about Android security
> issues.

Historically, they didn’t directly identify other vendors, but strongly
implied it so it was obvious to most without directly saying names. This has
changed a bit recently and I feel isn’t a good thing.

> I have _never_ heard Google officially talk crap about Apple.

No offense, but then you aren’t paying attention. There are examples given
directly in this thread already.

------
kccqzy
The bug is scaringly easy to trigger. It just takes four system calls, none of
which are niche or take unusual arguments.

    
    
        int fd, epfd;
        struct epoll_event event = { .events = EPOLLIN };
    
        fd = open("/dev/binder0", O_RDONLY);
        epfd = epoll_create(1000);
        epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event);
        ioctl(fd, BINDER_THREAD_EXIT, NULL);

~~~
catern
It's interesting that even such basic usage of binder is buggy. It's long been
known that binder is horrible code, but I didn't know it was quite this bad.

It's unfortunate that Google chose to use a custom IPC system, binder, for
Android, instead of changing Android's design to better fit Linux. If binder
was in use outside Android, I expect this bug would have been caught long ago
and certainly would have been backported to stable.

~~~
blub
Judging by how much Binder's "elegant design" of BeOS pedigree was praised, I
was expecting it to be quite good.

I just had a look at binder.c and the ref counting and locking in general
looks like a nightmare to maintain. This reminds me of how much I hate
resource management in C.

~~~
jumpingmice
Most of the BeOS was written in C++. Nobody at Be would have tolerated the
code quality you find in Linux binder.

------
userbinator
This is another great chance to root your phone and take complete control of
what you should rightly own.

~~~
notmokjklhr
And your chance to share this complete control with every installed app.
Phones should be like desktop computers. You install an app, you give it
access to everything your account can touch on the computer.

~~~
zelly
Android has one of the best security models and sandboxing for apps. It's
based around SELinux.

~~~
zzzcpan
> Android has one of the best security models and sandboxing for apps. It's
> based around SELinux.

You mean a security model that misses the fact that the kernel cannot be
updated and relies on a "sanboxing" solution that doesn't bother limiting
kernel attack surface. No, I don't think they even had a security model in
mind, a threat model or anything beyond random ad hoc ideas. And if they did
some thinking, they would not have chosen SELinux either, as it's not a decent
solution to anything, it's more like a solution to "we must to do something,
this is something, we must do this".

~~~
ebiggers
SELinux actually does significantly reduce the kernel attack surface on
Android, and it has made a lot of kernel vulnerabilites unexploitable on
Android. This particular bug was simply one in the remaining attack surface.

------
bloudermilk
The macro-level progression of digital security really worries me. Each day
the attack surface grows, the number of bad actors grows, the number of
internet-connected individuals grows, and the quantity and sensitivity of data
per-capita grows.

Is there a well-researched theory that considers a "breaking point" in this
pattern? Where we either a) accept that all data is at risk of being exposed
or b) develop fundamental security patterns to privatize our data or c)
something else?

------
mehrdadn
> _The researchers speculate the bug is being used by NSO, an Isreal-based
> group known to sell tools to authorities to exploit iOS and Android._

> Due to evidence of in the wild exploit, we are now de-restricting this bug 7
> days after reporting to Android.

Why is this a good idea?

~~~
beojan
Well, Google are themselves the vendor here. Also seems it's fixed and this
might encourage manufacturers to push out an update.

~~~
xvector
I feel like this goes against responsible disclosure. Google should give the
manufacturers a month to push updates themselves, just like Google would
expect a month to fix an issue someone reported to them.

~~~
jdm2212
It's being actively exploited, which changes the calculus.

~~~
mehrdadn
"Actively exploited" by... law enforcement? Do all consumers _really_ need to
freak out about this the same way they would if hackers had access? Doesn't
_that_ detail change the calculus here?

~~~
infinityplus1
Not all law enforcements are working for the good of their people, probably.

~~~
mehrdadn
That still doesn't counter my point.

------
ec109685
> It’s advisable that you don’t install apps from non-trustworthy sources, and
> use an alternate browser such as Firefox or Brave till the issue is fixed.
> We’ll keep you posted on any updates issued by phone makers.

The recommendation that other browsers are inherently protected doesn’t make
sense. Any app with an rce bug could be a vehicle to exploit this Android bug.

------
cryptozeus
“It’s advisable that you don’t install apps from non-trustworthy sources, ”

Unpopular opinion but this is why I prefer walled garden apple for my family
then alternative.

~~~
StavrosK
I don't understand people who want to remove choice. Don't want the ability to
install apps from untrustworthy sources? Don't enable the option that gives
you that ability.

~~~
dodobirdlord
The position is self-defeating. How can you hold it and at the same time
advocate against their choice to use a system that doesn't have the ability to
install apps from untrustworthy sources? The availability of such systems is
obviously an increase in available choice, not a decrease.

~~~
AnthonyMouse
> How can you hold it and at the same time advocate against their choice to
> use a system that doesn't have the ability to install apps from
> untrustworthy sources? The availability of such systems is obviously an
> increase in available choice, not a decrease.

Saying "doesn't have the ability to install apps from other sources" is the
same as saying "doesn't give you the choice to install apps from other
sources" \-- it's removing a choice.

If you don't want to install apps that aren't approved by Apple then... don't.
You could choose not to even if your ability to choose was not restricted.

~~~
dodobirdlord
I'm sorry, but you have completely missed the point. I generally try not to
respond in ways that can be construed as rude, but there was only one point,
it was core to my comment, and your comment indicates that you did not
understand it.

> You could choose not to even if your ability to choose was not restricted.

Choosing not to install apps that aren't approved by Apple is not the same
thing as choosing to use a device where apps that are not approved by Apple
cannot be installed. That is the entire point.

How can someone (perhaps yourself?) be in favor of expanding choice and also
opposed to to the existence of this choice?

~~~
AnthonyMouse
> How can someone (perhaps yourself?) be in favor of expanding choice and also
> opposed to to the existence of this choice?

The issue isn't that an iPhone on which you can't install apps not approved by
Apple exists, it's that an iPhone (i.e. Apple hardware running iOS) on which
you can install apps not approved by Apple doesn't exist, so that choice is
missing from the market. In order for it to be a _choice_ it is necessary for
both alternatives to be available.

~~~
dodobirdlord
> In order for it to be a choice it is necessary for both alternatives to be
> available.

Fair, and ideally both options would exist. But an Android phone is a close
approximation of an unlocked iPhone, while there is no other close
approximation of a locked iPhone. Pushing the security stance of iPhone to
align more closely with Android is a homogenization of the landscape and a
reduction in the diversity of options.

------
z3t4
Mobile phones, especially Android ones are very vulnerable as they rarely get
updates, or if they get updates at all. And these devices are used for second
factor security. And sometimes they are the only thing needed to get access to
your entire life.

------
delibes
> However, if you install an application from an untrusted source, attackers
> can take advantage of that. Attackers can also take advantage of the bug if
> they pair it with vulnerabilities in the Chrome browser to render content.

So, you have to sideload an app or from some other source. Is it unreasonable
to say don't do that? How common is it anyway? I work with IT folks and only a
few ever seem to load outside the Play store. Perhaps in other parts of the
world it's more common...?

~~~
mehrdadn
There are lots of sites out there that host APKs of apps (older versions,
etc.)... I'd wager they have more than a few users.

~~~
klingonopera
...there need to be more developers like these!

I'm not sure, but aren't Play Store submittals APKs anyways? Is additionally
self-hosting them that much more complicated?

I've heard that developers often go Play Store exclusive, for fear that Google
might block them. Is that true?

------
app4soft
AWESOME!

Please, give me instruction to root my _Xiaomi Ido_ until they fixed it!
(updates on my phone disabled for a while)

------
arpa
I see that samsung s series is also affected. The thing about the samsung
phones is that you can root them, but that basically breaks the KNOX (secure
folder) functionality forever (efuse AFAIR). Couldn't this exploit be used to
root the phones while preserving knox by not tripping the efuse?

------
jdc
Proof on concept: [https://bugs.chromium.org/p/project-
zero/issues/detail?id=19...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=1942#c7)

------
klingonopera
> _However, if you install an application from an untrusted source, attackers
> can take advantage of that._

I'm slightly confused: Do they mean _any_ app or a _compromised_ app?

~~~
sp332
A compromised app. The vulnerability requires local code execution, so either
an app you install and run, or a malicious webpage that somehow breaks out of
the browser sandbox, or... loading a specially constructed video file in a
vulnerable version of VLC, or something. Basically you need to combine this
with some other vulnerability _or_ convince the user to just straight up run
the code.

~~~
tmd83
What wasn't clear was that is there a known browser sandboxing vulnerability
at this point that can be used to get root or the idea is that if someone has
one they could use this one to get root. Can I use Chrome in my Android phone
now or cannot?

~~~
Thorrez
Generally to exploit an OS from within Chrome you need 2 vulnerabilities: (1)
to break out from javascript into machine code execution within the sandbox,
(2) to break out of the sandbox into the general OS (and maybe (3) to then get
root on the OS).

From my reading of this comment[1], it sounds like this vulnerability is such
that if an attacker has vulnerability (1), this vulnerability can be used as
vulnerability (2) and (3). It sounds like NSO group either had or has a
separate vulnerability (1), possibly something from [2].

[1] [https://bugs.chromium.org/p/project-
zero/issues/detail?id=19...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=1942#c7)

[2] [https://www.cvedetails.com/product/15031/Google-
Chrome.html?...](https://www.cvedetails.com/product/15031/Google-
Chrome.html?vendor_id=1224)

------
asdfasgasdgasdg
People, many on this very site, often erroneously claim that P0 does not
disclose vulnerabilities in Google's own products. Or they claim that Google
gets favorable treatment, like the disclosure only of less severe bugs, or
longer disclosure deadlines. Here is a countervailing datapoint.

------
walrus01
Oppo A3, but not OnePlus 7 pro?

------
KibbutzDalia
This is why we need the kernel to be re-written in Rust ASAP -- to make these
flaws a thing of the past.

~~~
techntoke
Too much effort for something that is only theoretical. Better to start new
and see how it goes.

------
OrgNet
this is a feature and not a bug

~~~
2OEH8eoCRo0
Do you have a source for that?

~~~
OrgNet
the source is me, and the reason why I said that is because they usually block
you from being root on your own devices... sometime, bugs like these are the
only way to really own your device.

