On Sat, 23 Jul 2016 16:36:30 +0900 "Stephen J. Turnbull" <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
It works by an attacker inserting an http_proxy header into the headers which it presents to the web server, which are then passed in the HTTP_PROXY environment variable to the CGI script. I think that there aren't many ways to read this.
Erm, here's what the site says:
What can happen if my web application is vulnerable? If a vulnerable HTTP client makes an outgoing HTTP connection, while running in a server-side CGI application,Note the *in a server-side CGI*. AFAICS, we're done: we're safe.
You're misinterpreting. The issue is that some server side systems also use web APIs of various kinds.
Mailman (as we distribute it) doesn't make *outgoing* HTTP connections, it sends responses to incoming requests.
So that makes it invulnerable, yes.
BTW, the Mailman 3 bundled Django applications Postorius and HyperKitty are also apparently safe from this vulnerability even though they make outgoing HTTP connections to the Mailman core, since they are WSGI applications:
wsgi, for example, is not vulnerable, because os.environ is not polluted by CGI data (from http://httpoxy.org)
Well, actually, if you read more, apps using wsgiref.handlers.CGIHandler are (apparently) vulnerable, unless I'm misreading.
GNU Mailman has no control over how you set up your web server to serve Mailman's CGI output, so your question should be "is my web server configuration vulnerable?".
Not entirely, no. You could defend Mailman by interposing code on the http server of course.
I don't understand. If you mean between Mailman and the HTTP server, that's site configuration and Mark's question applies. If you mean in Mailman itself (and the Python modules it calls), I guess you mean the "belt and suspenders" approach? (In fact the RightThang to do there would be to remove all envvars that Mailman itself doesn't depend on, with the same risk of bugs, of course.)
What I meant was that you can do things on the web server side like altering your handling of http_proxy (which is what I did on my web servers as soon as this came out). I would agree that nuking any environment variable that you don't know that you need is probably a good idea in general. It increases safety.
Perry
Perry E. Metzger perry@piermont.com