Bug 1027592 - Apache ServerToken has fake old(vulnerable) version number of openssl, which can confuse vulnerability scanning service.
Apache ServerToken has fake old(vulnerable) version number of openssl, which ...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: openssl (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-07 02:35 EST by hkoba
Modified: 2013-11-08 04:00 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-08 04:00:02 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description hkoba 2013-11-07 02:35:11 EST
Description of problem:

Recently, I received some vulnerability reports about my httpd(apache)
from Symantec, even though I'm using latest httpd, mod_ssl and openssl.

And I found my apache promotes very old openssl version in HTTP response.


 % curl --silent --head http://localhost/|grep '^Server: '
 Server: Apache/2.4.6 (Fedora) OpenSSL/1.0.0-fips mod_fcgid/2.3.9 mod_wsgi/3.4 Python/2.7.5 mod_perl/2.0.8-dev Perl/v5.16.3
 % 

I verified actual version used by apache, and it is latest.

 # for p in $(pidof =httpd); do
 lsof -p $p 2>/dev/null | grep 'libssl\|libcrypt'
 done|perl -anle 'print $F[-1]'|sort|uniq
 /usr/lib64/libcrypt-2.17.so
 /usr/lib64/libcrypto.so.1.0.1e
 /usr/lib64/libssl.so.1.0.1e
 #


I'm not sure why this version-faking is included in F19 release,
but I think that promoting fake-version in public service can invite
this kind of troubles and could harm Fedora's reputation.

Version-Release number of selected component (if applicable):

httpd-2.4.6-2.fc19.x86_64
mod_ssl-2.4.6-2.fc19.x86_64
openssl-1.0.1e-30.fc19.x86_64


How reproducible:

 % curl --silent --head http://localhost/|perl -nle 'm{ OpenSSL/\S+} and print $&'

Actual results:

 OpenSSL/1.0.0-fips

Expected results:

 OpenSSL 1.0.1e-fips
Comment 1 Jan Kaluža 2013-11-07 03:03:25 EST
I think that's OpenSSL bug. During my testing I've found out it returns proper version with openssl-1.0.1e-4.fc19.x86_64:

Server: Apache/2.4.6 (Fedora) OpenSSL/1.0.1e-fips

But after updating my system to latest openssl-1.0.1e-30.fc19.x86_64, it started returning:

Server: Apache/2.4.6 (Fedora) OpenSSL/1.0.0-fips

Reassigning to openssl.
Comment 2 Jan Kaluža 2013-11-07 03:23:46 EST
Just checked some openssl patches added between those two versions and this one looks like the root of this problem:

http://pkgs.fedoraproject.org/cgit/openssl.git/tree/openssl-1.0.1e-version.patch#n21
Comment 3 Jan Kaluža 2013-11-07 03:26:39 EST
Rebuilding with proper version in this patch shows proper version also in httpd.
Comment 4 Tomas Mraz 2013-11-07 04:38:29 EST
Just rebuilding apache with the openssl-1.0.1e-30.fc19 should help. There is no need to change the patch. The patch was added so the software compiled against the old openssl versions was not confused.
Comment 5 hkoba 2013-11-07 21:50:33 EST
(In reply to Tomas Mraz from comment #4)
> Just rebuilding apache with the openssl-1.0.1e-30.fc19 should help. There is
> no need to change the patch. The patch was added so the software compiled
> against the old openssl versions was not confused.

Does this mean/imply, fedora build servers are using old openssl versions?
Comment 6 Jan Kaluža 2013-11-08 02:08:04 EST
(In reply to Tomas Mraz from comment #4)
> Just rebuilding apache with the openssl-1.0.1e-30.fc19 should help. There is
> no need to change the patch. The patch was added so the software compiled
> against the old openssl versions was not confused.

Rebuilding httpd fixes this issue, but I still think the patch is not right, because packages compiled against old versions apparently *are* confused - showing bad version info at least. If the rebuild is needed, maintainers should be informed.
Comment 7 Tomas Mraz 2013-11-08 04:00:02 EST
They must show the bad version because they expect it.
There are applications which compare the version string they were built against with the string that is returned by the library. If there is difference bigger than patchlevel (the letter after minor version), they bail out. This was the reason the patch was added.

As in Red Hat Enterprise Linux we are often backporting security fixes and not rebasing, having vulnerability scanning software to detect vulnerability by looking at version string is broken anyway.

Note You need to log in before you can comment on or make changes to this bug.