3 ms·

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 ta

by pdkl95 5y ago

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.html https://www.schneier.com/blog/archives/2017/01/class_breaks....

maldeh 5y ago
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)
gruez 5y ago
On the flip side, having a monoculture is good because you made more eyes looking at the same piece of code.
- pdkl95 5y ago
  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.
  - gruez 5y ago
    >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.

by pdkl95 5y ago

maldeh 5y ago

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)

gruez 5y ago

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

pdkl95 5y ago
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.
- gruez 5y ago
  >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.