Re: OpenSSH: What went wrong?

[Darren Reed <avalon@coombs.anu.edu.au>]

Theo,
     I think you (and perhaps others) are mistaken about what I'm
expecting here.  When something in the Government fucks up, they
investigate and announce that something will be changed to try and
make sure it doesn't happen again.  I don't expect there to be any
"invetigation", but I was kind of hoping that someone would come
out and say "we're going to do this differently from now on so we
catch more things before they hurt the public."  It sounds to me
like you're saying nothing is going to change in the way the audit
process is applied or in how code goes from idea to integrated for
public use.

     Now, had I large amounts of spare time that weren't doing
other things, maybe I'd feel inclined to audit OpenSSH, but from
what I've seen, the code is not very auditable.  There are large
chunks of it without any comments about what anything does.  Yes,
I know my code in the past has been no better but I've set a
direction for at least myself to follow to ensure that isn't the
case for the future.  It might take me some time to get there, but
by the end the goal is for each section of code to have a clear
purpose and be auditable against that purpose.  As a quick example
of my problem, ssh.c:ssh_session().  What is it meant to do?  What
does it do?  Does it do what's intended?  How do you tell?  Is it
allowed to return 0xa5a5a5a5?  Others have minimal comments which
say very little and do nothing to make the task of auditting easier.

     I guess what I'm looking for is some amount of pompous words
like those from Bill Gates about how there was a feature-freeze and
everyone there was going into bug-fix mode.  His Bill-ness might be
full of hot air at times like this and people might say it isn't
achieving anything or laugh at him, but you can't say he's not
responding and doing nothing about it.

     Whilst I might not have time to contribute anything in terms
of auditting or writing code, I was kind of hoping that maybe I
would have some ideas worth considering.  That they're rejected off
hand with taunts indicates to me that any assistance from me to the
OpenSSH project in terms of code audits would not be well received.
Nor do I think helping a process which is broken achieves anything.
Even if I auditted all the code overnight, sent you a 10MB set of
diffs, that would not solve what I perceive to be the real problems,
because I get the feeling I would need to do it again, at some future
point in time.  What can I do to help fix *that* problem ?  What can
anyone do that's not in the OpenSSH development team ?  If it was a
journalist (or someone else with no coding experience) asking you the
same questions that I have, would you respond in the same way ?

     One thing I don't see in OpenSSH, which wasn't in OpenBSD either
for a long time, is the idea of "release branches".  I understand that
these can be a lot of work to maintain but maybe it is worth considering
so people can opt to use a version that ages only with patches rather
than new features as well.

Darren

p.s. I'm not trying to tell you what to do, just offer you ideas on how
you might do things differently in the future which you are free to reject
ignore or take up.  I think I'll agree to disagree with you on how well
the current environment/mechanisms work.

From: Theo de Raadt <deraadt@cvs.openbsd.org>
> > In some mail from Theo de Raadt, sie said:
> > [...]
> > > > What situations exist now (vs earlier in the project life) that might have 
> > > > made it easier for something like this to happen?
> > > > Is this a new kind of vulnerability, or a 'standard' one that just got missed?
> > > > How has the management of the project dealt with the issue?
> > > 
> > > This bug was different from a technical standpoint.  It was really
> > > hard to spot.  There were two bugs.  One is that it uses an int off
> > > the network without checking.  But the real bug is an integer
> > > overflow, and noone is looking for those yet.  The code looked safe.
> > [...]
> > 
> > So what are you doing to prevent this sort of thing from reoccuring ?
> 
> We audit continually.  You don't help.
> 
> > What I'd expect, for starters, is quite simply that all "new" code must
> > be audited before a "major" OpenSSH release is made.
> 
> This code has been under development continually, and this bug is old and
> subtle.
> 
> Yet, you don't help.
> 
> > I'd also expect that in an application like OpenSSH is for all inputs to
> > be checked (this one wasn't).  This new code should have been rejected
> > by someone before it got into the CVS tree for OpenSSH because it was
> > missing things like this.
> 
> Where is your help?
> 
> > I don't particularly like the idea that this is a "new type of overflow".
> 
> The real tricky part is arithmetic overflow.
> 
> Wait till you see what u_int vs int and > and < are going to cause.
>
> > What that says to me is that you aren't really auditting software
> > properly if these kinds of things have slipped through previous audits.
> 
> And are you helping?
> 
> > Just for something different, maybe you should get together and have an
> > auditathon rather than a hackathon.
> 
> Why are you telling us to do what we already do, when you don't do any
> of it?
> 
> 
From: Theo de Raadt <deraadt@cvs.openbsd.org>
> > In some mail from Theo de Raadt, sie said:
> > [...]
> > > > What situations exist now (vs earlier in the project life) that might have 
> > > > made it easier for something like this to happen?
> > > > Is this a new kind of vulnerability, or a 'standard' one that just got missed?
> > > > How has the management of the project dealt with the issue?
> > > 
> > > This bug was different from a technical standpoint.  It was really
> > > hard to spot.  There were two bugs.  One is that it uses an int off
> > > the network without checking.  But the real bug is an integer
> > > overflow, and noone is looking for those yet.  The code looked safe.
> > [...]
> > 
> > So what are you doing to prevent this sort of thing from reoccuring ?
> 
> We audit continually.  You don't help.
> 
> > What I'd expect, for starters, is quite simply that all "new" code must
> > be audited before a "major" OpenSSH release is made.
> 
> This code has been under development continually, and this bug is old and
> subtle.
> 
> Yet, you don't help.
> 
> > I'd also expect that in an application like OpenSSH is for all inputs to
> > be checked (this one wasn't).  This new code should have been rejected
> > by someone before it got into the CVS tree for OpenSSH because it was
> > missing things like this.
> 
> Where is your help?
> 
> > I don't particularly like the idea that this is a "new type of overflow".
> 
> The real tricky part is arithmetic overflow.
> 
> Wait till you see what u_int vs int and > and < are going to cause.
> 
> > What that says to me is that you aren't really auditting software
> > properly if these kinds of things have slipped through previous audits.
> 
> And are you helping?
> 
> > Just for something different, maybe you should get together and have an
> > auditathon rather than a hackathon.
> 
> Why are you telling us to do what we already do, when you don't do any
> of it?