6

OS Ubuntu Ubuntu 16.04.2 LTS Apache/2.4.18 Perl v5.22.1

So I have perl code that reads a mysql database, and then creates a dynamic webpage. The code's been working great for years. A week ago, my client calls and says they are getting a 500 internal server message. I take a look and everything seems fine, but when I try to load the page, I get 500 error. In the apache error log, there's this error:

[Tue May 30 22:16:13.144199 2017] [http:error] [pid 12487] [client 99.99.99.99:55628] AH02429: Response header name '<!-- warning' contains invalid characters, aborting request

Has anyone seen this, or have any idea what is causing it?

chicks
  • 3,639
  • 10
  • 26
  • 36
user3640899
  • 61
  • 1
  • 1
  • 2

4 Answers4

7

You have a key header with invalids characters, it wasn't a problem untill security fix CVE-2016-8743.

https://blog.tigertech.net/posts/apache-cve-2016-8743/

In my case wasApache + PHP and a whitespace before ":" like "X-CUSTOM-KEY :" and I haven't found other solution than changing the header.

GroGz
  • 71
  • 1
  • The thing is, my code doesn't touch the headers. It's currently failing when I have some code in the perl cgi, but I'm not actually executing the code. It's just there, yet it fails. – user3640899 Jun 02 '17 at 00:17
  • 1
    @user3640899 you CGI script surely *DOES* touch the headers, or it would have never worked at all. It must output at least `Content-Type: text/html` HTTP header (usually by `use CGI; print header()`) and it must NEVER output any HTML code or other text *before* that header. So any warning or other output generated by your script will case it to fail in newer apaches. In your example it was HTML comment starting with ` – Matija Nalis Aug 16 '17 at 10:26
2

As @GroGz says, this issue is almost certainly caused (or rather exposed) by the fix to CVE-2016-8743 - the parsing of HTTP headers was made much more strict in an update to Apache released on 20 December 2016 (details at https://httpd.apache.org/security/vulnerabilities_24.html). It's likely your Perl script uses the module CGI::Carp which includes a "warningsToBrowser" subroutine. This subroutine puts warnings triggered by code issues in HTML comments embedded in the output of your program, rather than just logging them to the HTTPD logs. This subroutine is triggered like so:

warningsToBrowser(1);

If you trigger it before the HTTP headers have been sent in their entirety you will see an error similar to the one you describe.

The easy fix is to search your code for any occurrence of:

warningsToBrowser(1);

and change it to:

warningsToBrowser(0);

With this, the warning messages will only be sent to STDERR (like most HTTPD servers, Apache will direct STDERR to the server's error log). Since you say "the code's been working great for years" it's likely the warnings aren't too serious anyway. Check out http://perldoc.perl.org/5.8.9/CGI/Carp.html#MAKING-WARNINGS-APPEAR-AS-HTML-COMMENTS for a bit more information.

1

I had this problem with a buggy java application that was returning a "Location: http://foo.bar\n" (note that \n at the end).

I didn't have access to the application source code to solve the problem, so I had to do a workaround by telling apache to fix the headers using mod_header

The solution was:

      Header edit Location "\n$" ""

I did some tests, created an application that returned a <!-- warning: teste header and solved it on apache with the following directive:

      Header always unset "<!-- warning"

If you can't fix the application, apache can remove/fix the header for you.

Camargo
  • 11
  • 1
-1

The problem results from a empty header list which looks in symfony 1.4 like

array(1) {
 [""] => string(9) "text/html"
}

The problem can be fixed by altering line 357 in lib/response/sfWebResponse.class.php to

foreach ($this->headers as $name => $value)
{
  if($name === "")
    $name = "Content-type";

  header($name.': '.$value);

  [...]

Actually I do not know why no proper name is set but the project is too old to dig into the framework.