
Quadrooter: New Vulnerabilities Affecting Over 900M Android Devices [pdf] - ge0rg
https://www.checkpoint.com/downloads/resources/quadRooter-vulnerability-research-report.pdf
======
lvs
The FCC absolutely must clamp down on EOL policies and security updates for
phones. It's a telecom infrastructure issue. Sure it places a burden on
companies like Google and Verizon, but they're the ones who deserve to carry
that burden -- not consumers. The secure lifetime of a device that is hundreds
of dollars should not be only 2-3 years. That leaves a dramatic number of
consumers fully exposed and eliminates the secondary market for used
technology.

Edit: Furthermore, if the companies are going to lock down devices and driver
blobs so nobody else can fix them, all the more reason that the security of
the device is their absolute responsibility.

~~~
ultramancool
Be careful what you wish for, this type of legislation may unintentionally
prevent consumer level device modifications like rooting and custom roms which
allow security researchers the ability to find these issues and basically
restrict this to an NSA level of funding. If I were qualcomm that'd be my
first response in order to minimize effort on my part.

Ideally Google would just produce a version that was more directly update-
able.

~~~
lvs
First, a nitpick that the FCC makes regulation not legislation, and it could
do this under existing authority. Second, I think a fine solution would be to
force open the buildable source including all drivers and firmwares upon EOL.
If top-down security updates will stop, then all components must be open
source at that point.

~~~
mjevans
All information required to build, package, and install; as well as a license
for anyone using or working on affected hardware to the copyright and patents
involved for use with affected devices.

------
gregmac
> The vulnerabilities are found in Qualcomm’s software drivers that come with
> its chipsets. Pre-installed on devices at the point of manufacturing, these
> vulnerable drivers can only be fixed by installing a patch from the
> distributor or carrier. Distributors and carriers can only issue patches
> after receiving fixed driver packs from Qualcomm.

> The research team provided Qualcomm with information about the
> vulnerabilities in April 2016. The team then followed the industry-standard
> disclosure policy (CERT/CC policy) of allowing 90 days for patches to be
> produced before disclosing these vulnerabilities to the public.

> Qualcomm reviewed these vulnerabilities, classified each as high risk, and
> confirmed that it released patches to original equipment manufacturers
> (OEMs).

The complexity of this is really a problem for security updates.

It's bad enough for Android updates: the OEM packages it and adds their stuff,
then the carrier packages it and adds their stuff. A firmware update like this
is yet another layer..

While Checkpoint did the right disclosure thing here, I notice they don't
mention how far down the patches have gotten, or how many users are still
vulnerable today.

~~~
ac29
>I notice they don't mention how far down the patches have gotten, or how many
users are still vulnerable today.

There were a handful of "Critical" Qualcomm specific bugs fixed in the July
[0] and August [1] Android security updates.

I can tell you that my Nexus 5X, which is on the July patch level, is still
vulnerable to 2 of the bugs according the checkpoint security scanner. One is
listed as being fixed in the August update, the other isn't.

[0]
[https://source.android.com/security/bulletin/2016-07-01.html](https://source.android.com/security/bulletin/2016-07-01.html)

[1]
[https://source.android.com/security/bulletin/2016-08-01.html](https://source.android.com/security/bulletin/2016-08-01.html)

~~~
icc97
I'm on a Nexus 5, can I take it there's basically nothing we can do until
Google push out patches.

~~~
kuschku
Correct, because you don’t even have the required data to fix the device, and
instead are fully dependent on someone else.

A someone which has been proved to be unreliable again and again.

~~~
danudey
Better 'a someone' on the Nexus 5 than 'a series of someones' (e.g. Qualcomm,
Google, HTC, and Verizon) on any non-Nexus phone, only some of which have any
vested interest in getting you those updates.

~~~
kuschku
Best to be the owner on your own device.

There’s a reason we modularized drivers on other systems, which allows people
to customize the OS however they want it, because the firmware, drivers, main
OS, UI layer of OS, and applications are all properly seperated.

------
hannob
This is in a certain sense a typical checkpoint finding. It's probably a good
finding and it's good that they point out the problematic andorid ecosystem.
But their announcement is then filled with some nonsense and marketing
bullshit that's more likely to confuse users than help.

In their blog post they say [1]:

* "Use known, trusted Wi-Fi networks or while traveling use only those that you can verify are provided by a trustworthy source." What's that supposed to mean? Is a Wifi trustworthy if it's named Starbucks, because I just bought a coffee there?

* "End users and enterprises should consider using mobile security solutions designed to detect suspicious behavior on a device, including malware that could be obfuscated within installed apps." I call bullshit.

* And then further on [2]: "ZoneAlarm® Mobile Security for Android™ keeps your mobile devices fully protected from malicious apps and Wi-Fi attacks." Oh really? Can they explain how they overcame the theoretical limits (halting problem) that prevent something like this from being possible?

A lot of it reminds me to the Misfortune Cookie vuln a while ago. Also a good
find from Check Point in DSL routers, yet they claimed Zone Alarm can protect
you, which was outright nonsense.

[1]
[http://blog.checkpoint.com/2016/08/07/quadrooter/](http://blog.checkpoint.com/2016/08/07/quadrooter/)

[2] [https://www.checkpoint.com/resources/quadrooter-
vulnerabilit...](https://www.checkpoint.com/resources/quadrooter-
vulnerability-consumer/)

------
profeta
> BlackBerry Priv

YES!

i bought this phone only to "vote with my wallet" that more companies should
make android phones with keyboards. It is pure garbage in any other aspect. It
is the lame phablet size. The keyboard doesn't even have a DOT or COMMA key,
let alone numbers, tab, etc.

The only redeeming features is the OLED screen and keyboard. But then they
made the software for the keyboard pure garbage, and filled the OS with
bloatware.

I've been waiting for root on this phone so i can start to hack away for
months. But blackberry with its cave man corporate mentality, thinks that
giving out root will scare the 5 old men still buying their products. I can't
even buy a developer version like motorola (which have the same mentality)
allowed before.

So, thank you for the sloppy coding, Qualcomm! Thank you for not doing your
homework, Blackberry! and thank you AT&T for holding OS updates until you can
bother to patch your bloatware!

~~~
Karunamon
I have one of these phones, and this was my first thought too. "Woohoo! Root
vulnerability! Now I can run what I want on my own device!"

:(

~~~
mdaniel
As a former Samsung owner, that's actually the same feeling I get every time I
heard of an Android vuln but definitely without the frowny face. I only get
frowny face when the exploits don't work on my specific device. Or, rather,
used to then I noped right out of that situation and got a Nexus device.

In the same way I never intend to get "free phone with contract" ever again, I
hope to never again buy a device that is subject to vendor "enhancements."

------
niftich
Some enterprising lawyer could look for people whose phones or accounts get
hacked as a direct result of manufacturer-provided security patches not
integrated in time by Android core, the device maker, or the carrier.

Then start a class-action lawsuit, with the stated outcome of forcing carriers
to allow, at no cost to all users of no-longer-security-patched phones still
being paid off on their plan, a switch to newer phone that are still being
patched.

While it'd likely result in a settlement, this may be a way to get the ball
rolling, and turning our multi-year outrage into actual (if underwhelming)
results.

------
mvdwoord
"An attacker can exploit these vulnerabilities using a malicious app. These
apps require no special permissions to take advantage of these
vulnerabilities, alleviating any suspicion users may have when installing."

So If I understand correctly, it does require you to side-load an app. Can I
assume Google Play apps are "safe", at least from this type of
vulnerabilities?

~~~
VMG
> Can I assume Google Play apps are "safe", at least from this type of
> vulnerabilities?

Looking at the crap that is on the play store, I wouldn't count on it.

~~~
chickenbane
"crap" aside, users of the Play store (as well as Apple's App Store) are
overwhelmingly safe.

Google now has Android Security Annual reports [0]. From that you can see that
if you only use the Play Store (no sideloading), only 0.15% of devices got a
potentially harmful app.

On top of Play Store's security features, if there were a malicious app that
began causing trouble, Google has other mechanisms to shut down PHAs. As this
vulnerability shows there are issues that are outside AOSP, Android has been
shoring up more defenses in depth.

[0] [https://security.googleblog.com/2016/04/android-
security-201...](https://security.googleblog.com/2016/04/android-
security-2015-annual-report.html)

~~~
benologist
Overwhelmingly safe in the sense that tons of popular apps impede and
undermine your security and privacy, especially easily if you're never getting
updated to Marshmallow.

[https://www.engadget.com/2016/03/19/ftc-issues-warning-to-
ap...](https://www.engadget.com/2016/03/19/ftc-issues-warning-to-apps-
covertly-monitoring-tv-broadcasts/)

------
wepple
interesting that they highlighted how ecosystem fragmentation makes patching
more difficult; they didn't highlight how fragmentation makes exploitation of
their headline-grabbing "900m devices" also very tricky.

This is one of the key reasons the world didn't end when the stagefright
series of bugs was released.

Cool bugs nonetheless..

~~~
thecosas
As a layperson, I read the report that the exploit could apply broadly (since
it's the baseband), but the patches were potentially difficult to roll out
because of the layers of fragmentation in approving and pushing out the
patches to the baseband firmware and the various mechanisms which might or
might not be in pace to do so.

~~~
wepple
They all look like kernel code/driver bugs to me, meaning there will likely be
memory layout and config variations much more significant that you'd see in
baseband code which might be a lot more duplicated across devices.

~~~
thecosas
I think I get it more based on your explanation. Essentially, because the
potential exploits rely on a larger variety of configurations, it's unlikely
that any widespread exploits would take place; the work just wouldn't be worth
it.

More likely that they would focus on the largest subset, hence leading to
security through variety.

------
skykooler
I'm curious as to whether this affects the Jolla as well, as it uses
Qualcomm's chipset and kernel drivers (but not Android)

------
giis
SELinux enabled devices also affected by this?

~~~
Moral_
In N and in some later versions of M SE Linux will stop this.

They are exploiting a series of gpu bugs, and a IPC driver:

[https://android.googlesource.com/kernel/msm.git/+/e8408e6dca...](https://android.googlesource.com/kernel/msm.git/+/e8408e6dca1067f8759a5baeadbc454a8a2293bc)

[https://www.codeaurora.org/invalid-path-check-ashmem-
memory-...](https://www.codeaurora.org/invalid-path-check-ashmem-memory-file-
cve-2016-5340)

[https://www.codeaurora.org/use-after-free-due-race-
condition...](https://www.codeaurora.org/use-after-free-due-race-conditions-
kgsl-module-cve-2016-2504-cve-2016-2503)

[https://www.codeaurora.org/projects/security-
advisories/linu...](https://www.codeaurora.org/projects/security-
advisories/linux-ipc-router-binding-any-port-control-port-cve-2016-2059)

Which is now blocked by SELinux. The android security team has started killing
off IOCTL calls which aren't necessary for normal apps. They are also nuking
access to weird socket types. Including some Wifi related socket closures,
which nukes a huge attack surface on the wlan side of things:

[http://kernsec.org/files/lss2015/vanderstoep.pdf](http://kernsec.org/files/lss2015/vanderstoep.pdf)

[https://security.googleblog.com/2016/07/protecting-
android-w...](https://security.googleblog.com/2016/07/protecting-android-with-
more-linux.html)

~~~
giis
thanks for the details & links. Good to know some version of SELinux prevents
this.

------
arca_vorago
All I ever wanted was pure linux on a phone, so I could do what I wanted to
with it, including securing it. Instead what we got was a half open half
proprietary peice of crap that even google bent over backwards to let the
carriers fuck up with their custom ROMs on top of stock droid.

What we need is an open source phone, metal to screen, so to speak. Oh wait,
the cell radio firmwares are all proprietary too?

I blame carriers and their bullshit first, google for not allowing more
granular ACL's natively, and consumers for accepting android because they were
so ready for anything different.

~~~
arvinsim
> and consumers for accepting android because they were so ready for anything
> different.

What would be the alternative for those who can't afford premium phones?

~~~
pjmlp
For a while it was Symbian, Maemo and WP but thanks to how Nokia and Microsoft
managed it , those options are now gone.

------
tdkl
So I can now finally root my unlockable device ? Cool !

------
wyldfire
I wonder if most apps have a reason to use the ioctl syscall normally. I think
termios uses ioctl(), but what else? Do apps even need terminal control? Seems
like ioctl() could be blacklisted with seccomp. Or maybe whitelist the
permitted nodes with seccomp.

------
Miner49er
Would rooting your phone, and then using an app like SuperSU protect you from
this? When a malicious app attempted to get root, would it be able to bypass
SuperSU or would the user have to give it permission though SuperSU?

~~~
ultramancool
SuperSU is simply a tool which allows apps to gain root access with user
permission via an API.

Apps that use exploits like this can still gain root with no need for user
permission. However, exploits like this can also be used for users to root
their phone and install SuperSU or similar, allowing them to take advantage of
the root-only apps on phones with locked down bootloaders and similar issues.
This may also allow patching of devices which don't get official updates in
similar fashion to "fixer" worms.

------
qwertyuiop924
Can you root your phone using the exoloit yet?

It's only a matter of time.

------
milankragujevic
This is just getting worse and worse. I'm not going to bash Android
specifically, because iOS does get some exploits, but seriously we need to
have a more locked down system that allows the user to only install the apps
that are downloaded from a app store, that runs the apps in a container and
doesn't allow special access to forbidden parts of the system. Of course if
the user doesn't like it and wants freedom to use any apps, as well to be open
to security risks that come with it, they MUST be allowed to do that, but
don't make that the default option on billions of devices...

~~~
0x6c6f6c
> only install the apps that are donwloaded from a app store

That's how it is by default. You have to enable the ability to install third-
party applications

~~~
milankragujevic
Yet Google's track record of spam and malware in the Play store is horrific.
They obviously care more about quantity of apps rather than quality, and
therefor don't do something like Apple with a manual review process.

Though apps should still be run in a sandbox...

~~~
lorenzhs
Google's automatic scanning is actually quite good. Most malware comes from
random apk downloads and third-party app stores (often piracy-related). This
has been pointed out many times throughout this thread (with links to back it
up).

------
Oletros
If a device has Marshmallow it can't write the system partition, isn't?

It can't be rooted because it will be detected at boot

~~~
honkhonkpants
You mean it can't have a persistent rootkit installed. That is not the same
thing.

------
drdaeman
From the PDF it seems that this only applies to kernels that have a few
Qualcomm patches applied.

~~~
wmf
So only 65% of Android phones (100% on Verizon/Sprint?).

~~~
drdaeman
No idea about the exact percentages, but no doubt it's a large fraction of
phones. I'm not debating it's insignificant or something - sure, it's giant.

Just thought that pointing out it's Qualcomm-specific issue should make other
chipset phone users feel somewhat at ease. (I have an Intel SoC-based one and
got nervous upon seeing the title.)

------
icc97
Seems like a pretty good reason to switch to a nightly cyanogenmod build

~~~
mdaniel
Perhaps I'm not following your intention, but for those with bootloader-locked
devices, if we could have gotten enough control over our devices then we would
have already jumped off of the antiquated builds. So it's a terrible catch-22:
those with super old bootloader-locked devices are actually the _most_
vulnerable to a whole host of these style attacks, but are the _least_ able to
do anything to the hardware that we paid good money to buy.

Also, while this may just be my experience with cyanogenmod and the devices
that I _have_ managed to root, one can often end up not having access to the
necessary blobs to make the phone run as well as it did under the bloated rom.
That actually is very similar to Linux and the Win-modems and a ton of Win-
printers that followed: sure, you can run a FLOSS setup, you'll just need to
be very, very choosy about the hardware that goes into it.

