Bug 120285

Created attachment 99195 [details]
Patch and spec file for change.

Patch and spec file for change.

A version string of "SSH-1.99-OpenSSH_3.6.1p2-18" doesn't help you audit systems
across a hetrogeneous network - it only helps you if you know that you're
running patch level 18 on Red Hat Enterprise Linux 3 system.  So the patch would
need to include a Red Hat specific identifier, also tied to the product.   The
server would need to return something like "SSH-1.99-OpenSSH_3.6.1p2-rhel3-pl18"
in order for a remote scanner to be able to make a judgement based solely on the
version string of what backported security fixes were included.  

Changing the summary to reflect we won't add this to 2.1.  Please open a new FZ
for RHEL4.

*****************************************************************************
But the patch in question did not report the upstream equivalent version, it was
a change that allowed (as an optional configuration) the openssh server to
report the Red Hat *release* version.
******************************************************************************

If openssh is configured using this optional flag, instead of returning
SSH-1.99-OpenSSH_3.6.1p2 when connected to, it would return
SSH-1.99-OpenSSH_3.6.1p2-33.30.1 and 33.30.1 is the RH release number, which
would be derived automatically during the build process. Looking up what 33.30.1
"means" WRT security patches would still be done the same way as before.

So, in essence this is *not* a request for OpenSSH to report "the upstream
equivalent," which appears to be the concept that was rejected. Rather, it is a
way of reporting the installed RH package version so that Red Hat will fit
seamlessly into BoA's environment/auditing scheme.

Here is the way things would work for BoA if the patch as submitted were
implemented:

With this patch, BoA can tell the auditor:

"All machines that report SSH-1.99-OpenSSH_3.6.1p2-33.30.1 upon a connection to
port 22 are in compliance."

Here is how things work now. The auditor does the scan and then has to ask the
following:

"All machines are reporting SSH-1.99-OpenSSH_3.6.1p2, what version of SSH is
actually installed on each system?"

Then an employee at BoA has to look up each host and provide a report to the
auditor for each machine showing it has the proper patch level. This takes time
and therefore costs them money for something they only see on Red Hat and which
is caused solely because of our packaging decision.

Since the auditors are not allowed access the boxes, solutions like Oval (a
project which seems stalled) or Tenable Security's  Nessus plugin
(http://www.tenablesecurity.com/pr16.html) are not going to work for them (both
of these solutions are intrusive, developmentally immature, and would require
their auditor to change the way they do business).

All they want is for Red Hat to integrate into their environment just like other
OSs do. So far, we are the only vendor they have run into this problem with and
form their perspective, we refuse to address their concern.

The fact is, this patch has little impact on Red Hat, but fixes a big issue for
a major customer (and possibly future customers).

As for the slippery slope argument, I don't think this is the case here. OpenSSH
is unique in that you cannot adjust the banner string reported when a connection
is opened to the server. Other services provide greater flexibility here; for
almost every service I can think of, I can come up with a work around regarding
banner strings.

For OpenSSH the two primary options are:

1> Report the equivalent upstream version (which seems to be the idea actually
rejected in the original feature request).
2> The proposed patch to (optionally) report the RH patch level.

Realistically we do not track upstream completely, so reporting equivalent
upstream version can lead to more problems and confusion. So I understand why
this concept was rejected.

Adding Red Hat release version to the version string is enough to provide
information for customers like BoA. It provides enough information for their
auditor to figure out what security patch level is present on systems being
scanned. So in that sense this patch works to remedy a problem we created.

As for the argument that this is not upstream, well this patch is not required
upstream because the version string is correct in the upstream version.

So, if the filtering question (as Christian suggests) is:

"[Have] we have broken something that was working before, save for our decision
to use backporting?"

The answer is yes.

So this patch would provide an option to offset the change in functionality we
"broke" through our packaging choice with little effort on Red Hat's part.

One final point, from BoA's perspective the current man-hour investment
necessary to clear machines that are deemed out of compliance by their auditor
cannot continue.

If we do not provide them with a solution to the server string issue, then they
will not use our version of OpenSSH and switch instead to a commercial product
called FSecure, and when any peers i the industry asks them why they made this
choice, they will not be telling them how great Red Hat is.

Thanks for your consideration in this matter.

Johnray

But does this really only affect their use of OpenSSH?  I'd have thought if
their auditor is basing security decisions based on returned versions strings
that they'd also be having a problem with sendmail, Apache, mod_ssl, PHP,... and
so on? 

The auditor could solve this and simply insist on having the output of their
remote connection tool along with a locally generated "rpm -qa" list - that
would seem to me to be much more useful as they could then check to make sure
security issues in the underlying libraries and other services have been
addressed.  Example:

What if a flaw in the OpenSSL crypto library was found that could be exploited
via OpenSSH?  We'd fix the OpenSSL shared library but we wouldn't do an update
of OpenSSH.  OpenSSH *even with the proposed patch* would give no information to
help an auditor decide if it was remotely vulnerable to that issue, or not.  It
doesn't matter if the patch reports some upstream patch number or a Red Hat
revision number.  A local 'rpm -qa' list would help.

Mark, I don't think the discussion is whether the customer is doing a full
security audit of the system.  For that matter, the SSH string doesn't tell the
customer whether there is a remote root exploit in the kernel.  The point is
that they have an established automated process for checking SSH version strings
remotely to verify a specific patch level and they can't do this with the way we
report version numbers today.  However, they can with the version numbers
reported by the upstream packages.  So there's no question that this isn't going
to be the complete security blanket for their systems, but it's something that
is needed by their security audit process.

And in reality, they don't need any specific version number, upstream or ours. 
All they need is a unique identifier for each SSH package that we build that
they can tie back to the actual binary.

And to ease the pain of carry a patch upstream, how about we just make the
following change to just the spec file?  The patch provided previously was coded
such that people who didn't want to see the extra information wouldn't.  The
change to the spec file below will mean there's no Red Hat only patch to carry:

mv version.h upstream_version.h
cat upstream_version.h | grep -v SSH_VERSION > version.h
echo "#define SSH_VERSION \""%{version}-%{release}"\"" >> version.h

That patch wouldn't work as it stands, many SSH clients rely on this version
string sent from the server in order to work around specific bugs - it would
have to be appended.  You'd also have to append something to explain the
distribution in use (or the auditor couldn't make a simple numerical comparison
from a range of vulnerable versions).

> they have an established automated process for checking SSH version strings
> remotely

Then their process is flawed - that process does nothing to help the auditor
determine if OpenSSH is or is not vulnerable to a given flaw that could affect
OpenSSH.  Could someone talk to BoA about the specific example of the library
issue in my previous comment and see what they say?  

(I've no objection from a security point of view to us adding optional
versioning information to the end of the SSH version strings, but at the moment
this seems like only benefit to one customer whose requirement is based on a
process that is flawed.)

Customer has been told that Red Hat will not be changing this.

An advisory has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-471.html