Re: Announce: OpenSSH 10.3 released

[Demi Marie Obenour <demiobenour () gmail com>]

On 4/2/26 05:25, Damien Miller wrote:
> OpenSSH 10.3 has just been released. It will be available from the
> mirrors listed at https://www.openssh.com/ shortly.
>
> OpenSSH is a 100% complete SSH protocol 2.0 implementation and
> includes sftp client and server support.
>
> Once again, we would like to thank the OpenSSH community for their
> continued support of the project, especially those who contributed
> code or patches, reported bugs, tested snapshots or donated to the
> project. More information on donations may be found at:
> https://www.openssh.com/donations.html
>
> Potentially-incompatible changes
> --------------------------------
>
>  * ssh(1), sshd(8): remove bug compatibility for implementations
>    that don't support rekeying. If such an implementation tries to
>    interoperate with OpenSSH, it will now eventually fail when the
>    transport needs rekeying.
>
>  * sshd(8): prior to this release, a certificate that had an empty
>    principals section would be treated as matching any principal
>    (i.e. as a wildcard) when used via authorized_keys principals=""
>    option. This was intentional, but created a surprising and
>    potentially risky situation if a CA accidentally issued a
>    certificate with an empty principals section: instead of being
>    useless as one might expect, it could be used to authenticate as
>    any user who trusted the CA via authorized_keys. [Note that this
>    condition did not apply to CAs trusted via the sshd_config(5)
>    TrustedUserCAKeys option.]
>
>    This release treats an empty principals section as never matching
>    any principal, and also fixes interpretation of wildcard
>    characters in certificate principals. Now they are consistently
>    implemented for host certificates and not supported for user
>    certificates.
>
>  * ssh(1): the -J and equivalent -oProxyJump="..." options now
>    validate user and host names for ProxyJump/-J options passed
>    via the command-line (no such validation is performed for this
>    option in configuration files). This prevents shell injection in
>    situations where these were directly exposed to adversarial
>    input, which would have been a terrible idea to begin with.
>    Reported by rabbit.
>
> Changes since OpenSSH 10.2
> ==========================
>
> This release contains some relatively minor security fixes as well
> as a number of feature improvements and general bugfixes.
>
> Security
> ========
>
>  * ssh(1): validation of shell metacharacters in user names supplied
>    on the command-line was performed too late to prevent some
>    situations where they could be expanded from %-tokens in
>    ssh_config. For certain configurations, such as those that use a
>    "%u" token in a "Match exec" block, an attacker who can control
>    the user name passed to ssh(1) could potentially execute arbitrary
>    shell commands.  Reported by Florian Kohnhäuser.
>
>    We continue to recommend against directly exposing ssh(1) and
>    other tools' command-lines to untrusted input. Mitigations such
>    as this can not be absolute given the variety of shells and user
>    configurations in use.

Is it safe (from a shell injection perspective) to pass inputs that are
sanitized for character set, but otherwise untrusted?  For instance,
is it sufficient to limit usernames to ^[A-Za-z][A-Za-z0-9_-]{0,31}$
and domain names to valid host names [1]?

Can one assume that in situations where entries come from an
untrusted source (such as AuthorizedKeysCommand), OpenSSH _does_
do such checking?

[1]: No more than 254 bytes (plus optional trailing '.'), no leading '.',
     each '.'-delimited component must start and end with [a-z0-9], not
     be more than 63 bytes, and only have [a-z0-9-].
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature