Upcoming OpenSSH vulnerability

[Chris Adams]

Once upon a time, Ben Lindstrom <mouring at etoh.eviladmin.org> said:
> > 1) I've done most of the work getting OpenSSH working on Tru64 Unix, not
> >    any "vendor".  Compaq^WHP doesn't support OpenSSH because they've got
> >    a license for SSH.com's software and make that version available for
> >    free for Tru64 (I don't use it because I prefer OpenSSH).  Telling
> >    them to fix something they not only don't support but supply a
> >    different implementation of is not real bright.
> 
> HP/Compaq uses OpenSSH in their routers and switches.

I really don't think they use Tru64 Unix in their routers and switches,
nor are any of the same people involved.

> > 2) What happened to the interim release on Friday?  I (as everyone is)
> >    am very busy, and allocated my time according to what was said.  I
> >    did submit a patch late Tuesday, but it was not included (hence,
> >    privsep still does not work on Tru64).  There was a "test" release
> >    for a few hours last night (sorry, I guess I'm deficient because I
> >    need sleep).  The following patch is still needed on Tru64 (not
> >    because FD passing is broken but because audit and enhanced security
> >    modes require root in the session setup, and if a PTY is allocated,
> >    the session setup needs to be done after PTY allocation - I don't see
> >    how to make that work with privsep):
> 
> Say thank you to who ever leaked the expliot.

Sorry, I wasn't aware of that.  It would have been nice if that had been
at least mentioned in the release notes or something, since it was a
significant change from the previously announced schedule.

> Next track them down and cut their hands off.

That I would love to do.

> > diff -urN openssh-3.4p1-dist/sshd.c openssh-3.4p1/sshd.c
> > --- openssh-3.4p1-dist/sshd.c	Tue Jun 25 18:24:19 2002
> > +++ openssh-3.4p1/sshd.c	Wed Jun 26 10:42:00 2002
> > @@ -624,7 +624,7 @@
> >  	/* XXX - Remote port forwarding */
> >  	x_authctxt = authctxt;
> >
> > -#ifdef BROKEN_FD_PASSING
> > +#if defined(BROKEN_FD_PASSING) || defined(HAVE_OSF_SIA)
> >  	if (1) {
> 
> No.  Fix Configure.ac.  There is a reason Tim and I agreed on
> that define.  So we don't have to litter the source with more #ifdef
> changes.

Then name the define something else, like "NO_POSTAUTH_PRIVSEP", and
auto-define it if BROKEN_FD_PASSING is defined.  FD passing is not
broken on Tru64 (4.x or 5.x as far as I can tell).  If something else is
added in the future that uses FD passing, it should be supported on
Tru64, so Tru64 should not set BROKEN_FD_PASSING in configure.ac.

> Better yet now we are post 3.4 we need a real solution.

As I said above, I don't see how to do post-auth privsep on Tru64.  The
requirements just don't seem to match the capabilities.  The only thing
I can see to do is to open a PTY unconditionally before post-auth
privsep and close it later if it is not needed (but I don't know for
sure that would work either).  That would be a fairly major change;
would such a change be accepted back into "core" OpenSSH?

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.