Re: Announce: OpenSSH 10.3 released

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

On 4/6/26 19:27, Damien Miller wrote:
> On Mon, 6 Apr 2026, Demi Marie Obenour wrote:
>
> > > Probably, but this is the essence of the problem as we see it: we can't
> > > know for sure whether this is safe, because we don't can effectively
> > > reason about what shell is in use (and thus what its metacharacters
> > > are) and what the user is doing with these characters in their
> > > configuration file.
> >
> > What about using execve() directly for these commands, rather than a
> > shell?  That would break backwards compatibility for what I suspect to
> > be rare configurations, while fixing most of these injection problems.
>
> People definitely use shell constructs in `Match exec` and `LocalCommand`
> so this would be quite a loss on the client side.

If OpenSSH knew what the shell was, could it quote appropriately?
Presumably most people are using POSIX-compatible shells.

> On the server-side, we already use execve(), but that's not a guarantee
> of safety. As an extreme example, consider
>
> AuthorizedPrincipalsCommand sh -c %u

That is true, but also presumably nobody is doing that :).

> > > It's still possible to shoot youself in the foot with these if you
> > > try hard enough though, e.g. if you've rigged NSS to allow arbitrary
> > > usernames with no character filtering, then there is the potential
> > > for shell injection if the admin has specified token expansion in
> > > a *Command directive.
> >
> > Does NSS generally enforce some sort of validation?
>
> Typically it's configured to perform a lookup in some database (e.g.
> LDAP) and return only users that exist there. These are fine.
>
> Other configurations are possible, e.g. someone might naively create
> a NSS configuration that accepted any username and returned default
> account information for it. sshd isn't the only thing that might have
> problems here. There's probably plenty of other things that would have
> difficulty with getpwnam() returning valid user information for the
> name "../../../../../../etc/shadow"

Good point!
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature