4 ms·

I've upvoted this because I want to see what really smart people have to say about it. That said, I've always been of mind that if someone gains unauthorized ro

by yock 12y ago

I've upvoted this because I want to see what really smart people have to say about it. That said, I've always been of mind that if someone gains unauthorized root access to my box, then nothing on it can ever be trusted again. This includes things in memory. In other words, this feels obvious to me, once pointed out. Is there something novel about this that I'm missing?

hemancuso 12y ago
No. If you have the ability to run code as root it's game over. Even if the agent re-encrypted the key in memory with its own temporary key it's just a layer of obfuscation that can easily be overcome.
tlrobinson 12y ago
I agree with you, but in case you missed the author's rationale: "However, this causes the attacker to have to wait for the target to type in their passphrase. This might be hours, days, or weeks, depending on how often the target logs out. This is why obtaining the SSH key from memory is vital to pivoting to other machines in a speedy fashion." I'm not sure how you would solve this problem while providing the functionality ssh-agent provides, aside from perhaps a HSM or something.
- agwa 12y ago
  Anyone keeping SSH keys in an ssh-agent process for weeks on end is doing it wrong. You can use the -t option to ssh-agent to specify a maximum lifetime for identities added to the agent. I would set it to less than a day.
  - zobzu 12y ago
    if you unlock it as soon as it expires im not sure what that gives you. all the attacker needs anyway in that scheme is 24h, its not a big difference.
- MichaelGG 12y ago
  Make sure nothing can run as root? Perhaps by using a VM system. You could run ssh-agent on another machine and make key requests over an internal network. Also you can get a cheap "HSM" by using a smartcard.
- peterwwillis 12y ago
  The problem of a root user inspecting the memory of arbitrary other users is solved with MAC like SELinux. https://security.stackexchange.com/questions/7801/keeping-secrets-from-root-on-linux https://security.stackexchange.com/questions/7801/keeping-se... But if you can exploit a specific user's program, you can (usually) inspect the memory of other programs managed by that user. You can actually create security policies so secure that a user who exploits the sshd program can't read from the same user's ssh-agent process memory, but that's not practical for most people.
agwa 12y ago
It's not that novel. If an attacker gets root it's game over. That said, the article is a good reminder of the risk of keeping decrypted keys in a long-running ssh-agent process.
deleted 12y ago
[deleted]
zobzu 12y ago
nothing's novel - but consider this for example: - if its a server and you copy your private key onto it its likely to be compromised one day and the key reused even thus it was encrypted.. since its decrypted in memory when used. plus keystrokes could be captured. if you use this key elsewhere, all other servers are also compromised now.. - you can keep the key in a hardware token, then even if a laptop is remotely compromised your key - and thus servers you're not currently accessing - are safe. its also a little harder to hijack a connection or silently ask the key (generally its not silent with a token)

by yock 12y ago

hemancuso 12y ago

No. If you have the ability to run code as root it's game over. Even if the agent re-encrypted the key in memory with its own temporary key it's just a layer of obfuscation that can easily be overcome.

tlrobinson 12y ago

I agree with you, but in case you missed the author's rationale: "However, this causes the attacker to have to wait for the target to type in their passphrase. This might be hours, days, or weeks, depending on how often the target logs out. This is why obtaining the SSH key from memory is vital to pivoting to other machines in a speedy fashion." I'm not sure how you would solve this problem while providing the functionality ssh-agent provides, aside from perhaps a HSM or something.

agwa 12y ago
Anyone keeping SSH keys in an ssh-agent process for weeks on end is doing it wrong. You can use the -t option to ssh-agent to specify a maximum lifetime for identities added to the agent. I would set it to less than a day.
- zobzu 12y ago
  if you unlock it as soon as it expires im not sure what that gives you. all the attacker needs anyway in that scheme is 24h, its not a big difference.
MichaelGG 12y ago
Make sure nothing can run as root? Perhaps by using a VM system. You could run ssh-agent on another machine and make key requests over an internal network. Also you can get a cheap "HSM" by using a smartcard.
peterwwillis 12y ago
The problem of a root user inspecting the memory of arbitrary other users is solved with MAC like SELinux. https://security.stackexchange.com/questions/7801/keeping-secrets-from-root-on-linux https://security.stackexchange.com/questions/7801/keeping-se... But if you can exploit a specific user's program, you can (usually) inspect the memory of other programs managed by that user. You can actually create security policies so secure that a user who exploits the sshd program can't read from the same user's ssh-agent process memory, but that's not practical for most people.

agwa 12y ago

It's not that novel. If an attacker gets root it's game over. That said, the article is a good reminder of the risk of keeping decrypted keys in a long-running ssh-agent process.

deleted 12y ago

[deleted]

zobzu 12y ago

nothing's novel - but consider this for example: - if its a server and you copy your private key onto it its likely to be compromised one day and the key reused even thus it was encrypted.. since its decrypted in memory when used. plus keystrokes could be captured. if you use this key elsewhere, all other servers are also compromised now.. - you can keep the key in a hardware token, then even if a laptop is remotely compromised your key - and thus servers you're not currently accessing - are safe. its also a little harder to hijack a connection or silently ask the key (generally its not silent with a token)