Hacker News new | past | comments | ask | show | jobs | submit login
Weakness in Intel chips lets researchers steal encrypted SSH keystrokes (arstechnica.com)
36 points by headalgorithm 9 days ago | hide | past | web | favorite | 10 comments

> People should also be aware that disabling DDIO comes at a significant performance cost. So far as the researchers know, chips from AMD and other manufacturers aren't vulnerable because they don't store networking data on shared CPU caches.

Again, performance gains leak sensitive data and the solution is to disable some features (and loose performance as well). Seems that Intel chose between performance x security, and security lost.

> Intel DDIO is enabled by default on all Intel Xeon processor E5 family and Intel Xeon processor E7 v2 family platforms. (from https://www.intel.com/content/www/us/en/io/data-direct-i-o-t...)

Seems that it was used in 2012-2014 processors, so it's an attack on 5-years-old processors. Perhaps the impact isn't that great nowadays, but I couldn't find it the same attack can be made in more recent CPUs.

The web site of the researchers says:

> Yes, DDIO is enabled transparently by default in all Intel server-grade processors since 2012 (Intel Xeon E5, E7 and SP families).


Intel claimed that DDIO would boost performance up to 2.3x. that's a pretty big performance hit.


So, if I get this correct, the researchers side-channeled the LLC to reveal data stored there by the NIC (DDIO).

This flaw in ssh has been known about for ages, and has nothing to do with Intel, and putting data in cache is neither Intel-specific nor a "weakness".

For others, see https://www.usenix.org/conference/10th-usenix-security-sympo...

(You can recognize individual people from keystroke timing now. And I don't think this is patched in openssh.)

It isn't good if a remote non-MITM attacker can see the exact timing and cache associativity of remote writes. It doesn't seem from the article that they can monitor timing of other data, but then they also say the CPU does not reserve specific parts of cache for DDIO, leaving open the possibility of recovering information about local process memory/cache operations, the obvious candidate of interest being RSA calcs. I would not be surprised to see more attacks come from this.

Explain please. This is about direct device io exposing memory remotely through timing attacks. Ssh info is just one example of what can be leaked.

Memory isn't being exposed, just the fact that something is touching memory in a certain place. That ssh login keystrokes leak via side channels is a long standing flaw in ssh. Memory access patterns can already be inferred from network response latency on any processor, nothing about that is new or surprising.

This doesn't give more timing precision than previous techniques?

It is a super accurate way of timing packet receipt. For keystrokes sent across a WAN that wouldn't normally help you. But this really isn't about ssh, which is just used as a cute demo of the power of traffic analysis and side channels; this is about remote access to local side channels in the memory system.

Applications are open for YC Winter 2020

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