Mitigating the HTTPoxy Vulnerability with Nginx
1–10 of 10 posts
Re: Mitigating the HTTPoxy Vulnerability with Nginx
#2> The vulnerability was mentioned on the NGINX mailing list in July, 2013, by Jonathan Matthews.
Wow, that is long ago. Why isn't this mitigated earlier? The attack is very simple.
Re: Mitigating the HTTPoxy Vulnerability with Nginx
#3> The vulnerability was mentioned on the NGINX mailing list in July, 2013, by Jonathan Matthews. Wow, that is long ago. Why isn't this mitigated earlier? The attack is very simple.
It gets worse
March 2001 - The issue is discovered in libwww-perl and fixed. Reported by Randal L. Schwartz.
Re: Mitigating the HTTPoxy Vulnerability with Nginx
#4There are mentions of Python... Does this affect WSGI applications, in particular, uWSGI?
AFAIK, uWSGI somewhat resembles but doesn't emulate CGI (unlike how FastCGI works), and WSGI application's `environ` parameter isn't related to `os.environ`, so it should be safe. But I may be mistaken here...
Re: Mitigating the HTTPoxy Vulnerability with Nginx
#5There are mentions of Python... Does this affect WSGI applications, in particular, uWSGI? AFAIK, uWSGI somewhat resembles but doesn't emulate CGI (unlike how FastCGI works), and WSGI application's `environ` parameter isn't related to `os.environ`, so it should be safe. But I may be mistaken here...
I don't know about uWSGI, but here is what it says at httproxy.org
----
Python code must be deployed under CGI to be vulnerable. Usually, that’ll mean the vulnerable code will use a CGI handler like wsgiref.handlers.CGIHandler
This is not considered a normal way of deploying Python webapps (most people are using WSGI or FastCGI, both of which are not affected),
Re: Mitigating the HTTPoxy Vulnerability with Nginx
#6NGINX should have really applied for a CVE instead of pretending that they are immune.
Re: Mitigating the HTTPoxy Vulnerability with Nginx
#7NGINX should have really applied for a CVE instead of pretending that they are immune.
But Nginx isn't vulnerable. All Nginx does is proxying the HTTP headers. It is the applications that run behind Nginx that may be vulnerable depending on how they set/use environment variables.
Saying Nginx is vulnerable is like saying that the Linux kernel is vulnerable to heartbleed.
Re: Mitigating the HTTPoxy Vulnerability with Nginx
#8NGINX should have really applied for a CVE instead of pretending that they are immune.
But Nginx isn't vulnerable. All Nginx does is proxying the HTTP headers. It is the applications that run behind Nginx that may be vulnerable depending on how they set/use environment variables. Saying Nginx is vulnerable is like saying that the Linux kernel is vulnerable to heartbleed.
I think the CGI "standard" is to be blamed.
Whoever the f*ck had the briliant idea to alter the environment variables of a server child process through incoming HTTP headers should have his browsers environment variables altered by the servers responses.
Re: Mitigating the HTTPoxy Vulnerability with Nginx
#9There are mentions of Python... Does this affect WSGI applications, in particular, uWSGI? AFAIK, uWSGI somewhat resembles but doesn't emulate CGI (unlike how FastCGI works), and WSGI application's `environ` parameter isn't related to `os.environ`, so it should be safe. But I may be mistaken here...
I don't know about uWSGI, but here is what it says at httproxy.org ---- Python code must be deployed under CGI to be vulnerable. Usually, that’ll mean the vulnerable code will use a CGI handler like wsgiref.handlers.CGIHandler This is not considered a normal way of deploying Python webapps (most people are using WSGI or FastCGI, both of which are not affected),
btw, the reference FastCGI C library libfcgi also alters the environment to emulate legacy CGI and may also be vulnerable (haven't checked).
Re: Mitigating the HTTPoxy Vulnerability with Nginx
#10NGINX should have really applied for a CVE instead of pretending that they are immune.
But Nginx isn't vulnerable. All Nginx does is proxying the HTTP headers. It is the applications that run behind Nginx that may be vulnerable depending on how they set/use environment variables. Saying Nginx is vulnerable is like saying that the Linux kernel is vulnerable to heartbleed.
It's as much to blame by not, within the actual code, refusing to clear PROXY... Apache httpd isn't "vulnerable" either but it still created a code patch that ensures things don't sneak thru as WELL as proving a runtime workaround. Plus, even the nginx mailing list example shows that it's a security issue.