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

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.

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