Caddy: HTTPoxy Vulnerability and Caddy

[Nixtren]

Read https://www.kb.cert.org/vuls/id/797896 an https://httpoxy.org/

This vulnerability may impact for all web servers.

Run 'wget -S --header="Proxy: 1.2.3.4:8080" https://yourdomain.com' for testing. If return something like 'ERROR 403: Forbidden' that mean website is 'safe'.

Original post at https://www.lowendtalk.com/discussion/88058/info-httpoxy-vulnerability-may-impact-to-web-servers

I can confirm this vulnerability exists on Caddy-based environments:

grep HTTP_PROXY info.php
<tr><td class="e">$_SERVER['HTTP_PROXY']</td><td class="v">1.2.3.4:8080</td></tr>

The best solution meanwhile is dropping or blocking the proxy header. I have attempted the following:

127.0.0.1:80 {
        root domains/localhost
        fastcgi / 127.0.0.1:9000 {
                ext .php
                split .php
                index index.php
                env HTTP_PROXY ""
        }
        errors
}

But the issue persists. I have also tried env proxy "" and it does the same. So, how do we strip out a header?

Running Caddy 0.9.0 and PHP 7.0.

[elcore]

go1.6.3 (released 2016/07/17) includes security fixes to the net/http/cgi package and net/http package when used in a CGI environment. This release also adds support for macOS Sierra. See the Go 1.6.3 milestone on our issue tracker for details.

https://golang.org/doc/devel/release.html

It´s fixed :smile:

@mholt do you use Golang 1.6.3 (build server)

[mholt]

Caddy 0.9.0 is built with Go 1.6.3.

Although FastCGI doesn't use Go's built-in transport facilities; I believe it makes a raw socket connection. I'll have to double-check, maybe get this patched in 0.9.1.

[elcore]

Well, I thought we use the built-in transport facilities :cry:

[mholt]

Does PHP even use the HTTP_PROXY env variable to control where to make requests through? Trying to understand the extent of this vulnerability in this context... if the web application is using an environment variable from headers (HTTP_PROXY in this case), that is its own fault, not Caddy's for passing it on to the application. There might not be anything to fix here, except your PHP app.

[abiosoft]

After looking at the source to see how FastCGI is implemented and how environment variables are passed, Caddy (and FastCGI) does not look vulnerable.

If no one else is able to prove otherwise, I think we can close this issue.

[elcore]

@mholt

Does PHP even use the HTTP_PROXY env variable to control where to make requests through? Trying to understand the extent of this vulnerability in this context... if the web application is using an environment variable from headers (HTTP_PROXY in this case), that is its own fault, not Caddy's for passing it on to the application. There might not be anything to fix here, except your PHP app.

http://php.net/ChangeLog-7.php#7.0.9
http://php.net/ChangeLog-5.php#5.6.24

Fixed bug #72573 (HTTP_PROXY is improperly trusted by some PHP libraries and applications).

@abiosoft

After looking at the source to see how FastCGI is implemented and how environment variables are passed, Caddy (and FastCGI) does not look vulnerable.

https://httpoxy.rehmann.co/ --> The service has queried domain.com using httpoxy headers, but received no http_proxy request

[elcore]

UPDATE:

Create a file called httpoxy.php with following content

<?php
if (isset($_SERVER['HTTP_PROXY']) && $_SERVER['HTTP_PROXY'] == 'vulnerable') {
  echo 'Vulnerable!';
}
?>

Run:

curl --header "Proxy: vulnerable" https://example.com/httpoxy.php

Results:

"Vulnerable!" (Ubuntu 16.04 -- non fixed PHP)
"" (Ubuntu 16.04 -- fixed PHP)

PHP Script Source (https://www.lowendtalk.com/discussion/88058/info-httpoxy-vulnerability-may-impact-to-web-servers)

@mholt / @abiosoft

[mholt]

Right, that's an example of a web app that would use a value from the request header to direct an HTTP request.

(Image credit: https://twitter.com/rob_pike/status/617548868641656832)

[elcore]

Right, that's an example of a web app that would use a value from the request header to direct an HTTP request.

I know :smile: -- Should we "disable/remove" the header?

P.S.: Nice GIF :+1:

[Nixtren]

I guess since PHP patched the issue it's no longer needed to disable the header, people just have to update PHP :)

[elcore]

I am just caring about our beloved uses!

[mholt]

Update the broken software instead.

[elcore]

@mholt I am not using it ! To repeat it "I am just caring about our beloved uses!" :smile:

Have a nice day, thank you for Caddy -- I :heart: it

[abiosoft]

If the user chooses to do that then it is not fair if Caddy prevents him/her 😄
And as long as Caddy is not the cause as we have ascertained here, I am fine.