4 ms·

> Delete /tmp/framer.txt on affected hosts. Isn’t the correct fix to assume compromise and rotate all SSH keys? I imagine there will be scripts created very qu

> Delete /tmp/framer.txt on affected hosts. Isn’t the correct fix to assume compromise and rotate all SSH keys? I imagine there will be scripts created very quickly to grab this file from any servers, so even if it is deleted soon there is no guarantee someone else has not read it.

saghm 2y ago
I'm not sure I follow. From what I understand, the issue is that literally all of stdin and stdout is potentially leaked to a globally-readable text file. ssh-keys wouldn't normally be part that leaked information (other than if you `cat` your private key, but by that logic, literally any credentials ever stored in a file or potentially even an env var would be equally susceptible). Yes, anyone with ssh access would have access, but nothing about this vulnerability seems to imply it would allow an unauthorized user to gain ssh access. It doesn't sound like this is something with a specific risk of leveraging into ssh access because the only ones who can read the file are the ones with access in the first place, so there's no more reason to suspect that now compared to any other point in time.
- varenc 2y ago
  Agreed. I believe this means just means that the entire contents of your ssh session is available in /tmp/framer.txt. But as long as credentials aren't part of your STDIN/STDOUT, then they shouldn't be leaked. Your ssh private key definitely would never be in there. The server you're connecting to doesn't even know your private key, just the public one.
  - m1keil 2y ago
    So Sudo password for example seem to be up there.
    - saghm 2y ago
      That's an interesting point; I think it might depend on the exact details of how stuff is getting put into that tempfile. It's possible that anything getting read in via "silent mode" (see `-s` in https://ss64.com/bash/read.html https://ss64.com/bash/read.html) might not get put into that file, but given that this was a bug rather than a feature, it would probably be better to check the source code (or try an example with an unpatched version) to be sure.

saghm 2y ago

I'm not sure I follow. From what I understand, the issue is that literally all of stdin and stdout is potentially leaked to a globally-readable text file. ssh-keys wouldn't normally be part that leaked information (other than if you `cat` your private key, but by that logic, literally any credentials ever stored in a file or potentially even an env var would be equally susceptible). Yes, anyone with ssh access would have access, but nothing about this vulnerability seems to imply it would allow an unauthorized user to gain ssh access. It doesn't sound like this is something with a specific risk of leveraging into ssh access because the only ones who can read the file are the ones with access in the first place, so there's no more reason to suspect that now compared to any other point in time.

varenc 2y ago
Agreed. I believe this means just means that the entire contents of your ssh session is available in /tmp/framer.txt. But as long as credentials aren't part of your STDIN/STDOUT, then they shouldn't be leaked. Your ssh private key definitely would never be in there. The server you're connecting to doesn't even know your private key, just the public one.
- m1keil 2y ago
  So Sudo password for example seem to be up there.
  - saghm 2y ago
    That's an interesting point; I think it might depend on the exact details of how stuff is getting put into that tempfile. It's possible that anything getting read in via "silent mode" (see `-s` in https://ss64.com/bash/read.html https://ss64.com/bash/read.html) might not get put into that file, but given that this was a bug rather than a feature, it would probably be better to check the source code (or try an example with an unpatched version) to be sure.