4 ms·
This attack, "BranchScope", seems largely unrelated to Spectre - it's "just" another side-channel attack, allowing an attacker to learn which branches were take
by JoachimSchipper 9y ago
This attack, "BranchScope", seems largely unrelated to Spectre - it's "just" another side-channel attack, allowing an attacker to learn which branches were taken by a victim process. BranchScope has a similar impact, and seems less convenient and slower, than pre-existing attacks that poke at the CPU cache. (Spectre 2 is scarier, because it allows the attacker to learn more-or-less anything accessible to the victim process.)
Which isn't to say that this is bad work, nor even that the authors are over-hyping it (in fact, the paper mentions Spectre... very early in the introduction only.) But this article makes it easy to over-estimate the impact.
As always, crypto code (in particular) must be constant-time (constant-everything) to avoid key recovery via such attacks. But again, that isn't new - cache-based attacks have broken lots of non-constant-time crypto code.
- mannykannot 9y agoThe issue goes beyond the limited threat of any particular vulnerability. The larger issue is that we were blindsided by a category of systemic vulnerabilities that upend prior assumptions about the security of core principles of modern processor and operating system design, which raises doubt about our collective ability to identify and avoid risks in the design phase of computer and communications systems. Even if every individual aspect of these vulnerabilities had been recognized before, it is undeniable that the risks of their synergistic (from the point of view of an attacker) combination had not been properly appreciated prior to deployment of the affected technology, and for some time after.
- akavel 9y agoInterestingly, there are people for whom this is of 0 surprise, and who built systems avoiding issues like this decades ago. See e.g. many comments by user https://news.ycombinator.com/threads?id=nickpsecurity https://news.ycombinator.com/threads?id=nickpsecurity, who tries to pursue a bona fide mission to educate. The main problem was of cost, and current "modern" processors are generally an example of the how the "it's cheaper to fail and then apologise" approach wins economically for consumer software.
- TeMPOraL 9y ago> The main problem was of cost, and current "modern" processors are generally an example of the how the "it's cheaper to fail and then apologise" approach wins economically for consumer software. This happens everywhere; hell, that's how we ended up with Unix. "Worse is better".
- lholden 9y agoAttacks against a host system of a virtual machine or of a shared system have been speculated about for quite a long time. I really do not think it should be a surprise to anyone that these vulnerabilities are being announced. Yeah, it certainly stands up shake up our industry... but I am not sure we were blindsided by it. Using shard or managed hardware has always been a compromise between the increased risk against the convenience. Nobody wants to build a data center out of their office anymore. Some of this risk can be mitigated by using managed but dedicated hardware. More expensive, but the option exists just about everywhere.
- mannykannot 9y agoBased on the facts of how this problem has played out, I think it is an empirical fact that the major processor and operating system producers were blindsided by this issue, even though there were some people, such as Philip Guenther from OpenBSD, saying there is probably an exploit here. There seems to be a certain amount of after-the-fact analysis to the claim that no-one should have been surprised by this, and even that was, in fact, the case, the broader concern simply becomes one of why the situation was allowed to develop. In retrospect, we can say that people were making decisions that favored convenience over security, but were they aware at the time what specific compromises they were making? Either way, there is an important issue here that does not go away by saying they should or could have known.