AW: AW: AuthorizedKeysCommand support added

[Fiedler Roman]

Hi,

> -----Ursprüngliche Nachricht-----
> Von: Damien Miller [mailto:djm at mindrot.org]
> An: Fiedler Roman
> Cc: openssh-unix-dev at mindrot.org
> Betreff: Re: AW: AuthorizedKeysCommand support added
> 
> On Wed, 31 Oct 2012, Fiedler Roman wrote:
> 
> > Hi,
> >
> > Just curious:
> >
> > > ...
> > > The program is executed (directly, not via the shell) with a single
> > > argument of the user being logged in. It produces on stdout zero or more
> > > lines in authorized_keys format. The program must terminate normally
> and
> > > with a zero exit status or its output is disregarded.
> > >
> > > The program is executed as the user being logged in, unless a different
> > > user is specified using AuthorizedKeysCommandUser.
> >
> > Does this allow:
> >
> > * Login as user x
> > * Fork a daemon process to stay alive after logout
> > * Logout
> > * Login again
> > * Let the daemon process running as x attach to the key-fetch-script
> running as x, take over fds, ..
> > * Let key-fetch-script return something nice
> >
> > This would of course only work, if e.g. ptrace-attach to non-children
> > with same UID is allowed, which is OK on older kernels/distros, new
> > ones should block that.
> 
> Well, it would let you break into your own account.

It would let you break in your own account if you just return your keys. Would spread harvoc if any fds from sshd other than stdout are open. I've just looked at the patch and are not quite sure if code might be vulnerable:

You are switching uids before close of fds>STDERR+1. Is it possible to attach to the script between setresuid and closefrom? If kernel allows that, this would give access to all open sshd fds.

To verify, I would have to check the specs or setup a test instance (or do you have one?)

> This is a risk of using
> the target user for the login script, which is something we explicitly
> recommend against.

OK, then documentation is quite important: if I understand it right, the default will be this unsafe mode, unless one uses AuthorizedKeysCommandUser

Roman