Race condition in sshd - openssh

This is a discussion on Race condition in sshd - openssh ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Race condition in sshd

  1. Race condition in sshd

    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?

    Thanks!

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBIdplMMFAGrRS91BsRAj3lAKCSMUx0ooiTO1T+RiOZpg gnkysszwCeNhAT
    a+lk+Z3UpvgJnnsYwy85RA4=
    =JaHA
    -----END PGP SIGNATURE-----


  2. Re: Race condition in sshd

    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
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  3. Re: Race condition in sshd

    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).

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBIdyE2MFAGrRS91BsRArVvAKCS7iPyCRCLTMMFUcQmgl VyONEL2ACdFQkZ
    jsfJbclWZTLqZYqOTlBqNOg=
    =EEed
    -----END PGP SIGNATURE-----


  4. Re: Race condition in sshd

    On Friday 11 July 2008 12:00:34 Georgi Chulkov wrote:
    > 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).


    This is now in Bugzilla: https://bugzilla.mindrot.org/show_bug.cgi?id=1487

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBIeJuWMFAGrRS91BsRAl2oAKCsN1VfsbrnqMzLtlIMkz L5YItbwQCgoz3D
    Org8T0TYKOHtdAke9jKZOX4=
    =gh2d
    -----END PGP SIGNATURE-----


+ Reply to Thread