Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH gets protection against side-channel attacks

undeadly.org

Post reply on HN
Print view View original

131–140 of 166 posts

Re: SSH gets protection against side-channel attacks

#131

Post by LinuxBender »

simias wrote: post #55
tremon wrote: post #26

Earlier quoted context omitted.

What part of the existing purpose is performance-critical?

I certainly wouldn't want scp to suddenly slow down compared to what I'm used to. I use scp and sftp rather heavily to transfer very large files and do backups, that might not be performance-critical but it's definitely performance-sensitive. I haven't had to mess with that in a while but there was a time where you'd get a significant boost with scp on underpowered hosts if you used the arcfour cipher for instance (I…

Using LFTP's mirror sub-system plus SFTP can be faster than all of the unencrypted protocols. It gives you the behavior of rsync, but can work with sftp+chroot logins and can spawn multiple threads per job or even per file. Working demo [1]

I find it very useful when I want to give people the ability to transfer files quickly, but I don't want to give them a shell.

[1] - https://tinyvpn.org/sftp/#lftp

Re: SSH gets protection against side-channel attacks

#132

Post by abugheratwork »

mehrdadn wrote: post #38
pixl97 wrote: post #13

Earlier quoted context omitted.

Ah yes, I too love the panicked rush of trying to force application vendors to patch once we we discover something is being exploited in the wild. Remember defense is depth is a valid strategy.

What I was trying to say was I think library users care to know how urgent it is. If this is being used in the wild then application vendors might need to provide out-of-band patches somehow, and end users should rush to get those patches. If OTOH this is known to be extremely hard to pull off and not known to be used, then it'd be nice for users to know that just the same. Nowhere was I trying to suggest they should…

I agree with the idea that availability of information is good, and that information about the context for a security-related change should be made transparent. But how relevant is it? I would think relevant enough for FAQ or other reference information. I wouldn't include it in announcements, though.

The headline is "patch available, mitigating known exploit". "Not yet widely exploited" is barely a footnote. The release of a patch can bring enough attention to make the window between release and full deployment of the patch the single worst time to be vulnerable. If I tell you it wasn't being exploited yesterday, and you delay patching based on that information, and then the storm of exploits blows through ... I'd feel bad.

Re: SSH gets protection against side-channel attacks

#133

Post by mjevans »

thijsvandien wrote: post #56
reza_n wrote: post #15

Earlier quoted context omitted.

Yup, we added this feature to Varnish Cache a few years ago, random key encryption. It generates a random key at startup and encrypts all memory with it. Since this kind of memory is only resident for the lifetime of the process, it works. We stored the random key in the Linux kernel using the crypto API [0] just because its not safe storing any kind of keys in a memory space used for caching (Cloudbleed [1]). We the…

Could this be implemented at the OS level, i.e. whenever a proces launches, the OS generates a key that it will keep to itself and use to transparently encrypt all memory allocated by that process?

My first thought was to try to use 'containers' (cgroups) combined with the AMD secure memory extensions to achieve this type of isolation using as much off the shelf hardware as possible.

https://en.wikichip.org/wiki/x86/sme

https://www.kernel.org/doc/Documentation/x86/amd-memory-encr...

From the quick description it sounds like this provides a way of encrypting, per memory page, based on a symmetric key that is backed by some level of hardware encryption. It was not clear (in a quick read) how or where to specify the key by which an individual page is encrypted. That would be a critical component of comprehension with respect to identifying if this could be used to encipher individual processes and further isolate memory. It sounds like it might be possible to establish per-process memory isolation, which is probably the best level of security possible without resorting to entirely isolated hardware.

Re: SSH gets protection against side-channel attacks

#134

Post by the8472 »

thijsvandien wrote: post #56
reza_n wrote: post #15

Earlier quoted context omitted.

Yup, we added this feature to Varnish Cache a few years ago, random key encryption. It generates a random key at startup and encrypts all memory with it. Since this kind of memory is only resident for the lifetime of the process, it works. We stored the random key in the Linux kernel using the crypto API [0] just because its not safe storing any kind of keys in a memory space used for caching (Cloudbleed [1]). We the…

Could this be implemented at the OS level, i.e. whenever a proces launches, the OS generates a key that it will keep to itself and use to transparently encrypt all memory allocated by that process?

Per-process keys aren't really possible because memory can change process ownership (vmsplice) or be shared across processes (fork, page cache, memfd). It might be possible for pages marked MADV_DONTFORK

Additionally a per-process key does not help against spectre style attacks where you would trick the process into speculating on protected memory.

Re: SSH gets protection against side-channel attacks

#135

Post by eridius »

ajaurio wrote: post #114

Could password managers like 1Password (AgileBits Inc.) employ similar techniques? They seem to make very little effort in this regards. E.g. on 1Password, https://discussions.agilebits.com/discussion/101551/article-... .

This kind of mitigation really only makes sense on shared machines (such as servers). On a desktop OS, if an attacker is in a position to read memory from other processes, it's pretty much game over already.

Browsers implement Spectre/Meltdown mitigation on desktop OSes because without that, JS could read secrets from other JS contexts executing in the same process. One of the mitigations is in fact to just segregate JS contexts into different processes depending on the domain they belong to. But most apps don't execute untrusted code so most apps don't have this sort of in-process attacker to worry about.

Re: SSH gets protection against side-channel attacks

#136

Post by vageli »

dang wrote: post #123
ris wrote: post #122

Earlier quoted context omitted.

> Closed source Ah, so we'll just have to trust you that it's doing anything at all, then.

" Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. " https://news.ycombinator.com/newsguidelines.html

> "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."

> https://news.ycombinator.com/newsguidelines.html

Forgive me but can we not be skeptical of claims made about a commercial product?

Re: SSH gets protection against side-channel attacks

#137

Post by mehrdadn »

abugheratwork wrote: post #132
mehrdadn wrote: post #38

Earlier quoted context omitted.

What I was trying to say was I think library users care to know how urgent it is. If this is being used in the wild then application vendors might need to provide out-of-band patches somehow, and end users should rush to get those patches. If OTOH this is known to be extremely hard to pull off and not known to be used, then it'd be nice for users to know that just the same. Nowhere was I trying to suggest they should…

I agree with the idea that availability of information is good, and that information about the context for a security-related change should be made transparent. But how relevant is it? I would think relevant enough for FAQ or other reference information. I wouldn't include it in announcements, though. The headline is "patch available, mitigating known exploit". "Not yet widely exploited" is barely a footnote. The rel…

> I would think relevant enough for FAQ or other reference information. I wouldn't include it in announcements, though.

Maybe you wouldn't, but US-CERT, Mozilla, etc. do...

https://www.us-cert.gov/ncas/current-activity/2019/06/18/Moz...

https://www.mozilla.org/en-US/security/advisories/mfsa2019-1...

Re: SSH gets protection against side-channel attacks

#138

Post by MarkSweep »

java-man wrote: post #92
saurik wrote: post #90

Earlier quoted context omitted.

In that code, after generateKey, during the sensitive operation, the system might need to do a garbage collection, at which point this array might have been copied to a different location in memory before your call to zero. You have to also "pin" (afaik this is the usual terminology for this) that array to a fixed location (which would then have to be a feature of that runtime and garbage collector) after allocating…

So what you are saying is that JVM copying surviving object between generational pools might expose secrets in memory? A very good point, thank you. What could be done to mitigate this? Direct ByteBuffer per https://stackoverflow.com/questions/5670862/bytebuffer-alloc... ?

In .NET you can pin memory in the GC heap, either using something like the fixed expression in C# or GCHandle. A quick Googleing did not turn up something usable directly by Java, except ByteBuffer.

Re: SSH gets protection against side-channel attacks

#139

Post by rphlx »

jasonh3 wrote: post #120

When I first saw this post, I got excited that someone had finally addressed the side channel from 17 years ago, which gathered inter-packet timing from ssh packets (and the fact that passwords are not echo'd) to a) detect when passwords were being typed, and b) use Hidden Markov Models to extract keystroke timing to try to extract the likely passwords. There have been defenses proposed over the years, but none were…

If you really cannot use keys, then one mitigation is to use copy/paste to paste the entire password instead of typing it one character at a time. That can open some copy/paste vulnerabilities e.g. in X11 where any app can then read the password until you copy something else in its place. And a network observer may still determine the password length. But it closes the inter-key timing channel that permits direct character recovery.

Re: SSH gets protection against side-channel attacks

#140

Post by rphlx »

gnur wrote: post #130
wahern wrote: post #126

Earlier quoted context omitted.

The proper defense is to not use passwords. It's 2019, nobody should be using passwords on SSH-enabled shell accounts. Heck, I use secure tokens for authentication so this memory encryption hack is useless to me--even I don't know what my private key(s) are, nor does OpenSSH or any other software on my computers. But I appreciate that we're a long way from ubiquitous hardware-based authentication.

After you are connected you might still want to enter a password (for sudo perhaps).

The solution there is to have the app use line buffering rather than a "raw" term mode that exposes inter-char timing on the network. How widely that's followed in practice, I do not know, but one would certainly hope that sudo does it.
Post reply on HN