Bug 65584 - Disable resolution of X-forwarded-for
Summary: Disable resolution of X-forwarded-for
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_remoteip (show other bugs)
Version: 2.4.52
Hardware: PC Linux
: P2 major with 9 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-20 11:03 UTC by v.truong
Modified: 2023-03-28 09:49 UTC (History)
0 users



Attachments
DNS in XFF header (23.89 KB, image/png)
2021-09-20 11:03 UTC, v.truong
Details

Note You need to log in before you can comment on or make changes to this bug.
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.