4 ms·

Stealing unencrypted SSH-agent keys from memory (2014)

20 points by kencausey 6y ago

kencausey 6y ago
An earlier entry (https://news.ycombinator.com/item?id=24768220 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.
- kencausey 6y ago
  Oops, it did appear earlier with a variant link: https://news.ycombinator.com/item?id=8065583 https://news.ycombinator.com/item?id=8065583 (2014) which has a fair number of comments although the original link no longer works.
marcan_42 6y ago
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.
- GauntletWizard 6y ago
  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)
  - simcop2387 6y ago
    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-offload.html https://www.kernel.org/doc/html/latest/networking/tls-offloa...
    - GauntletWizard 6y ago
      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.
      - simcop2387 6y ago
        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.

20 points by kencausey 6y ago

An earlier entry (https://news.ycombinator.com/item?id=24768220 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.

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

marcan_42 6y ago

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.

GauntletWizard 6y ago
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)
- simcop2387 6y ago
  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-offload.html https://www.kernel.org/doc/html/latest/networking/tls-offloa...
  - GauntletWizard 6y ago
    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.
    - simcop2387 6y ago
      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.