> This "garbage" is exactly what you allowed to add via crafted request
> (curl -H ... etc). Why you want to allow so?
I don't want to. It was "allowed" until now, as X-Forwarded-For headers were not
deleted by the reverse proxy.
I still think that many people are using Debian and mod_rpaf, and are not
deleting these headers.
Won't you do anything for them ?
> > (so the request has two X-Forwarded-For headers when it arrives
> > on the web front end, one is malicious, one is correct from a trusted
> > source).
> >
> > A workaround could be stripping the previous X-Forwarded-For headers on the
> > reverse proxy, but it shouldn't be necessary.
>
> Usually, you can just ignore X-Forwarded-For, provided by client. This
> case covers typical simple frontend+backend setup.
>
> Of course, this shouldn't be necessary - but it's a good idea to expose
> less headers for modification to client, right?
Agreed. Still, there's a bug, and this "solution" is - a "best practice" but -
only a
workaround to this bug.
My point is:
allright, we should all harden our setups, but:
* many people don't and it shouldn't be necessary for Apache2 to keep running
* there are no words about it in the docs provided by Debian :
/usr/share/doc/libapache2-mod-rpaf/README.Debian
Module configuration is pretty simple, there are only two directives to
set; RPAFenable and RPAFproxy_ips. With the later you can define which
IP's are your frontend proxies that sends the correct X-Forwarded-For
headers. If you do not use the RPAFproxy_ips directive then the module
will not change the remote address of the incoming connection at any
time.
* The bug is exposed by the ipv6 patch which has been applied by Debian.
I cannot reproduce the segfaults with upstream sources.
There is likely to be an issue with upstream code, but the NULL pointer
dereference has been introduced by Debian.
Cheers
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
