[Mailman-Users] Is mailman vulnerable to the httpoxy bug?
Stephen J. Turnbull
turnbull.stephen.fw at u.tsukuba.ac.jp
Sat Jul 23 03:36:30 EDT 2016
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
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
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.)
More information about the Mailman-Users