Race condition in sshd

Damien Miller djm at mindrot.org
Fri Jul 11 09:55:44 EST 2008


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.

-d


More information about the openssh-unix-dev mailing list