httpoxy vulnerability

DirectAdmin Support

Staff member
Feb 27, 2003

Apache has released a vulnerability report with regards to the Proxy header.

In short, we just need to filter out the Proxy header from all requests, as it should only be used internally.


I've created this script to help you check if you're affected (which everyone most likely is):

Download it to any website/domain, and run it through your browser.
It will give you a good or bad output.

It makes a call to itself via curl (so make sure your domain works from within your server), and passes the "Proxy" header in the curl call.
The output of that internal call will return "good" or "bad" depending on if the internal call received the Proxy header.

How to fix:

The fix varies per setup, but custombuild can do this for you.
cd /usr/local/directadmin/custombuild
./build update
./build version
./build rewrite_confs

so the configs are updated that filter out the Proxy header.
Note that the change only exists on files1, so the other mirrors may take a few hours before the update.

Ensure that in the "./build version" output, you see "rev 1564" or newer.
rev 1563 does not have the changes in the configs.
If not, you may want to do the fix manually, unless you want to wait for the mirrors to sync up.
If you have CustomBuild 1.1/1.2, manually check the files below to ensure the changes are added, and test with the above testing script.

Verify by running the testing php script again to ensure it says "Good!" in the output.


Manual Fix:

However, if you just want to do this surgically, these are the changes:


and add:
<IfModule mod_headers.c>
        RequestHeader unset Proxy early
to the bottom, and restart httpd, then check again with the above test script.

Nginx & Nginx/proxy

and add this code to the bottom
fastcgi_param HTTP_PROXY "";
and restart nginx, then check again with the above test script.

Is it possible to force a sync in the future? Especially in cases like this it helps if all mirrors are up to date.
They're all pulls from servers we don't manage.
If you want, just use one of ours, eg:
./build set downloadserver
as we have those set to 4 hour rsyncs.
But after you're done, we recommend finding the fastest one again:
./build set_fastest
Thanks for the quick update in the default configs. Everything is patched now without any problems. files6 (amsterdam) is already synced (syncs at GMT +1) :)
What is the priority of this issue? Should I immediately fix it or can it wait a few days?

Whether you are vulnerable depends on your specific application code and PHP libraries, but the problem seems fairly widespread
Just using one of the vulnerable libraries, while processing a user’s request, is exploitable.
If you’re using a vulnerable library, this vulnerability will affect any version of PHP
It even affects alternative PHP runtimes such as HHVM deployed under FastCGI
It is present in Guzzle, Artax, and probably many, many libraries
Guzzle versions after 4.0.0rc2 are vulnerable, Guzzle 3 and below is not.
Another example is in Composer’s StreamContextBuilder utility class

So, for example, if you are using a Drupal module that uses Guzzle 6 and makes an outgoing HTTP request (for example, to check a weather API), you are vulnerable to the request that plugin makes being “httpoxied”.

So if you got a server with clients and you don't know exactly what they got in their code, you'd better run the fix. As you can see a standard CMS could be using something in a simple plugin that is vulnerable.
I've done the manual patch to apache and the script was still showing "Bad..."

Then, I've done the:
cd /usr/local/directadmin/custombuild
./build update
./build version
./build rewrite_confs
and the script still shows "Bad..."

The CB is 2.0.0 (rev: 1564)
Last edited:
If you're running a basic apache setup, confirm you see the mentioned code in the httpd-default.conf file.

Yes, the code is there.

I've tried running the script using https and it showed "Good..." but on refresh it's back to "Bad..."
Might be Firefox cache, but chrome is showing the same.
Another way to check, would be from the command line, eg:
curl 'http://[B][/B]/test_proxy_header.php?check=yes' -H 'Proxy: evil'
where the output will be simpler, just "good" or "bad" (without any newlines, so will likely show up to the left of the next prompt). Not sure beyond that.. unless the httpd process didn't get a full restart.., like "killlall -9 httpd" to nuke it, then start it again.

Another possibility would be if you don't have mod_headers.c in httpd? Check:
/usr/sbin/httpd -l | grep mod_headers
where we should see it listed.

curl check returned "Bad" as well and "mod_headers.c" are present.
I've rebooted the whole system and now it's all good.
I guess the httpd didn't restart fully for some reason.

Thank you all for the help.

Peter, matter of couriousity, how do you update a kernel without reboot without using rebootless external systems?