openssh and defensive programming (or lack thereof)

[James Ralston]

Before I start, a disclaimer: I've spent (literally) a few weeks
pondering this issue and how to best raise it (where I define "best"
as meaning "most likely to lead to a productive dialog" instead of
"most likely to fill the openssh-unix-dev mailing list with random
flamage").  Despite that, some of what I say will no doubt be
abrasive, or perhaps even offensive.  That's not my intent.  My intent
is to help make openssh a better, more secure software product.

On Wed, 14 Nov 2001, Markus Friedl wrote:

>> ------- Additional Comments From ralston at pobox.com  2001-11-13
>> 15:59 ------- The question is irrelevant; regardless of how one
>> chooses to answer it, the answer does not make sshd's behavior (of
>> not making sure all inherited descriptors are closed) any less
>> broken.
> 
> no, i don't understand. if the program calling sshd breaks because
> sshd does not close fd 142 on startup, then the program is broken.
> it must close its filedescriptors.

Ok, fine.  Let's declare that a startup procedure/program that leaves
descriptors other than [0,1,2] open when it invokes sshd is broken.

But sshd is still broken, regardless of whether the startup
procedure/program is broken.  That is the point I am trying to get
across.

> [daemons] need to make sure to close fd 0-2.  closing 1024 file
> descriptors on startup does not fix bugs, it only fixes symptoms and
> hides the actual bugs.

But this is one of the main ideas of defensive programming: trying to
anticipate what bugs might be in your program (or others' programs),
and coding in such a way that if bugs *are* discovered, their damage
is minimized.

And I'm talking about *bugs in sshd* here.  Any security conscious
program, when starting, should clear file descriptors that it doesn't
need.  There have been several programs, including sendmail, that
could be exploited by opening all but a couple of file descriptors,
and then starting the program and having it die due to an unexpected
shortage of file descriptors.  In some cases, it was possible to turn
this into a root level exploit.

When I originally filed a bug report on this, you closed it with
NOTABUG.  Before you did so, did you conduct an audit of the entire
OpenSSH source tree, and verify that it was impossible for the attack
described above to cause sshd to malfunction, and/or allow privilege
escalation?  Did you?  If you didn't (as I highly suspect), then why
not?

I attended the LISA 2001 conference at the beginning of this month,
and I had lunch with two of the OpenBSD people who were there.
Unfortunately, I don't now remember their names, but they both said
that you were a really great guy, and that you cared a lot about
OpenSSH.  ("OpenSSH is Markus' baby", as one of them put it.)

If this is true, then I challenge you to do the right: FIX THE DAMN
BUG IN SSHD, and just as important, FIX YOUR ATTITUDE.  I can and will
patch the former for you (as I already did, and already offered to
redo), but I can't correct your (apparent) religious opposition to
defensive programming, which will ultimately cause you to create new
bugs in OpenSSH faster than they can be fixed.

(I'll have the reworked patch in a few days, BTW.)

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA