You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2022/05/18 12:14:00 UTC

CVE-2022-1388

All,

I've been doing some reading about the recently-publicized Big-IP 
vulnerability and I was wondering if httpd is doing the right thing.

According to Randori's analysis[1] of the flaw, there is confusion 
between Apache httpd and Jetty (introduced by Big-IP) as to which 
component is responsible for authentication and authorization.

The root of the problem is that they have two different authentication 
mechanisms for different types of users. It's possible to send a request 
that tells Apache httpd "I will be authenticated by Jetty" and by the 
tie the request gets to Jetty it says "I've already been authenticated". 
This is done using some headers:

   Authorization: Basic YWRtaW46
   X-F5-Auth-Token: 1
   Connection: X-Forwarded-Host, X-F5-Auth-Token

Big-IP uses the X-F5-Auth-Token to tell httpd that Jetty will 
authenticate the request, so it proxies the request through to Jetty. 
But the Connection header causes httpd to strip-out the X-F5-Auth-Token 
header as it's being proxied and then Jetty makes a bad decision with 
the Authorization header.

But I'm wondering about why httpd removes that X-F5-Auth-Token header.

RC 2616[1] says that the Connection header contains headers to remove 
from proxied connections, but:

"
Message headers listed in the Connection header MUST NOT include
end-to-end headers, such as Cache-Control.
"

Section 13.5.1[3] defines hop-by-hop and end-to-end headers:

"
  The following HTTP/1.1 headers are hop-by-hop headers:

       - Connection
       - Keep-Alive
       - Proxy-Authenticate
       - Proxy-Authorization
       - TE
       - Trailers
       - Transfer-Encoding
       - Upgrade

    All other headers defined by HTTP/1.1 are end-to-end headers.
"

Given the above, I believe the interpretation of X-F5-Auth-Token should 
be that it is an end-to-end header, and should therefore NOT be removed 
from the proxied request.

The text does say "All other headers *defined by HTTP/1.1* are 
end-to-end headers" (emphasis mine, of course), and the X-F5-Auth-Token 
header isn't defined by HTTP/1.1 (it's a custom one), but I think the 
definition of specific hop-by-hop headers implies that *all* other 
headers should be considered end-to-end.

Have I missed something in my reading of the spec, or the vulnerability 
report itself?

-chris

[1] https://www.randori.com/blog/vulnerability-analysis-cve-2022-1388/
[2] https://datatracker.ietf.org/doc/html/rfc2616#section-14.10
[3] https://datatracker.ietf.org/doc/html/rfc2616#section-13.5.1

Re: CVE-2022-1388

Posted by Julian Reschke <ju...@gmx.de>.
Am 18.05.2022 um 14:50 schrieb Ruediger Pluem:
>
>
> On 5/18/22 2:31 PM, Eric Covener wrote:
>>> Given the above, I believe the interpretation of X-F5-Auth-Token should
>>> be that it is an end-to-end header, and should therefore NOT be removed
>>> from the proxied request.
>>>
>>> The text does say "All other headers *defined by HTTP/1.1* are
>>> end-to-end headers" (emphasis mine, of course), and the X-F5-Auth-Token
>>> header isn't defined by HTTP/1.1 (it's a custom one), but I think the
>>> definition of specific hop-by-hop headers implies that *all* other
>>> headers should be considered end-to-end.
>>
>> I don't think that interpretation can be squared with e.g.
>>
>> https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.1
>> https://datatracker.ietf.org/doc/html/rfc7230#section-6.1
>>
>
> I get to the same conclusion. The current proxy code does it correctly.

fwiw; you may want to check the new text in


<https://greenbytes.de/tech/webdav/draft-ietf-httpbis-semantics-latest.html#field.connection>

(really very soon to be published as RFC)

Best regards, Julian

Re: CVE-2022-1388

Posted by Ruediger Pluem <rp...@apache.org>.

On 5/18/22 2:31 PM, Eric Covener wrote:
>> Given the above, I believe the interpretation of X-F5-Auth-Token should
>> be that it is an end-to-end header, and should therefore NOT be removed
>> from the proxied request.
>>
>> The text does say "All other headers *defined by HTTP/1.1* are
>> end-to-end headers" (emphasis mine, of course), and the X-F5-Auth-Token
>> header isn't defined by HTTP/1.1 (it's a custom one), but I think the
>> definition of specific hop-by-hop headers implies that *all* other
>> headers should be considered end-to-end.
> 
> I don't think that interpretation can be squared with e.g.
> 
> https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.1
> https://datatracker.ietf.org/doc/html/rfc7230#section-6.1
> 

I get to the same conclusion. The current proxy code does it correctly.

Regards

Rüdiger

Re: CVE-2022-1388

Posted by Christopher Schultz <ch...@christopherschultz.net>.
Eric,

On 5/18/22 08:31, Eric Covener wrote:
>> Given the above, I believe the interpretation of X-F5-Auth-Token should
>> be that it is an end-to-end header, and should therefore NOT be removed
>> from the proxied request.
>>
>> The text does say "All other headers *defined by HTTP/1.1* are
>> end-to-end headers" (emphasis mine, of course), and the X-F5-Auth-Token
>> header isn't defined by HTTP/1.1 (it's a custom one), but I think the
>> definition of specific hop-by-hop headers implies that *all* other
>> headers should be considered end-to-end.
> 
> I don't think that interpretation can be squared with e.g.
> 
> https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.1
> https://datatracker.ietf.org/doc/html/rfc7230#section-6.1

Thanks for those references. So the client /is/ expected to be able to 
tell the proxy that certain headers are hop-by-hop by specifying them in 
the Connection header.

It appears that Big-IP wasn't aware of this and wasn't ensuring that 
headers associated with authentication should always be proxied (perhaps 
by copying inbound header -> outbound header) by overriding httpd's 
spec-compliant default behavior.

Thanks for clearing that up for me.

(I was previously unaware of this nuance of the Connection header. It's 
a pretty important nuance :)

Thanks,
-chris

Re: CVE-2022-1388

Posted by Eric Covener <co...@gmail.com>.
> Given the above, I believe the interpretation of X-F5-Auth-Token should
> be that it is an end-to-end header, and should therefore NOT be removed
> from the proxied request.
>
> The text does say "All other headers *defined by HTTP/1.1* are
> end-to-end headers" (emphasis mine, of course), and the X-F5-Auth-Token
> header isn't defined by HTTP/1.1 (it's a custom one), but I think the
> definition of specific hop-by-hop headers implies that *all* other
> headers should be considered end-to-end.

I don't think that interpretation can be squared with e.g.

https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.1
https://datatracker.ietf.org/doc/html/rfc7230#section-6.1