LWN.net Logo

Advertisement

E-Commerce & credit card processing - the Open Source way!

Advertise here

OpenSSH 5.0 released

OpenSSH 5.0 released

Posted Apr 4, 2008 13:29 UTC (Fri) by nhippi (subscriber, #34640)
In reply to: OpenSSH 5.0 released by madscientist
Parent article: OpenSSH 5.0 released

> However, to my mind the real fault here lies with XXX

I think it was rather a unfortunate chain of multiple human errors. Blaming a sigle point
misses the whole point, when fiasco could have been avoided had almost anyone in the chain of
events not done their mistake:

x) confusing ipv4/ipv6 behaviour on socket bind

If someone as experienced as openssh developers fall to this, how many other will/have done
the same mistake? This api does not seem to follow the principle of least surprise.

x) openssh developers creating the bug

Not fully understanding the api you are using is quite common source of security problems.
Requesting an tcp listening socket and then telling X to connect to the ipv4 address via
$DISPLAY might seem reasonable to assume safe when ipv6 doesn't pop into your mind.

x) fedora fixing the bug without realizing the the security implications

Has also happened often before. Especially when dealing with software as critical to security
as openssh, every bug should be considered as a security bug until proven wrong. It is
unfortunate that distributions hold bugfixes in their packages without pushing them upstream..

x) reporting the security bug to debian via inproper channel

For a enduser, finding out the proper way of reporting bugs is hard enough.  Now it requires
even more to find out that there is a separate channel or security issues. Now documentation
might help but most people don't read them anyway. debbugs could support security bugs better
(as it already supports the security tag the user was properly using..)

x) reporting it to wrong upstream contact

Different person than above, but basically the same mistake.

x) Debian security not watching "security" tagged bugs closely.

Presumably caused by lack of manpower.

x) pushing the update to Debian not via the security channel

While it was somewhat reasonable to expect that people before him in buglog had contacted the
upstream properly, A bigger mistake was to upload to unstable directly instead notifying
debian security team to do security uploads to stable and testing.

--

While the specific people have probably learned by now and will not repeat their mistake(s),
new people will join and eventually do similar mistakes. It's quite hard to avoid human
mistakes without same time making contributing inhumanly hard.


(Log in to post comments)

OpenSSH 5.0 released

Posted Apr 4, 2008 15:18 UTC (Fri) by madscientist (subscriber, #16861) [Link]

You're right about all these errors, but you left out the one specific error I called out as
the most egregious one:

x) Red Hat does not report the bug and its fix upstream to OpenSSH back in 2005, when they
found it.

Of course it can be quite difficult to determine whether a bug is a security risk, especially
if that's not how you came across it in the first place.  I certainly don't blame Red Hat for
not recognizing the security implications.  Regardless, however, good community participation
demands that when you find a bug you report it upstream to the developers.  It's true we don't
know for a fact that this was not done, but we can have a reasonable suspicion since there was
no indication of this in the bug report, and the bug was not fixed upstream after all this
time.

OpenSSH 5.0 released

Posted Apr 7, 2008 10:07 UTC (Mon) by dwmw2 (subscriber, #2063) [Link]

madscientist writes:
You're right about all these errors, but you left out the one specific error I called out as the most egregious one:

x) Red Hat does not report the bug and its fix upstream to OpenSSH back in 2005, when they found it.

This is fairly unfortunate, and definitely not Fedora policy. For both selfish and altruistic reasons, we really do try to merge patches upstream as promptly as possible.

OpenSSH is a bit special here, since it seems so hard to get patches merged. It's very unfortunate that we carry so many patches, but after my own experience with bugs/RFEs #1328, #1329 and #1330, for which I've been building my own packages for years and occasionally trying to merge the patches but getting nowhere, I can't really criticise our OpenSSH package maintainer for that.

Looking through the (unfortunately private) bug report in RHEL bugzilla, it seems that it was originally reported to us with the text "Grrr. This is a *known* sshd bug...", which probably made it seem even less necessary for the package maintainer to chase it to the recalcitrant upstream.

Still, maybe this is a good time for us to improve matters by trying to flush all our pending patches to upstream, and for upstream to start being a little more receptive to them.

OpenSSH 5.0 released

Posted Apr 7, 2008 12:06 UTC (Mon) by djm (subscriber, #11651) [Link]

Your commentary is quite misleading: of the three patches you list, only one is a bug (and is
arguably not) - the other two are enhancements. One of these (multiple X11 forwarding) is not
supported by the SSH protocol without hacks, and I have given you quite a reasoned explanation
why we aren't pursuing your approach - that is not unresponsiveness, just a disagreement over
what features should live in the product.

OpenSSH 5.0 released

Posted Apr 7, 2008 12:14 UTC (Mon) by djm (subscriber, #11651) [Link]

I should add that most (all?) of the _bugs_ filed by the Redhat maintainer (Thomas Mraz)
against OpenSSH are closed, mostly because he writes great bug reports and makes his patches
very easy to merge. He is probably the easiest distribution representative to deal with.

OpenSSH 5.0 released

Posted Apr 7, 2008 14:16 UTC (Mon) by dwmw2 (subscriber, #2063) [Link]

I'm sorry; I didn't mean to mislead. I did say "bugs/RFEs", and it was just an example.

Personally, I count the first two as bugs and only the last as an RFE — I do consider the forwarding of X clients to the "wrong" display to be a bug rather than a missing feature, and it isn't so much of a hack to use our own locally-generated MIT-MAGIC-COOKIE to differentiate between clients. I thought your objection was mostly that we have a similar bug with agent forwarding which is harder to fix, and that fixing one but not the other would be inconsistent, even though the agent forwarding bug is much less often an issue (in my experience, never). But this probably isn't the correct forum for that discussion.

I could perhaps have also included bug #1349, but I haven't been carrying that patch in my builds for so long.

Anyway, those are just in my personal builds. The important thing is that we get everything from the distribution(s) properly considered for merging upstream. There are too many patches outstanding for my liking, for whatever reasons.

Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds