Live data from Hacker News

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

thenextweb.com

221–230 of 236 posts

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

#222

Earlier quoted context omitted.

The position is self-defeating. How can you hold it and at the same time advocate against their choice to use a system that doesn't have the ability to install apps from untrustworthy sources? The availability of such systems is obviously an increase in available choice, not a decrease.

> How can you hold it and at the same time advocate against their choice to use a system that doesn't have the ability to install apps from untrustworthy sources? The availability of such systems is obviously an increase in available choice, not a decrease. Saying "doesn't have the ability to install apps from other sources" is the same as saying "doesn't give you the choice to install apps from other sources" -- it'…

I'm sorry, but you have completely missed the point. I generally try not to respond in ways that can be construed as rude, but there was only one point, it was core to my comment, and your comment indicates that you did not understand it.

> You could choose not to even if your ability to choose was not restricted.

Choosing not to install apps that aren't approved by Apple is not the same thing as choosing to use a device where apps that are not approved by Apple cannot be installed. That is the entire point.

How can someone (perhaps yourself?) be in favor of expanding choice and also opposed to to the existence of this choice?

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

#223
post #146

Earlier quoted context omitted.

I want to buy into a platform that is controlled tightly by a single entity that I trust to deliver a good user experience reliably; in this case, that's Apple. I consider the tight control a feature and I'm glad this philosophy of computing is available in the marketplace. I think people underestimate this view.

I don't think it's an underestimated view, it's quite common. I just don't think it would be compromised very much if there was an optional escape hatch. Buying a hypothetical Apple device and never flicking on the sideloading switch would still give you that. Whereas the person who generally prefers the security engineering, design choices and/or integration of iOS but wants some exceptions is now told "If you care…

> Buying a hypothetical Apple device and never flicking on the sideloading switch would still give you that.

Until someone (my abusive spouse? someone with a narrowly scoped zero-day and physical access to my phone?) abuses the existence of this functionality in ways that compromise my security.

> Whereas the person who generally prefers the security engineering, design choices and/or integration of iOS but wants some exceptions is now told "If you care about this so much, you can go over to Android.".

I agree with you here. It would be great if Apple offered two classes of iPhone, one where such a switch was present and one where unsigned code was prevented from executing by hardware.

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

#224

Earlier quoted context omitted.

The position is self-defeating. How can you hold it and at the same time advocate against their choice to use a system that doesn't have the ability to install apps from untrustworthy sources? The availability of such systems is obviously an increase in available choice, not a decrease.

Unless I'm misunderstanding your point, haven't you just rephrased Karl Popper's "paradox of tolerance?" Advocating freedom to create walled gardens in mainstream computing is what's self-defeating.

I disagree. The existence of a walled garden to opt into is a meaningful choice. As long as other choices exist, the existence of a walled garden limits nobodies choice. Based on some other comments in the thread I'll add that it would be even better from a choice perspective if Apple offered two configurations of iPhone, one where sideloading was available via a software toggle and one with hardware that cannot run unsigned code. Ultimately though, an approximation of this choice is available by substituting some Android device for the first option.

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

#225

Earlier quoted context omitted.

There isn't a way to do that on Android either. You have to use the confused deputy to install the app.

The installer as designed was able to download code and execute it - so there was obviously a way to do it on Android.

> The installer as designed was able to download code and execute it

No, it was able to download code and ask a Samsung app store system app to install it. This doesn't work on non-Samsung Android devices, and the exact same confused deputy problem can exist on iOS.

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

#226

Earlier quoted context omitted.

> they didn’t directly identify other vendors Who cares when they do this https://essentialapple.com/in-the-news/wwdc-2014-tim-cook-te... > examples given directly in this thread Just because someone feels this way it does not make it true. I bet apples own security team are 100% thankful for someone uncovering this.

> I bet apples own security team are 100% thankful for someone uncovering this. That’s not my point at all with my original reply. I know first hand that some Apple security members are thankful for the work of ProjectZero. But that isn’t the point I was making or you made previously, Google “not saying anything bad about Apple” is patently false.

What Google did is industry standard, they do it to their own products all the time:

https://en.m.wikipedia.org/wiki/Full_disclosure_%28computer_...

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

#227
post #86
post #37

Earlier quoted context omitted.

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

> Android has one of the best security models and sandboxing for apps. It's based around SELinux. You mean a security model that misses the fact that the kernel cannot be updated and relies on a "sanboxing" solution that doesn't bother limiting kernel attack surface. No, I don't think they even had a security model in mind, a threat model or anything beyond random ad hoc ideas. And if they did some thinking, they wou…

Despite the fragmentation and lack of updates provided by most OEMs, Android's architecture from security point of view is safer than any other Linux based platform, with exception of ChromeOS.

Managed languages userspace, drivers implemented in Java or C++ in their own process with IPC to the kernel (since project Treble), whitelist of allowed native calls beyond the rather thin set of native libraries, to touch IO beyond own APK install dir or TCP/IP, native code needs to go through managed layer, several security critical processes are deployed in production with FORTIFY and sanitizers turned on.

ChromeOS turns the notch even higher by running Crostini on its own Rust implemented hypervisor and Go written userspace syscalls wrapper (gVisor).

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

#228
post #5
post #3

Earlier quoted context omitted.

Well, Google are themselves the vendor here. Also seems it's fixed and this might encourage manufacturers to push out an update.

I feel like this goes against responsible disclosure. Google should give the manufacturers a month to push updates themselves, just like Google would expect a month to fix an issue someone reported to them.

The manufacturers don't need to fix anything though, they just need to push out the update. The entity that needs to fix (and has fixed) the bug is Google itself.

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

#229

Earlier quoted context omitted.

You’re wrong that no one should ever use goto. Goto is a perfectly fine control flow operator IF AND WHEN you use it in a highly structured, well-understood way. This is how systems programming is done. A “goto cleanup” section at the end of a function is the best way to do exit-on-error in C, hands down. I hate that people keep peddling this nonsense because they wrote a little C and read a headline about “goto cons…

Goto is only de rigueur in terrible languages that are unable to release function-local resources automatically. It is an intentional choice by kernel authors to ignore all progress in our field after 1988 and insist on writing everything in C. It’s not the goto statements that are the problem, rather it is the culture that necessitates them.

Do you realize how big the kernel source is? No one wants to rewrite it to C++. Also C++ compiles slower and can be more difficult to read, depending on code style and features used. C++ is also far more fragile regarding compiler compatibility and sometimes spits rather confusing error descriptions.

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

#230

Earlier quoted context omitted.

goto for error handling is not just "freeform anything goes goto". It's a very specific idiom, being an "error" label and a bunch of "if (resource) free(resource)" statements at the end of the function. It is essentially analogous to a common use case of Go's defer. Typically an accepted pattern when dealing with many resources and possible exit points. Prevalent in I/O heavy code. Different ballgame from the subject…

> It is essentially analogous to a common use case of Go Go, which is also known for its terrible error-handling. Great.

Really? I have never seen a Go program to misbehave while not printing some meaningful output. It is possible but almost no one ignores the error parameter. Yet I have seen many, many Java and Python software which quit after the first Unhandled Exception. So often that I consider exceptions as the bad error handling mechanism.
Post reply on HN