
Exploring Previously Unknown Remote Kernel Bugs Affecting Android Phones - Moral_
https://pleasestopnamingvulnerabilities.com/
======
Ajedi32
> In late 2016 and early 2017 I became burned-out from hunting bugs as it
> became a race between some very talented researchers and I. For example
> Derrek and I spent 2 months auditing and coding up PoCs for some bugs in a
> wifi driver where nearly 95% of our reports were duplicates with the Chinese
> teams. It was becoming hard to compete with teams who do this 40 hours a
> week while I do it as a hobby over coffee on Saturday mornings.

This isn't really the main focus of the article, but I find this really
interesting. There are teams of full-time Chinese researchers looking for and
reporting vulnerabilities in Android? Are they doing this to win the bug
bounties? If so, it sounds like Google's bug bounty program is really paying
off.

~~~
nobodyorother
I hope it's Google's bug bounty program that's paying off.

~~~
Ajedi32
If they were black-hat researchers, they wouldn't have reported the
vulnerabilities to Google, and thus the researcher's reports wouldn't be
considered duplicates.

My guess is they're either working for the bug bounties, or they're employed
by a company that uses Android extensively and wants to make sure its secure.

~~~
ac29
Exploring the acknowledgements [0] shows many of these Chinese researchers are
working for the big internet firms there (Alibaba, Tencent, Baidu), so my
guess is they are more motivated in securing Android for internal use than
collecting bounties (its entirely possible they run their own AOSP-based
Android builds for employee-provided hardware).

Being China, its also possible that the Chinese government indirectly or
directly sponsors this research, since Android is by far the most common
smartphone OS there.

edit: C0RE Team [1], who also has many contributions seems to be an
independent research company, who may be doing it just for the bounties.

[0]
[https://source.android.com/security/overview/acknowledgement...](https://source.android.com/security/overview/acknowledgements)

[1] [http://c0reteam.org/about.html](http://c0reteam.org/about.html)

~~~
wahern
An interesting exercise would be to compile notification dates with code
commit dates, and then compare the average difference (notification date -
commit date) among groups.

If there's a discrepancy, then that's possible evidence one group might be
hoarding bugs, or at least waiting for notification approval from, e.g., a
domestic intelligence agency.

~~~
Cyphase
_cue commit scrubbers_

------
45h34jh53k4j
What is a vuln name, other than a binding of a CVE to a real word to make it
easier to reference or promote.

It draws public attention to an issue better than any CVE-2017-XXXXX would do.

No, keep it up. Dictionary words are far easier to remember than specific
numbers.

~~~
sp332
I think it's better over the long run to keep the CVE as the "canonical" name
and just treat the others like nicknames. Instead we have branding, logos,
domain names etc. Some argue that it's easier to get attention or shame a
vendor by going all-out, but it seems like overkill for a simple mnemonic.

~~~
subway
I think a lot of it is that there are folks who want to contribute to security
awareness, and their skills lie with design/branding rather than with low
level security concepts.

I can't speak for what the value-add is there, but I don't see any harm from
it.

------
bdelay
Well done to the author. I always found working on more obscure systems to be
a lot more entertaining as a hobby and I'd definitely recommend it -- you'll
almost never run into the issue of another researcher coming out with
something first. Most security researchers seem to shy away from embedded VR
due to an unjustified fear of obscure assembly languages and hardware (or
perhaps they just realize there's no money in it...), but isn't nearly as hard
as anyone thinks.

I expect to see drastically more work into IoT devices once tooling and
knowledge sharing gets better. A lot of the articles right now begin and end
with binwalk. Great tool but that's just the start.

The only hard part of embedded work is that it's really, really difficult to
collaborate with anyone as VR is always filled with incredible drama and the
talent pool of individuals willing to work on this (for free) with the
prerequisite knowledge is almost non-existent.

Good luck. And thanks for not coming out with another media campaign first and
interesting research second.

------
simosx
The PLEASESTOPNAMINGVULNERABILITIES vulnerabilities are surely of a different
type than the KRACK attack.

------
dtornabene
fascinating write up. Is it normal for wifi-drivers to have such an enormous
code base? like, nearly 700k loc? And how much of it is generated code? I'd
love any links to stuff on this if anyone has them and time to post, thanks.

~~~
w-ll
Generated code can really build up quick. And that's not taking into account
the transformations from higher level languages down to op codes. I use a lot
of code gen and some projects I manage ~50k loc which can balloon to 10x that.

The exploits i'd bet are still in the human written weird stuff and not
unfolded loops and boring setters/getters.

------
infogulch
Aw I can't take the quiz?

[https://pleasestopnamingvulnerabilities.com/integers.html](https://pleasestopnamingvulnerabilities.com/integers.html)

