Hacker News new | past | comments | ask | show | jobs | submit login

> it would be easy to guarantee that you can get a rootkit-free phone

The problem in this case is that you get the malware installed through a no-click required iMessage and not a "supply chain" attack on the image your phone is running on. How would that help?




It could help by simply being sufficiently different. The only reason this type of malware is such a widespread problem is the large monoculture of potential targets. Just like in agriculture (e.g. potatoes, bananas), a monoculture allows a single pathogen to affect an entire crop. In security this is a class break[1].

Utilizing different software implementations limits the scope of this type of attack. The current trend to increasing centralization and forced-update monoculture is a huge gift to malware authors: they only have to write one version of their malware to affect everyone.

[1] https://www.schneier.com/blog/archives/2017/01/class_breaks....


This is a good principle in terms of reducing the overall blast radius of exploits. But to do this the implementations should genuinely be independent.

In practice we may find a monoculture within a hidden layer of the stack than we're optimizing for, such as an OS kernel method, TLS library or chipset which coincidentally has captured the entire market. When a clever enough exploit on a common resource is found, then the problem transforms to one of coordinating patching for the same, wherein a broad ecosystem of higher level components (like Android or PCs) becomes nearly impossible to thoroughly cover. As such malware authors may potentially still get away with writing a single version of their software so long as they target low-level enough. With sufficient fragmentation they don't even need to invent their own exploits, just use publicly known CVEs that they can brute-force against older devices.

(Not saying you're wrong, your recommendation may still be better in the long-run. We're after all weighing the risk level of black swan events, such as a zero-day on a low level of the stack, or a high level of the stack on a high-volume vendor)


On the flip side, having a monoculture is good because you made more eyes looking at the same piece of code.


How many people have seen the iMessage source code? A handful of devs at Apple? Closed, proprietary software by definition prevents "more eyes" from looking. Even if we consider an open source product where having "many eyes" review the code is at least hypothetically possible, a large number of people using the software doesn't imply there is also a large amount of people reviewing it.


>Closed, proprietary software by definition prevents "more eyes" from looking

But we were talking about the general case of monoculture, not closed source monoculture. Even for closed source software, where more eyes are prevented from looking "by definition", having a monoculture can in theory allow more code audits to be done, because of economy of scale.

> large number of people using the software doesn't imply there is also a large amount of people reviewing it.

Right, but roughly speaking, the number of reviewers should monotonically increase given an increase in users. Whether that produces better security overall is anyone's guess. My point was just that there was a counteracting force to consider.


The argument isn't that granting more freedoms to the owner of the device will magically make it more secure in all cases, for most it won't.

The argument is that removing freedoms from owners in the name of security is a false dichotomy because bad actors will still gain the ability to execute arbitrary code whilst owners of devices won't be able to do so.

Also, if I could provide the software I want to run, I'd probably not have iMessage.


It would help because knowledgeable people would get to pick what software they run on their phones and iMessage probably wouldn't be on the list.


Journalists (as here) don't usually get to choose the communication software their sources are comfortable communicating over. They install whatever's required to get the story. And they likely wouldn't install an OS that doesn't let them install such apps.


That's a niche use case. You might not be able to choose what app they require to communicate over, but you can choose what device to install it onto, like a burner, couldn't you? Some apps you might not mind on your personal phone, others you probably do.


Well, yes, but if you think about it, the whole point of a journalist's work phone is just to aggregate a bunch of "burner" accounts. And that's exactly what an attacker would want to steal from a journalist: conversations between them and (or contact details of) another source.

Which is all to say, ideally a journalist would have N phones, one per source. But that's impractical.


Would it? Wouldn't you still need privilege escalation? Having root access is different from being logged in as the root user. Of course being logged in as root comes with all the same security risks as it does if you do this on Linux. But no one uses root as their main account.


You could replace the image with software that doesn't support iMessage, for example.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: