[NEWS] Vulnerability in URI parsing code of Foundry Networks ServerIron Allows to Bypass Rules

From: support@securiteam.com
Date: 03/16/02 

From: support@securiteam.com
To: list@securiteam.com
Date: Sat, 16 Mar 2002 14:30:23 +0100 (CET)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Vulnerability in URI parsing code of Foundry Networks ServerIron Allows to
Bypass Rules
------------------------------------------------------------------------

SUMMARY

 <http://www.foundrynet.com> Foundry Networks' ServerIron Family of
Internet traffic and content management switches provide high performance
Layer 2 through 7 switching, enabling network managers to control and
manage today's exploding web transaction, web application and eCommerce
traffic flows.

The ServerIron switches do not decode URI's correctly, and thus it is
possible to bypass their rules by encoding URLs.

DETAILS

A key feature of ServerIron switches is that HTTP requests can be balanced
by server groups according to rules. A common configuration is to have a
group of servers for static content, and other groups of servers for
dynamic pages.

This feature is enabled with the "url-map" keyword in ServerIron switching
rules. Several methods are available to select the server group according
to the request, especially the "pattern" method that simply matches
incoming URIs against patterns.

In the following configuration, PHP scripts handled by group #1, Perl
scripts by group #2, and static pages by server group #3 :
url-map "p1"
method pattern
default 3
match .php 1
match .pl 2

However, unlike other web servers, ServerIron switches do not decode URIs,
and patterns are matched against raw URIs.

For a web server, the following requests are equivalents and match the
same file :
  
http://web.example.com/index.pl
http://web.example.com/index.%70%6c

Unfortunately, for ServerIron switches, ".%70%6c" doesn't match ".pl"; the
request will match the next rule and go to the wrong server group.

In the previous configuration, the request will be processed by servers
dedicated to static content. The source code of PHP and Perl scripts may
be sent to the client instead of being processed by expected servers.

Workaround:
Administrators should not trust ServerIron pattern filtering. Duplicate
the ServerIron filtering rules to every web server, by denying everything
by default and allowing only expected patterns.

Sample Apache configuration for a static content server:

Order deny,allow
Deny from all
<Files ~ "\.(html|shtml|jpg|png)$">
 Order allow,deny
 Allow from all
</Files>

Vendor response:
This issue was reported to Foundry Networks support on 12/02/2002 to
security@foundrynet.com (mail bounced) and support@foundrynet.com.
First answer was: "do you have a valid support contract?"
Second answer (the day after) was: "This is not a supported feature on our
ServerIron. Please contact our Sales and submit a feature request".

Finally a phone call was received from a Foundry Networks technical
manager on 19/02. He acknowledged the bug, and said that no URI decoding
was indeed made in ServerIron products, regardless of the firmware
version.

All the mails to Foundry Networks were unanswered since. It is unclear
whether an official workaround or fix is on progress.

ADDITIONAL INFORMATION

The information has been provided by <mailto:j@42-Networks.Com> Frank
DENIS (Jedi/Sector One).

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

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

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

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.