Bug 1765606

Summary: [SECURITY] Hiding Server Name HTTP header from Webrick (used in pcs/pcsd)
Product: Red Hat Enterprise Linux 7 Reporter: Ondrej Benes <obenes>
Component: pcsAssignee: Tomas Jelinek <tojeline>
Status: CLOSED ERRATA QA Contact: cluster-qe <cluster-qe>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.6CC: cfeist, cluster-maint, idevat, mlisik, mmazoure, mpospisi, nhostako, nwahl, omular, phagara, tojeline
Target Milestone: rcKeywords: EasyFix
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pcs-0.9.168-3.el7 Doc Type: Bug Fix
Doc Text:
Cause: Pcsd sends the 'Server' HTTP header containing versions of daemon components in every response. Consequence: Attacking pcsd may be easier as exact server components versions are known. Fix: Send an empty Server header. Result: The Server header does not contain names and versions of daemon components.
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-31 19:09:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
proposed fix none

Description Ondrej Benes 2019-10-25 14:46:20 UTC
Description of problem:
When a HTTP request is made against a cluster node running pcsd, the HTTP response contains HTTP Server name in its headers.
This is perceived as a security thread.
This bug report is opened to investigate whether there is a way to hide that header or prevent disclosing the server name in a different way.


Version-Release number of selected component (if applicable):
pcs-0.9.165-6.el7_6.1.x86_64


How reproducible:
Easily, every time.


Steps to Reproduce:
1. Install and start pcsd
2. Send a http request to the node


Actual results:

# curl -vk https://nodename:2224
* About to connect() to nodename port 2224 (#0)
*   Trying 192.168.90.153...
* Connected to nodename (192.168.90.153) port 2224 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* 	subject: CN=nodename,OU=pcsd,O=pcsd,L=Minneapolis,ST=MN,C=US
* 	start date: Sep 25 10:03:20 2019 GMT
* 	expire date: Sep 22 10:03:20 2029 GMT
* 	common name: nodename
* 	issuer: CN=nodename,OU=pcsd,O=pcsd,L=Minneapolis,ST=MN,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: nodename:2224
> Accept: */*
> 
< HTTP/1.1 302 Found 
< Content-Type: text/html;charset=utf-8
< Location: https://nodename:2224/login
< Content-Length: 0
< X-Xss-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Server: WEBrick/1.3.1 (Ruby/2.0.0/2015-12-16) OpenSSL/1.0.2k
< Date: Fri, 25 Oct 2019 13:24:09 GMT
< Connection: Keep-Alive
< Set-Cookie: rack.session=bec79f888bc354cb82abf6ed7da01a884fd76abec3243c4b009496cf97cd9ea9; path=/; expires=Fri, 25 Oct 2019 14:24:09 -0000; secure; HttpOnly
< 
* Connection #0 to host nodename left intact




Expected results:
Following line is obfuscated/nullified/hidden.
< Server: WEBrick/1.3.1 (Ruby/2.0.0/2015-12-16) OpenSSL/1.0.2k


Additional info:

Comment 2 Patrik Hagara 2019-10-25 15:09:15 UTC
For the record, web server implementations can be fingerprinted [1] even if the server obfuscates its version in HTTP headers (eg. different reaction to malformed requests, different ordering of headers, etc.).

[1] https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002)

Comment 3 Tomas Jelinek 2019-10-29 13:54:24 UTC
Created attachment 1630181 [details]
proposed fix

It seems the Server header cannot be deleted. It can be made empty, though.

See comment 0 for the reproducer / test.

Comment 6 Ivan Devat 2019-11-05 08:10:19 UTC
After Fix

[kid76 ~] $ rpm -q pcs
pcs-0.9.168-3.el7.x86_64

[kid76 ~] $ curl -vk https://localhost:2224 2>&1 | grep Server
* Server certificate:
< Server:

Comment 10 errata-xmlrpc 2020-03-31 19:09:41 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0996