Live data from Hacker News

NetSpectre: Read Arbitrary Memory Over Network [pdf]

misc0110.net

21–24 of 24 posts

Re: NetSpectre: Read Arbitrary Memory Over Network [pdf]

#21
post #15

Spectre just became a much bigger problem.

not really... this is only a vulnerability in so much as specific gadgets were intentionally placed in code. it's more of a danger for intentional data exfiltration covertly, not an issue of attacking random servers like ssh or web servers to get keys. show me a vulnerable ssh or web server and i'll be worried, otherwise, this is just hype about a new class of theoretical attack that has no known actual real world ta…

to further elaborate, it would take 85 days of 4gbps network link being 100% saturated to leak a 256 bit key, assuming you know the memory locations, assuming no ASLR, assuming the key doesn't move or change, and assuming a vulnerable spectre gadget running on the system, which means you already have RCE in the first place. this class of attack is easily mitigated, and has no real world implications. if you don't notice a 4gbps link being fully saturated for months at a time, you have bigger problems. otherwise, if you don't reboot a server or restart services within 85 days, and if you don't use ASLR, you have bigger problems. if you let someone run spectre code on your system, you have bigger problems.

this class of attack is theoretical, and all the hype is unsubstantiated. clearly y'all haven't read the paper. people never read past the headlines any more...

you don't even have to take my word for it, READ THE PAPER:

> As NetSpectre is a network-based attack, it cannot only be preventedby mitigating Spectre but also through countermeasures onthe network layer. A trivial NetSpectre attack can easily be detectedby a DDoS protection, as multiple thousand identical packets aresent from the same source. However, an attacker can choose anytrade-off between packets per second and leaked bits per second.Thus, the speed at which bits are leaked can simply be reducedbelow the threshold that the DDoS monitoring can detect. This istrue for any monitoring which tries to detect ongoing attacks, e.g., intrusion detection systems. Although the attack is theoretically not prevented, at some point the attack becomes infeasible, as the time required to leak a bit increases drastically. Another method to mitigate NetSpectre is to add artificial noise to the network latency. As the number of measurements depends on the variance in network latency, additional noise requires an attacker to perform more measurements. Thus, if the variance in network latency is high enough, NetSpectre attacks become infeasible due to the large number of measurements required.

Re: NetSpectre: Read Arbitrary Memory Over Network [pdf]

#22
post #20

Earlier quoted context omitted.

> overly complex Speculative execution is what makes our sequential code fast by exploiting parallel execution pipelines that would otherwise sit idle. Avoiding this would increase complexity somewhere else, e.g. compilers would have to become even more clever or programmers would have to work harder to reduce the branches in their code. Sprinkling code with annotations to prevent speculative execution around sensiti…

Complex compilers seem better than complex chips because the former is software and can be fixed. I'm wondering these days if Intel was onto something with EPIC/Itanium and just failed in the execution.

They were definitely onto something. They made something competitive performance-wise that wasn't vulnerable to all of these speculative execution vulnerabilities.

Itanium's slowness is generally very exaggerated (at least in part because the first Itanium had a rather slow memory subsystem, and the performance kind of sucked as a result). Circa 2008 or so the fastest database servers available were Itanium. Unfortunately, it emulated x86 extremely slowly and amd64 ran x86 very quickly, so AMD kinda ate Intel's lunch.

Re: NetSpectre: Read Arbitrary Memory Over Network [pdf]

#23
post #22
post #20

Earlier quoted context omitted.

Complex compilers seem better than complex chips because the former is software and can be fixed. I'm wondering these days if Intel was onto something with EPIC/Itanium and just failed in the execution.

They were definitely onto something. They made something competitive performance-wise that wasn't vulnerable to all of these speculative execution vulnerabilities. Itanium's slowness is generally very exaggerated (at least in part because the first Itanium had a rather slow memory subsystem, and the performance kind of sucked as a result). Circa 2008 or so the fastest database servers available were Itanium. Unfortun…

If I were at Intel management I might explore with engineering resurrecting the Itanium (rebranded and modernized of course). Today with so much open source there is less instruction set lock in, and with all these vulnerabilities you might be able to market it as a more secure architecture. In that case you might only need to equal x64 performance.
Post reply on HN