Upcoming OpenSSH vulnerability

[Ben Lindstrom]

> > We've given most vendors since Friday last week until Thursday to get
> > privsep working well for you so that when the announcement comes out
> > next week their customers are immunized.  That is nearly a full week
> > (but they have already wasted a weekend and a Monday).  Really I think
> > this is the best we can hope to do (this thing will eventually leak,
> > at which point the details will be published).
>
> 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.

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

Next track them down and cut their hands off.

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

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


Security releases never go the way you want them to.  I've seen more
fubared released because of expliot leaks in the last 10 years than
anything else.  And it is just as frustrating for us as you.

- Ben