Follow @Openwall on Twitter for new release announcements and other news
[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <77035453-8b86-45f7-a6b9-53ee46296a99@gmail.com>
Date: Sat, 11 Oct 2025 23:50:07 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: oss-security@...ts.openwall.com, David Leadbeater <dgl@....cx>
Subject: Re: Announce: OpenSSH 10.1 released

On 10/7/25 02:04, David Leadbeater wrote:
> On Mon, 6 Oct 2025 at 18:23, Damien Miller <djm@....openbsd.org> wrote:
> [...]
>> Security
>> ========
>>
>> * ssh(1): disallow control characters in usernames passed via the
>>   commandline or expanded using %-sequences from the configuration
>>   file, and disallow \0 characters in ssh:// URIs.
>>
>>   If an ssh(1) commandline was constructed using usernames or URIs
>>   obtained from an untrusted source, and if a ProxyCommand that uses
>>   the %u expansion was configured, then it may be possible for an
>>   attacker to inject shell expressions that may be executed when the
>>   proxy command is started.
>>
>>   We strongly recommend against using untrusted inputs to construct
>>   ssh(1) commandlines.
>>
>>   This change also relaxes the validity checks in one small way:
>>   usernames supplied via the configuration file as literals (i.e.
>>   that have no % expansion characters) are not subject to these
>>   validity checks. This allows usernames that contain arbitrary
>>   characters to be used, but only via configuration files. This is
>>   done on the basis that ssh's configuration is trusted.
>>
>>   This issue was reported by David Leadbeater.
> 
> There was a minor error in the above, it should say %r (remote
> username), not %u (local username).
> 
> It has also now been assigned CVE-2025-61984.
> 
> I thought it was worth expanding on this issue, it is essentially a
> follow up from CVE-2023-51385, where if a user clones a git repo or
> otherwise performs another action that passes an attacker controlled
> string to SSH, it could be passed through to the user configured
> ProxyCommand. i.e. it needs both a user action and a particular user
> configuration.
> 
> The ProxyCommand is run through "exec %s" passed to the user's $SHELL.
> One may think that given it is "exec" that it's not possible to run
> another command after it, but bash will ignore the line if it fails
> for certain syntax errors, and it is possible to pass something like:
> "$[+]", an invalid arithmetical expression.
> 
> The proof of concept is therefore a Git repo with a submodule (in
> .gitmodules) like so:
> 
> [submodule "foo"]
>         path = foo
>         url = "$[+]\nsource poc.sh\n@....example.com:foo"
> 
> Combined with a ~/.ssh/config configured with something like this:
> 
> Host *.example.com
>         ProxyCommand some-command %r@%h:%p
> 
> Then on cloning the git repo with "git clone --recursive" the "poc.sh"
> in it will be sourced.

Would it make sense to only allow ASCII characters that are not special
to the shell?  I think Git should enforce this restriction, as such
usernames are very risky and unlikely in legitimate use-cases.  OpenSSH
enforcing this would be even better.

> It is also worth pointing out that a mitigation (and defence for
> future similar issues) is to stop git from cloning repositories over
> SSH for submodules, this can be done with:
> 
>    git config --global protocol.ssh.allow user

This should be the default, as SSH is authenticated and the clone could
have CSRF-like side-effects.

> There are some potential other vectors than git, so that is not a
> complete mitigation, but git is one of the most common vectors and
> this configuration option follows the advice in the release notes of
> not "using untrusted inputs to construct ssh(1) commandlines".
> 
> I've put a more complete write up at
> https://dgl.cx/2025/10/bash-a-newline-ssh-proxycommand-cve-2025-61984
> (attached here in markdown for the archives). In particular I think
> this shell behaviour is quite interesting and may be worth looking out
> for in other tools.
> 
> David

Would it make sense to provide an option to quote shell metacharacters
when expanding, or to simply forbid them outright?  The latter would be
a complete solution.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.