Live data from Hacker News

Google, Xiaomi, and Huawei affected by zero-day flaw that unlocks root access

thenextweb.com

131–140 of 236 posts

Re: Google, Xiaomi, and Huawei affected by zero-day flaw that unlocks root access

#131
post #83

Earlier quoted context omitted.

The actual bug talks about "untrusted app code execution". As in, code in any app, regardless of where it was installed from. So you're relying on review by the walled garden as protection. And of course, "untrusted sources" is not the same as "all side-loading". I use sources to sideload from that I trust more than the average app developer.

Would you have trusted Epic? https://www.pcmag.com/news/363357/google-irks-epic-games-by-...

Good question, not sure. Haven't actually needed an install channel that wasn't through F-Droid (since it supports custom repositories), and would generally be wary of new ones.

Re: Google, Xiaomi, and Huawei affected by zero-day flaw that unlocks root access

#132
post #123

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);

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.

Re: Google, Xiaomi, and Huawei affected by zero-day flaw that unlocks root access

#133
post #111

this is a feature and not a bug

Do you have a source for that?

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.

Re: Google, Xiaomi, and Huawei affected by zero-day flaw that unlocks root access

#134

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

In Android land you can buy a phone where the bootloader can be unlocked and directly flash a pre-rooted ROM rather than relying on people exploiting security vulnerabilities like this.

From my experience, this is not necessarily true, even when a phone is advertised as unlockable. I know that Huawei phones, for instance, had two different unlock modes. One called USER Lock, and the other FB Lock. The unlock codes given to users only applied to USER Lock, which means only some partitions could be modified (e.g. recovery could be modified, but fastboot was restricted). I'm not sure whether or not other brands have similar "protections" or not, but I wouldn't be surprised it this was the case due to DRM.

Re: Google, Xiaomi, and Huawei affected by zero-day flaw that unlocks root access

#135
post #108

Earlier quoted context omitted.

And goto being used for error handling is pretty stock standard across most C codebases I’ve worked on or seen over the years, so I’m not sure what the particular gripe is there

Since when is "we do it all the time" the same as "it's a good thing"?

Properly used goto is essentially an inline exception handler. That is a good thing to eliminate repetitive fault checks and fragile cleanup code.

Re: Google, Xiaomi, and Huawei affected by zero-day flaw that unlocks root access

#136
post #102

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, p…

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 an…

If you submitted a huge patch to Linux that would really improve support for real-time audio, but break many other things like IO throughput, etc. but your argument for accepting it anyway was "yes, but it's for real-time audio support, so it's really important and more important than what everyone else is working on", you'd be laughed out of the mailing list.

The fact you use the word "prioritize security" is indeed telling. Security is just one aspect of a system. There is no particular reason for Linux to prioritize it above everything else, no matter what twitter infosec drama queens believe.

Obviously the fact that infosec people are quite often insufferable does not help their case.

Re: Google, Xiaomi, and Huawei affected by zero-day flaw that unlocks root access

#137
post #120

Earlier quoted context omitted.

GRSec is the primary reason the Android devices from BlackBerry have never, to my knowledge, been rooted (despite their many flaws). It's crazy that it's not more accepted.

I personally wouldn't trust a company that openly bragged it built a system to provide local police and Intel agencies with real time access to Blackberry messaging flowing across an entire city in 2010 for G20. In addition to sharing their "master" encryption key for a number of years: https://www.theverge.com/2016/4/14/11434926/blackberry-encry... Also AFAIK Blackberry only provided a hardened kernel with a single…

The new Android devices also have hardened kernels but it doesn't really matter phones are insecure as fuck in other ways.

Re: Google, Xiaomi, and Huawei affected by zero-day flaw that unlocks root access

#138
post #51

Earlier quoted context omitted.

Nobody would willingly run outdated, vulnerable software if there was an easy, direct, and supported way to root your phone. Sell phones locked for security or whatever, I couldn't care less, but give people the option to root when they want. So many iPhone users knowingly refuse to upgrade to newer versions of the operating system just so they can keep their jailbreak.

> Nobody would willingly run outdated, vulnerable software if there was an easy, direct, and supported way to root your phone. People do that all the time with desktop computers.

Yeah but at least there's a way to upgrade desktop computers, phones just aren't.

Re: Google, Xiaomi, and Huawei affected by zero-day flaw that unlocks root access

#139
post #37

Earlier quoted context omitted.

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.

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

And it throws all that security model out of the window by having the manufacturer do whatever they want and lacking upgrades. How long is it going to take for this update to propagate? I'm betting on at least 4 months for my phone.

Re: Google, Xiaomi, and Huawei affected by zero-day flaw that unlocks root access

#140
post #136
post #102

Earlier quoted context omitted.

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 an…

If you submitted a huge patch to Linux that would really improve support for real-time audio, but break many other things like IO throughput, etc. but your argument for accepting it anyway was "yes, but it's for real-time audio support, so it's really important and more important than what everyone else is working on", you'd be laughed out of the mailing list. The fact you use the word "prioritize security" is indeed…

When you're developing such a crucial part of an operating system, wouldn't you want to put security pretty high at the top of the priorities list?

If I were an average consumer, I would care much more about my device being secure, than having real time audio.

Post reply on HN