6 ms·

Am I correct in thinking that this is working as intended, and not actually a vulnerability? Many people seem to be sharing this as "look at Microsoft screwing

Am I correct in thinking that this is working as intended, and not actually a vulnerability? Many people seem to be sharing this as "look at Microsoft screwing up ssh-agent security", but I can't actually see any evidence of this in the article.

deleted 8y ago
[deleted]
EvanAnderson 8y ago
You are correct. There is no "vulnerability" here. The plaintext of the user's private keys must be accessible to the CPU performing the cryptographic operations. DPAPI is a reasonable method to keep the keys encrypted "at rest" while allowing the keys to be decrypted w/o the requiring password entry each time the keys are used. It is helpful for post-exploitation toolkits to have this functionality.
- vesinisa 8y ago
  AFAIK the whole point of ssh-agent is that the private keys are NOT extractable by other processes. https://man.openbsd.org/ssh-agent https://man.openbsd.org/ssh-agent: > The agent will never send a private key over its request channel. Instead, operations that require a private key will be performed by the agent, and the result will be returned to the requester. This way, private keys are not exposed to clients using the agent. This sounds like a pretty gaping security hole by Microsoft. I would not assume loading private keys to an "ssh-agent" means giving any process (browser, email client etc.) running on the same machine access to the unencrypted values!
  - EvanAnderson 8y ago
    The SSH agent isn't divulging the keys. The OP is decrypting the keys from the underlying storage. The API used to protect the keys allows the keys to be decrypted without explicit password entry. The OP has the necessary password to decrypt the keys, so the API allows it. The SSH agent isn't involved.
    - deleted 8y ago
      [deleted]
    - deleted 8y ago
      [deleted]
    - skrause 8y ago
      > The SSH agent isn't divulging the keys. The OP is decrypting the keys from the underlying storage. But can't just any program do that as soon as you're logged in? (Since your login password basically unlocks the DP-API which is protected at rest.)
      - JesseWright 8y ago
        A program would need the appropriate level of access (which isn't actually that high a bar), but at the end of the day the fact of the matter remains: other processes can potentially access private keys that would otherwise remain password protected.
  - Amezarak 8y ago
    > I would not assume loading private keys to an "ssh-agent" means giving any process (browser, email client etc.) running on the same machine access to the unencrypted values! It doesn't. > AFAIK the whole point of ssh-agent is that the private keys are NOT extractable by other processes. Any process with sufficient privileges (i.e., root) can extract the private key from ssh-agent on Linux as well.
    - geofft 8y ago
      But the definition of "sufficient privileges" is different here - on most Linux distros (and I'd guess on other OSes?) ssh-agent protects itself from being accessed by the same user account (via the debugging APIs) by being setgid to group ssh. On Windows, the data protection API specifically allows any process running as the same user on the same computer to decrypt protected data. So it's not a vulnerability in the sense of an unintended exposure, but, it's certainly true that Microsoft's design gives the private key much more exposure than the design used on most Linux distros. (And it's unclear whether MS intended to deviate from this behavior.)
      - deathanatos 8y ago
        > ssh-agent protects itself from being accessed by the same user account (via the debugging APIs) by being setgid to group ssh I don't think this is correct. ssh-agent typically will be run under your user/group; it shouldn't have the necessary privileges to setgid to ssh. Further, I have ssh-agent running on a machine, and it is still my gid. Last, that machine doesn't even have an "ssh" group. Rather, I think ssh-agent likely protects itself from being debugged (ptrace'd) by ptrace'ing itself. My understanding is that a process can only be ptraced by one process at a time, and by ptrace'ing yourself, you deny the ability for anything else to attach to you. For example, my uid & gid: » printf '%s,%s\n' "$(id -u)" "$(id -g)" 1000,1000 ssh-agent running as those: » ps -eo pid,uid,gid,args | grep ssh-agent 16438 1000 1000 ssh-agent but not debuggable: » strace -p 16438 strace: attach: ptrace(PTRACE_SEIZE, 16438): Operation not permitted Perhaps this is just my machine however, and if I did have a `ssh` group, and I were a member of it, it would setgid to it. I don't think that's foolproof, however: something running under your uid could kill ssh-agent, and restart it under a debugger, skip or elide the setgid() and ptrace() calls, then continue to allow it to execute normally, and now be attached as a debugger. I'm also not sure if ptrace()'ing yourself prevents you from reading out the process's memory from /proc. Edit: so, on Linux, it seems this is what it does[1]: prctl(PR_SET_DUMPABLE, 0) That makes the process "undumpable", which means it won't leave behind core files, /proc/pid is root:root, and it can't be ptrace()'d. I still think the caveat about starting it under a debugger applies, but that certainly makes it less trivial. [1]: https://github.com/openssh/openssh-portable/blob/5ee3fb5affd7646f141749483205ade5fc54adaf/platform-tracing.c#L38 https://github.com/openssh/openssh-portable/blob/5ee3fb5affd...
ropnop 8y ago
Yep, you're correct. Not a vulnerability or an exploit. It's always going to be possible with the right privileges, I was just wanted to see and show the "how"

deleted 8y ago

[deleted]

EvanAnderson 8y ago

You are correct. There is no "vulnerability" here. The plaintext of the user's private keys must be accessible to the CPU performing the cryptographic operations. DPAPI is a reasonable method to keep the keys encrypted "at rest" while allowing the keys to be decrypted w/o the requiring password entry each time the keys are used. It is helpful for post-exploitation toolkits to have this functionality.

vesinisa 8y ago
AFAIK the whole point of ssh-agent is that the private keys are NOT extractable by other processes. https://man.openbsd.org/ssh-agent https://man.openbsd.org/ssh-agent: > The agent will never send a private key over its request channel. Instead, operations that require a private key will be performed by the agent, and the result will be returned to the requester. This way, private keys are not exposed to clients using the agent. This sounds like a pretty gaping security hole by Microsoft. I would not assume loading private keys to an "ssh-agent" means giving any process (browser, email client etc.) running on the same machine access to the unencrypted values!
- EvanAnderson 8y ago
  The SSH agent isn't divulging the keys. The OP is decrypting the keys from the underlying storage. The API used to protect the keys allows the keys to be decrypted without explicit password entry. The OP has the necessary password to decrypt the keys, so the API allows it. The SSH agent isn't involved.
  - deleted 8y ago
    [deleted]
  - deleted 8y ago
    [deleted]
  - skrause 8y ago
    > The SSH agent isn't divulging the keys. The OP is decrypting the keys from the underlying storage. But can't just any program do that as soon as you're logged in? (Since your login password basically unlocks the DP-API which is protected at rest.)
    - JesseWright 8y ago
      A program would need the appropriate level of access (which isn't actually that high a bar), but at the end of the day the fact of the matter remains: other processes can potentially access private keys that would otherwise remain password protected.
- Amezarak 8y ago
  > I would not assume loading private keys to an "ssh-agent" means giving any process (browser, email client etc.) running on the same machine access to the unencrypted values! It doesn't. > AFAIK the whole point of ssh-agent is that the private keys are NOT extractable by other processes. Any process with sufficient privileges (i.e., root) can extract the private key from ssh-agent on Linux as well.
  - geofft 8y ago
    But the definition of "sufficient privileges" is different here - on most Linux distros (and I'd guess on other OSes?) ssh-agent protects itself from being accessed by the same user account (via the debugging APIs) by being setgid to group ssh. On Windows, the data protection API specifically allows any process running as the same user on the same computer to decrypt protected data. So it's not a vulnerability in the sense of an unintended exposure, but, it's certainly true that Microsoft's design gives the private key much more exposure than the design used on most Linux distros. (And it's unclear whether MS intended to deviate from this behavior.)
    - deathanatos 8y ago
      > ssh-agent protects itself from being accessed by the same user account (via the debugging APIs) by being setgid to group ssh I don't think this is correct. ssh-agent typically will be run under your user/group; it shouldn't have the necessary privileges to setgid to ssh. Further, I have ssh-agent running on a machine, and it is still my gid. Last, that machine doesn't even have an "ssh" group. Rather, I think ssh-agent likely protects itself from being debugged (ptrace'd) by ptrace'ing itself. My understanding is that a process can only be ptraced by one process at a time, and by ptrace'ing yourself, you deny the ability for anything else to attach to you. For example, my uid & gid: » printf '%s,%s\n' "$(id -u)" "$(id -g)" 1000,1000 ssh-agent running as those: » ps -eo pid,uid,gid,args | grep ssh-agent 16438 1000 1000 ssh-agent but not debuggable: » strace -p 16438 strace: attach: ptrace(PTRACE_SEIZE, 16438): Operation not permitted Perhaps this is just my machine however, and if I did have a `ssh` group, and I were a member of it, it would setgid to it. I don't think that's foolproof, however: something running under your uid could kill ssh-agent, and restart it under a debugger, skip or elide the setgid() and ptrace() calls, then continue to allow it to execute normally, and now be attached as a debugger. I'm also not sure if ptrace()'ing yourself prevents you from reading out the process's memory from /proc. Edit: so, on Linux, it seems this is what it does[1]: prctl(PR_SET_DUMPABLE, 0) That makes the process "undumpable", which means it won't leave behind core files, /proc/pid is root:root, and it can't be ptrace()'d. I still think the caveat about starting it under a debugger applies, but that certainly makes it less trivial. [1]: https://github.com/openssh/openssh-portable/blob/5ee3fb5affd7646f141749483205ade5fc54adaf/platform-tracing.c#L38 https://github.com/openssh/openssh-portable/blob/5ee3fb5affd...

ropnop 8y ago

Yep, you're correct. Not a vulnerability or an exploit. It's always going to be possible with the right privileges, I was just wanted to see and show the "how"