[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e8c26989-e50f-d892-c1cc-2515071132aa@mindrot.org>
Date: Tue, 7 Apr 2026 09:27:13 +1000 (AEST)
From: Damien Miller <djm@...drot.org>
To: Demi Marie Obenour <demiobenour@...il.com>
cc: oss-security@...ts.openwall.com
Subject: Re: Announce: OpenSSH 10.3 released
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.
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
> > 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"
-d
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.
