Nginx, Varnish, Cherokee, thttpd, mini-httpd, WEBrick, Orion, AOLserver,Yaws and Boa log escape sequence injection

Name              Nginx, Varnish, Cherokee, thttpd, mini-httpd,

                   WEBrick, Orion, AOLserver, Yaws and Boa log escape

                   sequence injection

Systems Affected  nginx 0.7.64

                   Varnish 2.0.6

                   Cherokee 0.99.30

                   mini_httpd 1.19

                   thttpd 2.25b0

                   WEBrick 1.3.1

                   Orion 2.0.7

                   AOLserver 4.5.1

                   Yaws 1.85

                   Boa 0.94.14rc21

Severity          Medium

Impact (CVSSv2)   Medium 5/10, vector: (AV:N/AC:L/Au:N/C:P/I:N/A:N)

Authors           Giovanni "evilaliv3" Pellerano (evilaliv3 AT ush DOT it)

                   Alessandro "jekil" Tanasi (alessandro AT tanasi DOT it)

                   Francesco "ascii" Ongaro (ascii AT ush DOT it)

Date              20100110

I. BACKGROUND

nginx is a HTTP and reverse proxy server written by Igor Sysoev.

Varnish is a state-of-the-art, high-performance HTTP accelerator.

Cherokee is a very fast, flexible and easy to configure Web Server.

thttpd is a simple, small, portable, fast, and secure HTTP server.

mini_httpd is a small HTTP server.

WEBrick is a Ruby library providing simple HTTP web server services.

Orion Application Server is a pure java application-server.

AOLserver is America Online's Open-Source web server.

Yaws is a HTTP high perfomance 1.1 webserver.

Boa is a single-tasking HTTP server.

II. DESCRIPTION

Nginx, Varnish, Cherokee, thttpd, mini-httpd, WEBrick, Orion, AOLserver,

Yaws and Boa are subject to logs escape sequence injection

vulnerabilites.

Escape sequences are special characters sequences that are used to

instruct the terminal to perform special operations like executing

commands [4, 5] or dumping the buffer to a file [6, 7].

When the webserver is executed in foreground in a pty or when the

logfiles are viewed with tools like "cat" or "tail" such control chars

reach the terminal and are executed.

III. ANALYSIS

Summary:

A) "nginx" log escape sequence injection

   (Affected versions: 0.7.64 and probably earlier versions)

B) "Varnish" log escape sequence injection

   (Affected versions: 2.0.6 and probably earlier versions)

C) "Cherokee" log escape sequence injection

   (Affected versions: 0.99.30 and probably earlier versions)

D) "thttpd" log escape sequence injection

   (Affected versions: thttpd/2.25b and probably earlier versions)

E) "mini_httpd" log escape sequence injection

   (Affected versions: 1.19 and probably earlier versions)

F) "WEBrick" log escape sequence injection

   (Affected versions: 1.3.1 and probably earlier versions)

G) "Orion" log escape sequence injection

   (Affected versions: 2.0.7 and probably earlier versions)

H) "AOLserver" log escape sequence injection

   (Affected versions: 4.5.1 and probably earlier versions)

I) "Yaws" log escape sequence injection

   (Affected versions: 1.85 and probably earlier versions)

L) "Boa" log escape sequence injection

   (Affected versions: 0.94.14rc21 and probably earlier versions)

One of the following two Proofs Of Concept can be used in order to

verify the vulnerability.

echo -en "GET //x1b]2;owned?/x07/x0a/x0d/x0a/x0d" > payload

nc localhost 80 < payload

xterm varnishlog

The following Proof Of Concept can be used in order to verify the

vulnerability.

IV. DETECTION

Services like Shodan (shodan.surtri.com) or Google can be used to get an

approximate idea on the usage of the products.

Some examples:

V. WORKAROUND

Cherokee and WEBrick (Ruby) released related security fixes and releases

as detailed below.

Cherokee issued a public patch that resolved the issue but caused some

better fix that both resolve the issue and doesn't affect the normal

webserver behavior. Use the second patch or a safe release like 0.99.34

or above. If you are using Cherokee 0.99.32 please note that your build

uses the first patch.

Webrick (Ruby) sent us the following patch and issued a release

that fixes the issues. Detailed informations are available at the

following url:

<a href="http://www.ruby-lang.org/en/news/2010/01/10/webrick-escape-sequence-injection">http://www.ruby-lang.org/en/news/2010/01/10/webrick-escape-sequence-injection</a>

The patch we reviewed is the following but please refer to the vendor's

article for exact informations.

--8&lt;--8&lt;--8&lt;--8&lt;--8&lt;--8&lt;--8&lt;--8&lt;--8&lt;--8&lt;--8&lt;--8&lt;--8&lt;--8&lt;--8&lt;--8&lt;--8&lt;--

Index: lib/webrick/httpstatus.rb

===================================================================

--- lib/webrick/httpstatus.rb (revision 26065)

+++ lib/webrick/httpstatus.rb (working copy)

@@ -13,5 +13,15 @@ module WEBrick

   module HTTPStatus

-    class Status      &lt; StandardError; end

+    class Status      &lt; StandardError

+      def initialize(message, *rest)

+        super(AccessLog.escape(message), *rest)

+      end

+      class &lt;&lt; self

+        attr_reader :code, :reason_phrase

+      def code() self::class::code end

+      def reason_phrase() self::class::reason_phrase end

+      alias to_i code

+    end

     class Info        &lt; Status; end

     class Success     &lt; Status; end

@@ -69,4 +79,5 @@ module WEBrick

     StatusMessage.each{|code, message|

+      message.freeze

       var_name = message.gsub(/[ /-]/,'_').upcase

       err_name = message.gsub(/[ /-]/,'')

@@ -80,16 +91,10 @@ module WEBrick

       end

-      eval %-

-        RC_#{var_name} = #{code}

-        class #{err_name} &lt; #{parent}

-          def self.code() RC_#{var_name} end

-          def self.reason_phrase() StatusMessage[code] end

-          def code() self::class::code end

-          def reason_phrase() self::class::reason_phrase end

-          alias to_i code

-        end

-      -

-

-      CodeToError[code] = const_get(err_name)

+      const_set("RC_#{var_name}", code)

+      err_class = Class.new(parent)

+      err_class.instance_variable_set(:@code, code)

+      err_class.instance_variable_set(:@reason_phrase, message)

+      const_set(err_name, err_class)

+      CodeToError[code] = err_class

     }

Index: lib/webrick/httprequest.rb

--- lib/webrick/httprequest.rb (revision 26065)

+++ lib/webrick/httprequest.rb (working copy)

@@ -267,9 +267,5 @@ module WEBrick

         end

-      begin

-        @header = HTTPUtils::parse_header(@raw_header.join)

-      rescue =&gt; ex

-        raise  HTTPStatus::BadRequest, ex.message

-      end

+      @header = HTTPUtils::parse_header(@raw_header.join)

     end

Index: lib/webrick/httputils.rb

--- lib/webrick/httputils.rb (revision 26065)

+++ lib/webrick/httputils.rb (working copy)

@@ -130,9 +130,9 @@ module WEBrick

           value = $1

           unless field

-            raise "bad header '#{line.inspect}'."

+            raise HTTPStatus::BadRequest, "bad header '#{line}'."

           end

           header[field][-1] &lt;&lt; " " &lt;&lt; value

         else

-          raise "bad header '#{line.inspect}'."

+          raise HTTPStatus::BadRequest, "bad header '#{line}'."

       }

Index: lib/webrick/accesslog.rb

--- lib/webrick/accesslog.rb (revision 26065)

+++ lib/webrick/accesslog.rb (working copy)

@@ -54,5 +54,5 @@ module WEBrick

            raise AccessLogError,

              "parameter is required for /"#{spec}/"" unless param

-           params[spec][param] || "-"

+           param = params[spec][param] ? escape(param) : "-"

          when ?t

            params[spec].strftime(param || CLF_TIME_FORMAT)

@@ -60,8 +60,16 @@ module WEBrick

            "%"

          else

-           params[spec]

+           escape(params[spec].to_s)

          end

+

+    def escape(data)

+      if data.tainted?

+        data.gsub(/[[:cntrl:]//]+/) {$&amp;.dump[1...-1]}.untaint

+      else

+        data

   end

end

VI. VENDOR RESPONSE

We contacted the vendors of eleven affected webservers, counting the

WEBrick/Ruby and Jetty), one will not fix the issue (Varnish) and one

acknowledged the issue (AOLserver).

Nginx               NO-RESPONSE

Cherokee           FIXED

thttpd             NO-RESPONSE

mini-httpd         NO-RESPONSE

WEBrick            FIXED

Orion              NO-RESPONSE

AOLserver          ACK

Yaws               NO-RESPONSE

Boa                NO-RESPONSE

Varnish            WONT-FIX

The response was overall good and it was nice to work with them, in

particular we want to thank Cherokee's staff, Ruby's staff, Raphael

Geissert (Debian) and Steven M. Christey (Mitre) for the support.

Poul-Henning Kamp (Varnish) replied to our contact email with the

following email that we quote as-is.

The official Varnish response, which I ask that you include in its

entirety in your advisory, if you list Varnish as "vulnerable" in it:

This is not a security problem in Varnish or any other piece of software

which writes a logfile.

The real problem is the mistaken belief that you can cat(1) a random

logfile to your terminal safely.

This is not a new issue. I first remember the issue with xterm(1)'s

inadvisably implemented escape-sequences in a root-context, brought up

heatedly, in 1988, possibly late 1987, at Copenhagens University

Computer Science dept. (Diku.dk). Since then, nothing much have changed.

The wisdom of terminal-response-escapes in general have been questioned

at regular intervals, but still none of the major terminal emulation

programs have seen fit to discard these sequences, probably in a

misguided attempt at compatibility with no longer used 1970'es

technology.

I admit that listing "found a security hole in all HTTP-related programs

that write logfiles" will look more impressive on a resume, but I think

it is misguided and a sign of trophy-hunting having overtaken common

sense.

Instead of blaming any and all programs which writes logfiles, it would

be much more productive, from a security point of view, to get the

terminal emulation programs to stop doing stupid things, and thus fix

this and other security problems once and for all.

We would like to punctuate the following facts:

1) We totally agree that the root of the problem is an unwise design in

the terminal emulators. If in 70' controls were sent out of band on a

secondary channel we would not have the equivalent of Blue Boxing in the

terminal.

This is a known issue from years. We didn't invented this attack vector

and never claimed so. We don't think that design changes will happen in

the short or mid term so it's better to have a proactive approach and

sanitize outputs where functionalities are likely to not be affected at

all like in this case.

Security in complex systems requires some sinergy.

2) Varnish is the only program that doesn't need a "cat" program as logs

are stored in memory and displayed using the "varnishlog" utility.

2) Apache fixed a similiar bug (CVE-2003-0020), "Low: Error log escape

filtering", in 2004 (six years ago). The bug was affecting Apache up

Take you conclusion, criticize if you want. In the meantime things are a

little safer.

VII. CVE INFORMATION

CVE-2009-4487 nginx 0.7.64

CVE-2009-4488 Varnish 2.0.6

CVE-2009-4489 Cherokee 0.99.30

CVE-2009-4490 mini_httpd 1.19

CVE-2009-4491 thttpd 2.25b0

CVE-2009-4492 WEBrick 1.3.1

CVE-2009-4493 Orion 2.0.7

CVE-2009-4494 AOLserver 4.5.1

CVE-2009-4495 Yaws 1.85

CVE-2009-4496 Boa 0.94.14rc21

VIII. DISCLOSURE TIMELINE

20091117 Bug discovered

20091208 First vendor contact

20091209 Cherokee team confirms vulnerability (Alvaro Lopez Ortega)

20091209 Alvaro Lopez Ortega commits Cherokee patch

20091210 Ruby team confirms vulnerability (Shugo Maeda)

20091211 Shugo Maeda sends us webrick patch for evaulation

20091211 AOLserver confirms vulnerability (Jim Davidson)

20091221 Contacted Raphael Geissert (Debian Security)

20091223 Contacted Steven M. Christey (mitre.org)

20091230 Raphael Geissert forwards to Redhat, Debian, Ubuntu and Mitre

20091230 CVEs assigned by Steven M. Christey

20100105 Poul-Henning (Varnish) Kamp said WONT-FIX

20100105 Ruby team is ready for commit (Urabe Shyouhei)

20100106 Second vendor contact

20100110 Advisory release

IX. REFERENCES

X. CREDIT

Giovanni "evilaliv3" Pellerano, Alessandro "jekil" Tanasi and

Francesco "ascii" Ongaro are credited with the discovery of this

Giovanni "evilaliv3" Pellerano

mail: evilaliv3 AT ush DOT it

Alessandro "jekil" Tanasi

mail: alessandro AT tanasi DOT it

Francesco "ascii" Ongaro

mail: ascii AT ush DOT it

X. LEGAL NOTICES

Copyright (c) 2009 Francesco "ascii" Ongaro

Permission is granted for the redistribution of this alert

electronically. It may not be edited in any way without mine express

written consent. If you wish to reprint the whole or any

part of this alert in any other medium other than electronically,

please email me for permission.

Disclaimer: The information in the advisory is believed to be accurate

at the time of publishing based on currently available information. Use

of the information constitutes acceptance for use in an AS IS condition.

There are no warranties with regard to this information. Neither the

author nor the publisher accepts any liability for any direct, indirect,

or consequential loss or damage arising from use of, or reliance on,

this information.