Is mailman vulnerable to the httpoxy bug?
https://httpoxy.org/ seems to impact any python program (among many others) that runs under cgi. Does it cause trouble for mailman? What is a reasonable mitigation?
Perry
Perry E. Metzger perry@piermont.com
On Tue, Jul 19, 2016 at 5:10 PM, Perry E. Metzger <perry@piermont.com> wrote:
https://httpoxy.org/ seems to impact any python program (among many others) that runs under cgi. Does it cause trouble for mailman? What is a reasonable mitigation?
If I understand the issue correctly (and admittedly It's kinda a new issue) this only affects proxied HTTP transactions, not HTTPS ones. Most mailman installations should be running HTTPS in order to protect user data, if not now is a good time to do so.
It's worth pointing out that if you are using nginx with mailman that this only affects you if you are using fastcgi. It does not seem to affect you if you are using nginx+uwsgi+mailman.
-Jim P.
On Tue, Jul 19, 2016 at 05:25:00PM -0400, Jim Popovitch wrote:
On Tue, Jul 19, 2016 at 5:10 PM, Perry E. Metzger <perry@piermont.com> wrote:
https://httpoxy.org/ seems to impact any python program (among many others) that runs under cgi. Does it cause trouble for mailman? What is a reasonable mitigation?
If I understand the issue correctly (and admittedly It's kinda a new issue) this only affects proxied HTTP transactions, not HTTPS ones. Most mailman installations should be running HTTPS in order to protect user data, if not now is a good time to do so. I wouldn't say it's new, it was first detected in 2001[1]
It's worth pointing out that if you are using nginx with mailman that this only affects you if you are using fastcgi. It does not seem to affect you if you are using nginx+uwsgi+mailman.
For anyone concerned, I suggest you take a look at [2] to decide what to do. The exploit involves HTTP_PROXY and the fix does depend on what you're using at the server end. Almost all work on the basis of unsetting any Proxy: header as early as possible in request processing.
Good luck
Lesley [1] https://httpoxy.org/#history [2] https://httpoxy.org/#fix-now
-Jim P.
Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/lesleyb%40herlug.org.u...
On Tue, 19 Jul 2016 17:25:00 -0400 Jim Popovitch <jimpop@gmail.com> wrote:
On Tue, Jul 19, 2016 at 5:10 PM, Perry E. Metzger <perry@piermont.com> wrote:
https://httpoxy.org/ seems to impact any python program (among many others) that runs under cgi. Does it cause trouble for mailman? What is a reasonable mitigation?
If I understand the issue correctly (and admittedly It's kinda a new issue) this only affects proxied HTTP transactions, not HTTPS ones.
That is incorrect, so far as I can tell.
Perry
Perry E. Metzger perry@piermont.com
On Fri, Jul 22, 2016 at 11:57 AM, Perry E. Metzger <perry@piermont.com> wrote:
On Tue, 19 Jul 2016 17:25:00 -0400 Jim Popovitch <jimpop@gmail.com> wrote:
On Tue, Jul 19, 2016 at 5:10 PM, Perry E. Metzger <perry@piermont.com> wrote:
https://httpoxy.org/ seems to impact any python program (among many others) that runs under cgi. Does it cause trouble for mailman? What is a reasonable mitigation?
If I understand the issue correctly (and admittedly It's kinda a new issue) this only affects proxied HTTP transactions, not HTTPS ones.
That is incorrect, so far as I can tell.
According to httpoxy.org, HTTPS is not affected by HTTP_PROXY statements.
"And, of course, another defense-in-depth strategy that works is to
use HTTPS for internal requests, not just for securing your site’s
connections to the outside world. Those aren’t affected by HTTP_PROXY."Of course, that's if you are using a very complicated split-mailman setup (web on one system, other parts on other hosts), If not, then what in your httpd.conf is would be proxying? And if nothing is proxying, then why haven't you already disabled proxy statements? Are you running anything else on the mailman server, PHP, etc?
-Jim P.
On 07/19/2016 02:10 PM, Perry E. Metzger wrote:
https://httpoxy.org/ seems to impact any python program (among many others) that runs under cgi. Does it cause trouble for mailman? What is a reasonable mitigation?
I am not an expert on httpoxy at all, but quoting from <https://httpoxy.org/#top>
"httpoxy is a vulnerability for server-side web applications. If you’re not deploying code, you don’t need to worry."
Mailman's web UI serves end user HTML pages. It does not deploy code.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Wed, 20 Jul 2016 12:02:13 -0700 Mark Sapiro <mark@msapiro.net> wrote:
On 07/19/2016 02:10 PM, Perry E. Metzger wrote:
https://httpoxy.org/ seems to impact any python program (among many others) that runs under cgi. Does it cause trouble for mailman? What is a reasonable mitigation?
I am not an expert on httpoxy at all, but quoting from <https://httpoxy.org/#top>
"httpoxy is a vulnerability for server-side web applications. If you’re not deploying code, you don’t need to worry."
Mailman's web UI serves end user HTML pages. It does not deploy code.
Er, it uses CGI scripts, doesn't it? That's what it means to "deploy code" in this context.
Perry
Perry E. Metzger perry@piermont.com
On 07/22/2016 08:55 AM, Perry E. Metzger wrote:
On Wed, 20 Jul 2016 12:02:13 -0700 Mark Sapiro <mark@msapiro.net>
I am not an expert on httpoxy at all, but quoting from <https://httpoxy.org/#top>
"httpoxy is a vulnerability for server-side web applications. If you’re not deploying code, you don’t need to worry."
Mailman's web UI serves end user HTML pages. It does not deploy code.
Er, it uses CGI scripts, doesn't it? That's what it means to "deploy code" in this context.
That's not the way I read it, but if you think that's the case, then you've already decided that Mailman 2.1 is vulnerable depending on the specific web server configuration. 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?".
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Fri, 22 Jul 2016, Mark Sapiro wrote:
That's not the way I read it, but if you think that's the case, then you've already decided that Mailman 2.1 is vulnerable depending on the specific web server configuration. 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?".
As I understand it, even with a potentially vulnerable httpd configuration (i.e. one that uses the HTTP Proxy: header to set the HTTP_PROXY environment variable for CGI scripts) the CGI application needs to make outgoing HTTP requests, and check the HTTP_PROXY env var to see if it should use a proxy to do so to be affected by httpoxy.
I'm not aware of Mailman 2.1 doing this. If that is correct, then httpoxy shouldn't cause problems for us.
Best, Jack
On Fri, 22 Jul 2016 09:48:34 -0700 Mark Sapiro <mark@msapiro.net> wrote:
On 07/22/2016 08:55 AM, Perry E. Metzger wrote:
On Wed, 20 Jul 2016 12:02:13 -0700 Mark Sapiro <mark@msapiro.net>
I am not an expert on httpoxy at all, but quoting from <https://httpoxy.org/#top>
"httpoxy is a vulnerability for server-side web applications. If you’re not deploying code, you don’t need to worry."
Mailman's web UI serves end user HTML pages. It does not deploy code.
Er, it uses CGI scripts, doesn't it? That's what it means to "deploy code" in this context.
That's not the way I read it,
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.
but if you think that's the case, then you've already decided that Mailman 2.1 is vulnerable depending on the specific web server configuration.
I don't know. I don't know if Mailman uses any of the vulnerable routines that might cause HTTP_PROXY being set to cause trouble.
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.
Perry
Perry E. Metzger perry@piermont.com
On 7/22/16 6:39 PM, Perry E. Metzger 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.
And Mailman 2.1's CGIs will do absolutely nothing with an HTTP_PROXY environment variable. They won't look for it even if it's there. They look at things like query strings and POST data to determine what to do and then they write HTML to stdout.
I don't know. I don't know if Mailman uses any of the vulnerable routines that might cause HTTP_PROXY being set to cause trouble.
Mailman 2.1 uses the Python cgi module and uses only cgi.FieldStorage() to retrieve POST data and query fragments.
It uses nothing other than writes to stdout to send any kind of output.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Fri, 22 Jul 2016 19:59:45 -0700 Mark Sapiro <mark@msapiro.net> wrote:
And Mailman 2.1's CGIs will do absolutely nothing with an HTTP_PROXY environment variable. They won't look for it even if it's there. They look at things like query strings and POST data to determine what to do and then they write HTML to stdout.
Well, there are implicit things that use HTTP_PROXY. If mailman makes any http requests itself, or calls anything that does, it might cause trouble that it is in the environment. I take it that this is *not* the case?
(The problem is not that cgi scripts explicitly look at HTTP_PROXY, it is that many things *implicitly* look at it.)
Perry
Perry E. Metzger perry@piermont.com
On 7/23/16 8:19 AM, Perry E. Metzger wrote:
Well, there are implicit things that use HTTP_PROXY. If mailman makes any http requests itself, or calls anything that does, it might cause trouble that it is in the environment. I take it that this is *not* the case?
Yes. That is not the case. In more than one post in this thread it has been affirmed that no Mailman 2.1 CGI issues any kind of HTTP request. They only write HTML to stdout. You can find the code at <http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/files/head:/Mailman/Cgi/> if you wish to verify this for yourself.
And, as also has been posted more than once, Mailman 3's web UI components, Postorius and HyperKitty, are Django WSGI applications, not CGIs at all.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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
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
Perry E. Metzger writes:
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.
Note that in my post, my three sentences above were one paragraph. So I wasn't misinterpreting after all. I know you're trying to help, but this is just FUD. The same is true for the WGSI applications. "Pure" WSGI applications like Postorius and HyperKitty don't use CGIhandler.
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).
Sure, but that is covered by Mark's point that it's the rest of the webserver configuration that site admins should worry about.
If you want to do people a favor, explain the necessary configuration magic for the webservers you use. That will protect them, both Mailman from the vanishing probability that there's something in Mailman that makes HTTP requests that we don't know about, as well as any other CGI applications that they happen to run.
participants (6)
-
'lesleyb' -
Jack Hill -
Jim Popovitch -
Mark Sapiro -
Perry E. Metzger -
Stephen J. Turnbull