[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANO=Ty322LOtzmR3Dwi3ZtmKX1TPhyrBUu1xdnnG3BRkDo9_bg@mail.gmail.com>
Date: Mon, 18 Jul 2016 14:27:03 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security <oss-security@...ts.openwall.com>
Subject: Re: A CGI application vulnerability for PHP, Go,
Python and others
On Mon, Jul 18, 2016 at 1:33 PM, Solar Designer <solar@...nwall.com> wrote:
> On Mon, Jul 18, 2016 at 02:23:41PM -0400, Jan Schaumann wrote:
> > Richard Rowe <arch.richard@...il.com> wrote:
> >
> > > The consequence is that an attacker can force a proxy of their choice
> to be
> > > used. This proxy receives the full request for anything sent over HTTP
> > > using a vulnerable client. It can also act in a malicious way to tie up
> > > server resources (a "reverse slowloris").
> >
> > I know you mentioned it on https://httpoxy.org/, but I think it's worth
> > stressing explicitly again: use of HTTPS for all requests made by the
> > application, internal as well as external, defeats this vulnerability
> > (provided certificates are actually verified).
>
> Certificates being actually verified doesn't help against use of this
> trick for host/port scanning or DoS attacks on third-parties. What does
> fully defeat this vulnerability is if the application or library only
> checks a different env var like HTTPS_PROXY for HTTPS connections. So I
> guess whether use of HTTPS fully defeats or partially mitigates the
> issue varies by the application or library invoked from a CGI program.
>
> Alexander
>
More to the point to quote myself:
https://access.redhat.com/security/vulnerabilities/httpoxy
==
Please note that the "Proxy" header is not an official standard header, nor
is it in the provisional header registry. The "Proxy" header should not be
used by any standards compliant applications or clients.
==
Case in point:
http://www.iana.org/assignments/message-headers/message-headers.xhtml
You will note that the "Proxy" header is not there. It's a common
convention to support it, and as it turns out, a bad one (seriously, in
what use case do you want to let a client specify the proxy that a server
then uses to handle outgoing requests?). We also asked several large web
CDN firms to check their logs for the "Proxy" header, and none reported
seeing it used in the wild. Literally the only use case for this header now
is for attackers.
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@...hat.com
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
