Hacker News Reader

Comment by SamuelAdams | Hacker News Reader

> 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.

View on HN

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.

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.

So Sudo password for example seem to be up there.

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) 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.

Reply on news.ycombinator.com