Bug 1500031

Summary: HTTPD - 400 BAD REQUEST - RFC 2616 HOSTNAME HEADER
Product: Red Hat Enterprise Linux 6 Reporter: Tiago Domingues <tiago>
Component: httpdAssignee: Luboš Uhliarik <luhliari>
Status: CLOSED NOTABUG QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.9CC: luhliari
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-10-10 13:33:39 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:

Description Tiago Domingues 2017-10-09 17:20:45 UTC
Description of problem:
new vesion of httpd demands hostname header giving the following error:
"[error] [client xxx.xxx.xxx.xxx] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23):" 

Version-Release number of selected component (if applicable):
httpd-2.2.15-60.el6

How reproducible:
Update from httpd-2.2.15-59.el6 to httpd-2.2.15-60.el6

Steps to Reproduce:
1. yum update httpd
2. send requests to httpd as:

"GET /monitoring/health.svc HTTP/1.1" = 400 BAD REQUEST

Actual results:
"[error] [client xxx.xxx.xxx.xxx] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23):" 

Expected results:
No error

Additional info:
By just downgrading / rollback to httpd-2.2.15-59.el6 solve the issue!

Comment 2 Tiago Domingues 2017-10-09 18:44:57 UTC
Additional Info on Version: httpd-2.2.15-60.el6.centos.5.x86_64 (August 2017)

Comment 3 Luboš Uhliarik 2017-10-10 09:39:42 UTC
Dear Tiago,

From RFC2616 section 14.23:

   A client MUST include a Host header field in all HTTP/1.1 request
   messages . If the requested URI does not include an Internet host
   name for the service being requested, then the Host header field MUST
   be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
   request message it forwards does contain an appropriate Host header
   field that identifies the service being requested by the proxy. All
   Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
   status code to any HTTP/1.1 request message which lacks a Host header
   field.

I also tried to reproduce your issue with httpd-2.2.15-59.el6 and the behavior is exactly same. 

# rpm -qa httpd
httpd-2.2.15-59.el6.x86_64
# /etc/init.d/httpd start
Starting httpd:                                            [  OK  ]
[root@qeos-175 ~]# telnet localhost 80
Trying ::1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.1 400 Bad Request
Date: Tue, 10 Oct 2017 09:19:12 GMT
Server: Apache/2.2.15 (Red Hat)
Content-Length: 325
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
</body></html>
Connection closed by foreign host.

# tail -n 1 /var/log/httpd/error_log 
[Tue Oct 10 05:19:12 2017] [error] [client ::1] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /

Release .60 is fixing CVE-2016-8743, you can try to set httpd directive HttpProtocolOptions to Unsafe:

HttpProtocolOptions Unsafe

Please see https://httpd.apache.org/docs/2.4/mod/core.html#httpprotocoloptions

Comment 4 Tiago Domingues 2017-10-10 12:47:15 UTC
Hi Lubos,

Thanks for your quick reply, we do have an F5 in front of our HTTPD servers and version 2.2.15.60 is breaking our monitoring calls something that does not happen with version 2.2.15.59 and probably related to the fix CVE-2016-8743 as you just mentioned.

We probably need to change our calls (send string + required host header) or create a specific VH while using the unsafe approach.

Thanks for your time & support
Tiago

Comment 5 Tiago Domingues 2017-10-10 13:05:47 UTC
Just as an addition info from F5:

“Note: HTTP/1.1 requires the Host header to be present in the request but does not require the header to contain a value. If you do not have a specific host name on your server, a value of Host: <space> suffices in most cases. A null value is valid unless the HTTP server requires them for virtual hosting.”

This is the full call:

GET /monitoring/health.svc HTTP/1.1\r\nHost: \r\nConnection: Close\r\n\r\n

It seems .60 fix just strict it.

Thanks again
Tiago

Comment 6 Luboš Uhliarik 2017-10-10 13:33:39 UTC
Hi Tiago,

yes, CVE-2016-8743 changed the way, how whitespace charactes are parsed. You can either use HttpProtocolOptions Unsafe or set Host header to some value.

Since this is not a bug, but feature, I'm closing this bug.

Comment 7 Tiago Domingues 2017-10-10 15:50:37 UTC
Thanks Lubos for the info.