Authoritative Evidence from Vendor

[duckfez]

Do you have a link to a public statement from OpenSSH team saying they do not intend to fix this at this time? I've checked a few places, and find several references to the OpenSSH team's statement - but they all lead back to your site as the authority.

[cpandya2909]

There is no public statement. This was from the conversation with OpenSSH in email.

[cfi-gb]

hey do not intend to fix this at this time

This could be reviewed again now that https://github.com/openssh/openssh-portable/pull/194 has been merged in https://github.com/openssh/openssh-portable/commit/197e29f1cca190d767c4b2b63a662f9a9e5da0b3

[ldo]

Correct me if I’ve missed something, but the vulnerability is server-side, is it not? The “fix” in OpenSSH 9 involves modifying the scp command to use sftp for file transfers, deprecating the original scp method. But this fix is only done client-side; the server still remains vulnerable to malicious clients forcing the older protocol (or indeed use of the standard client-side scp command with the -O option, conveniently provided for just this purpose!).

A proper fix needs to be done server-side. I don’t know enough about SSH to suggest how, but two obvious techniques come to mind from my own past experience with this sort of problem:

• Don’t spawn a shell, instead invoke the command directly via execve(2) or one of its wrapper calls

• If you have to spawn a shell, pass argument values via environment variables. E.g. if VAR contains some arbitrary string, then passing it to «cmd» via

  «cmd» "$VAR"

  is safe. (Assuming «cmd» can deal safely with the value.)

Depending on the situation, the printf(1) command provided by GNU Coreutils might also be useful in a shell script, since that seems to know how to do correct quoting of shell specials (with printf %q).