Live data from Hacker News

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

thenextweb.com

151–160 of 236 posts

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

#151
post #150

Earlier quoted context omitted.

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.

>If I were an average consumer If you were, you would behave like one, i.e. not care that much (if at all) about security. What you are saying is "I do care about my device being secure".

Yes, I suppose that's true. I should have worded it differently.

Perhaps, the average person would be more upset/notice if they were negatively impacted as the result of a security issue, than if some feature, e.g. real time audio were missing, which I'm sure no one would even notice.

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

#152
post #89

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?

So far this further supports the argument that they are special casing and going into a lot more detail when it comes to non Android or Chrome bugs. Will there be a large analysis how frequently this was exploited and so forth? How about a public Google blog post around this?

Oh, surprise Google fan boys/employees downvoting a critical post about the company without leaving a comment. How typical. This is getting boring on HN.

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

#153
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…

It’s “telling” of what exactly?

Linux distributions make up the majority of public web and database servers and approximately none of the real-time audio players, is that not a “particular reason” to prioritise security over real-time audio?

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

#154

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?

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…

>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.

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

#155

Earlier quoted context omitted.

It's not a "Chromium" bug, it's project-zero bug [1]. https://bugs.chromium.org/ is just a bug tracker site to host batch of projects by Google. While most of them are related to Chromium, there are also things like project-zero. [1] https://bugs.chromium.org/p/project-zero/issues/detail?id=19...

So where was the Project Zero blog post on the matter? Because if this wasn't announced on their blog I'm going to have to say that this particular case would not be an apples to apples comparison. Here was the Project Zero blog post on Apple's exploit, for comparison. https://googleprojectzero.blogspot.com/2019/08/a-very-deep-d...

Note that that blog post was published in August 2019, while the vulnerabilities mentioned in the blog post were reported in a wide range of dates from October 2017[1] to December 2018[2] (that's the latest one I found in a quick skim, maybe there are later ones). This Android vulnerability was reported September 2019[3], so it may take 8-22 months before the blog post comes out. The reporter does intend to post a blog post about it[3].

[1] https://bugs.chromium.org/p/project-zero/issues/detail?id=14...

[2] https://bugs.chromium.org/p/project-zero/issues/detail?id=17...

[3] https://bugs.chromium.org/p/project-zero/issues/detail?id=19...

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

#156

Earlier quoted context omitted.

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…

>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.

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.

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

#157
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.

“Many” users?

Yes, nearly all of /r/jailbreak is running iOS 12.x or lower. Specifically, practically no one there has updated to 12.4.1, which fixes Pwn20wnd's exploit.

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

#158
post #136

Earlier quoted context omitted.

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…

It’s “telling” of what exactly? Linux distributions make up the majority of public web and database servers and approximately none of the real-time audio players, is that not a “particular reason” to prioritise security over real-time audio?

I'm not saying that Linux should neglect security, but there is no reason for it to be above anything else. People who care about security can look at systems that are more focused, like OpenBSD.

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

#159
post #71
post #34

Earlier quoted context omitted.

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.

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?

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...

[2] https://www.cvedetails.com/product/15031/Google-Chrome.html?...

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

#160
post #94

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…

Could this be an issue of not appropriately identifying the impact of the bug? If it was reported by an automated tool and easy to fix perhaps the developer failed to fully investigate the problem, failing to realize it is a critical vulnerability and have the fix back ported.

KASAN identified it as a use after free bug. That makes it very plausibly a security vuln. What more do you want to automate?

The problem is there are so many of those.

Post reply on HN