• Type: Bug
    • Status: Help Wanted
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: inets
    • Labels:


      I'm the original researcher on httpoxy.org. I just wanted to reach out to make sure you're aware that this would affect any HTTP client that reads HTTP_PROXY without checking for a CGI environment.

      And also that common CGI implementations are probably going to start refusing to carry a Proxy header into HTTP_PROXY just to make a common library-level mistake less of a security problem. I wonder if you might consider a similar mitigation in mod_cgi (I think this is what Go does at the language level.)

      I should probably stress that inets HTTP Server's CGI handler is likely implementing RFC 3875 perfectly. It's just that when the spec was finalized, in 2003, the issue was already known about and fixed in libwww-perl, and I guess they just didn't notice and make it a special case in the spec (the informal use of HTTP_PROXY predates the spec, but then CGI as a whole goes way back into the early days of the web - I'm leaning toward blaming nobody; just an unfortunate coincidence that has been exploitable for over a decade.)

      Through the DWF, CVE-2016-1000107 has been assigned to the issue of CGI applications running under the http://erlang.org/doc/apps/inets/http_server.html mod_cgi receiving the injected HTTP_PROXY environment variable. (Obviously, you also need to trust it to be vulnerable, but this does not seem uncommon.)

      Please let me know if you have any questions. Sorry if this is the wrong place to report this.




            otp_team_ps Team PS
            dominics Dominic Scheirlinck
            0 Vote for this issue
            2 Start watching this issue