Race condition in sshd

[Georgi Chulkov]

On Friday 11 July 2008 02:55:44 Damien Miller wrote:
> On Fri, 11 Jul 2008, Georgi Chulkov wrote:
> > Hello,
> >
> > This bug exists in 5.0p1. I apologize that I couldn't test against
> > HEAD.
> >
> > I _believe_ I have found a race condition in sshd. In the v2 protocol,
> > after a connection, the accepting process forks in privsep_preauth().
> > The parent executes monitor_child_preauth() to allow certain privsep
> > requests necessary for authentication. The unprivileged child runs
> > do_ssh2_kex() followed by do_authentication2().
> >
> > I am working on a new KEX algorithm whose primary feature is
> > performance. It is fast enough that do_authentication2() runs
> > _before_ the monitor has a chance to permit the necessary requests
> > (MONITOR_REQ_PWNAM in particular), and therefore authentication fails
> > on the server with:
> >
> > monitor_read: unpermitted request 6
> >
> > Could someone more experienced please look at this?
>
> It looks like there is a race there, but it would be nearly impossible
> to hit with our current KEX methods. File a bug at
> http://bugzilla.mindrot.org so it doesn't get lost.
>
> You can fix the race by setting up a pipe shared between the monitor and
> child, and making the child wait until the monitor end closes, which
> it should do after permitting the monitor calls.

I put the pipe close call at the end of monitor.c:mm_answer_sign(), right 
after the permission for MONITOR_REQ_PWNAM is set to true. But I can't figure 
out where exactly to put the blocking pipe read call. Everything I tried is 
either too early (->authentication doesn't get far enough to permit 
MONITOR_REQ_PWNAM) or too late (->unpermitted request).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080711/23a78cfd/attachment.bin