mailing list archives
RE: Foundry Networks ServerIron don't decode URIs
From: Kevin Brown <kevin () kbrownfox net>
Date: Thu, 14 Mar 2002 01:40:23 -0500
I don't believe this qualifies as a security hole. This sounds more like a
bug. It does not create a vulnerability where none existed before. The
product is designed to do load-balancing, not provide security. Therefore,
no user should ever rely on it for security. If a web server gets
compromised because an encoded URL gets passed to it, the problem is with
the web server installation, not a switch that has no implicit or explicit
security policy. The policy it enforces is for load-balancing purposes
This bug does not expose the device itself to a compromise of any kind, and
it is not responsible for creating a vulnerability on a web server where
none existed before. This does not expose your network or any devices on it
to a DoS, a remote-to-local exploit, or a user-to-root compromise.
A quick review of their web site shows no mention of the ServerIron switches
being designed for security purposes.
From: Jedi/Sector One [mailto:j () pureftpd org]
Sent: Wednesday, March 13, 2002 1:49 PM
To: bugtraq () securityfocus com
Subject: Foundry Networks ServerIron don't decode URIs
Date : 13/03/2002 .
By : Frank DENIS <j () 42-networks com>
Vendor : Foundry Networks (http://www.foundrynet.com) .
Product: ServerIron web switches.
Summary: Vulnerability in URI parsing code allows to bypass rules.
------------------- DESCRIPTION -------------------
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.
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
That 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 :
match .php 1
match .pl 2
------------------- VULNERABILITY -------------------
Unlike web servers, ServerIron switches don't decode URIs, and patterns
matched against raw URIs.
For a web server, the following requests are equivalents and match the
same file :
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 -------------------
Don't 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 :
Deny from all
<Files ~ "\.(html|shtml|jpg|png)$">
Allow from all
------------------- VENDOR RESPONSE -------------------
That issue was reported to Foundry Networks support on 12/02/2002 to
security () foundrynet com (mail bounced) and support () foundrynet com .
First answer : do you have a valid support contract?
Second answer, the day after : "This is not a supported feature on our
ServerIron. Please contact our Sales and submit a feature request".
Thanks to another customer, I finally got a phone call from a nice 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
All my mails to Foundry Networks were unanswered since. I don't know
whether an official workaround or fix is on progress. It's not sure that the
URI decoding issue will ever be adressed. So the best way to go is probably
to tell sysadmins that they must check their web servers configurations, and
not rely only on ServerIron url-map filtering.
__ /*- Frank DENIS (Jedi/Sector One) <j () 42-Networks Com> -*\ __
\ '/ <a href="http://www.PureFTPd.Org/"> Secure FTP Server </a> \' /
\/ <a href="http://www.Jedi.Claranet.Fr/"> Misc. free software </a> \/