Stealing unencrypted SSH-agent keys from memory (2014) | Hacker News Reader

Stealing unencrypted SSH-agent keys from memory (2014)

blog.netspi.com

20 pointskencausey7 comments

This is pretty obvious; the while purpose of ssh-agent is to do this. Once you have access to the user account of whoever is running any software that does any kind of crypto (or in some cases root, depending on kernel hardening settings re: debugging/ptrace), you can always get the keys.

Those concerned about this attack vector should use hardware tokens, like a YubiKey. They aren't infallible, as they could be stolen while unlocked with some USB trickery to keep them active, but it beats being able to trivially dump the key material.

I’ve been pondering writing a kernel module that basically exposes the Golang TLS API (with hooks for things like CertPool and VerifyConnection) - so that rather than opening TCP sockets, you can open a TLS socket directly. There’s a lot of complication involved here, but having the TLS state inaccessible from userspace has a lot of desirable attributes.

Further on this line of thinking, it’s an entirely reasonable extension of the “secure bastion” on modern processors to allow for a temporary private key store - You load your private key into the bastion and get back a key handle, which can then be used to do TLS handshakes but only through the bastion. Once that’s done, recovery of the private key is impossible, only abuse of it by the kernel (by passing that handle to other processes)

It would be better to build up a library for using the existing ktls support from golang instead. Shouldn't be too hard and then it'll be better supported by being in the mainline kernel.

https://www.kernel.org/doc/html/latest/networking/tls-offloa...

I’m familiar with that infrastructure; However, that only takes over once a session-key has been negotiated, that is, after TLS handshake is completed and certs have been verified. That’s great - Everything should use that. What I’m proposing goes one further. When opening a socket, you should be able to specify your private key and certificate, pass it to the kernel, and be unable to further access that key from there. That way, your private key would be able to be entirely removed from userspace memory; Unrecoverable even if tried. Kernel TLS offloading as it exists is a performance enhancement that can potentially move the encryption computation into your NIC. What I’m proposing is a security barrier that reduces the amount of time that the private key is resident in (process mapped) memory.

Interesting, I didn't realize it only took over from that part of the communication. That would certainly be a nice to have thing then, maybe use the current kernel key management stuff so that it could even be done in a way that the process never actually gets to load the key itself but it's instead loaded by something else and given the id needed to tell the kernel that the socket should use it. I do wonder how this would play with SNI and such which might make it a non-starter for a lot of cases.

An earlier entry (https://news.ycombinator.com/item?id=24768220) to a Windows 10 specific blog post linked to this blog post from 2014 which appears to have never been posted here. So I did so.

Oops, it did appear earlier with a variant link: https://news.ycombinator.com/item?id=8065583 (2014) which has a fair number of comments although the original link no longer works.

Reply on news.ycombinator.com