Perry E. Metzger writes:
Er, it uses CGI scripts, doesn't it? That's what it means to "deploy code" in this context.
I can think of several alternative interpretations (such as browser-side Javascript, which was my first take when I read those words -- I haven't looked at the actual documentation).
In this case, it seems to mean "deploying an HTTP client (that makes outgoing HTTP requests) in your CGI script".
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. Mailman (as we distribute it) doesn't make *outgoing* HTTP connections, it sends responses to incoming requests.
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)
Note that the above analysis is completely superficial: it depends on the correctness of the statements by the authors of httpoxy.org. I have not looked at the code.
The belt and suspenders approach would be to remove that variable from the environment at the entry to any Mailman CGI. Of course if something in Mailman or its dependencies depends on correct setting of that variable it will occasion a bug.
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.)
Steve