Bug 65584

Summary:	Disable resolution of X-forwarded-for
Product:	Apache httpd-2	Reporter:	v.truong
Component:	mod_remoteip	Assignee:	Apache HTTPD Bugs Mailing List <bugs>
Status:	NEW ---
Severity:	major
Priority:	P2
Version:	2.4.52
Target Milestone:	---
Hardware:	PC
OS:	Linux
Attachments:	DNS in XFF header

Description v.truong 2021-09-20 11:03:05 UTC

Created attachment 38039 [details]
DNS in XFF header

It was possible during the penetration test to manipulate the application so that it performs a DNS resolution of our choice.
This vulnerability could possibly allow interaction with the internal servers of the application.
For more information, cf. : http://blog.portswigger.net/2015/04/introducing-burp-collaborator.html
Is there anyway to disable the DNS resolution of XFF header, or to allow only IP addresses in this header, or to implement a whitelist with which the application can communicate and block all other interactions?

Comment 1 Rainer Jung 2021-09-20 12:27:42 UTC

I guess this is related to

https://www.mail-archive.com/dev@httpd.apache.org/msg66312.html

where we discussed an attempt to solve it but stranded.

Comment 2 v.truong 2021-09-21 02:38:20 UTC

(In reply to Rainer Jung from comment #1)
> I guess this is related to
> 
> https://www.mail-archive.com/dev@httpd.apache.org/msg66312.html
> 
> where we discussed an attempt to solve it but stranded.

Yes, it is exactly what we are expecting.
It seems that we can't fix it at the moment.

Comment 3 JS 2022-02-25 00:11:55 UTC

I've recently discovered this across various hosts running hpptd between 2.4.6 and 2.4.52. While not causing major issues at this time, it does turn up as an SSRF vulnerability we are unable to resolve on pentests, and there is the heightened possibility of successful DoS attacks due to the extra overhead while httpd issues and waits for a response to the DNS request (particularly if the DNS requests are slow to return for whatever reason, thus holding a thread hostage while it waits to resolve).

The expected functionality is that if HostnameLookups is set to "Off" (which it is by default), there wouldn't be any backend DNS requests regardless. Is there going to be a fix for this at any point?

If a fix is not going to be provided, the documentation for HostnameLookups should be updated at the very least to point out that the expected behavior does not apply when using mod_remoteip and the RemoteIpHeader directive: https://httpd.apache.org/docs/2.4/mod/core.html#hostnamelookups I note the documentation does already reference an exception to the HostnameLookups behavior when using mod_authz_host, so it would make sense to spell out the exception for this as well.