To me, the biggest part of this story is:<p>1. Over two years ago, this was apparently detected automatically by the syzkaller kernel fuzzer, and automatically reported on its public mailing list. [1]<p>2. Over a year and a half ago, it was apparently fixed in the upstream kernel. [2]<p>3. It was apparently never merged back to various "stable" kernels, leading to the recent CVE. [3]<p>So you might read that and think "Ok, probably a rare mistake"...<p>...but instead:<p>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.<p>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:<p>slides: <a href="https://linuxplumbersconf.org/event/4/contributions/554/attachments/353/584/Reflections__Kernel_Summit_2019.pdf" rel="nofollow">https://linuxplumbersconf.org/event/4/contributions/554/atta...</a><p>video: <a href="https://youtu.be/a2Nv-KJyqPk?t=5239" rel="nofollow">https://youtu.be/a2Nv-KJyqPk?t=5239</a><p>---<p>[1] <a href="https://twitter.com/dvyukov/status/1180195777680986113" rel="nofollow">https://twitter.com/dvyukov/status/1180195777680986113</a><p>[2] <a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/android/binder.c?h=linux-4.14.y&id=7a3cee43e935b9d526ad07f20bf005ba7e74d05b" rel="nofollow">https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...</a><p>[3] <a href="https://mobile.twitter.com/grsecurity/status/1180059539233804288" rel="nofollow">https://mobile.twitter.com/grsecurity/status/118005953923380...</a>
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?
The bug is scaringly easy to trigger. It just takes four system calls, none of which are niche or take unusual arguments.<p><pre><code> 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);</code></pre>
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.<p>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?
> <i>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.</i><p>> Due to evidence of in the wild exploit, we are now de-restricting this bug 7 days after reporting to Android.<p>Why is this a good idea?
> 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.<p>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.
“It’s advisable that you don’t install apps from non-trustworthy sources, ”<p>Unpopular opinion but this is why I prefer walled garden apple for my family then alternative.
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.
> 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.<p>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...?
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?
> <i>However, if you install an application from an untrusted source, attackers can take advantage of that.</i><p>I'm slightly confused: Do they mean <i>any</i> app or a <i>compromised</i> app?
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.