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 only. 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. Brownfox -----Original Message----- From: Jedi/Sector One [mailto:jat_private] Sent: Wednesday, March 13, 2002 1:49 PM To: bugtraqat_private 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 dynamic pages. 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 : url-map "p1" method pattern default 3 match .php 1 match .pl 2 ------------------- VULNERABILITY ------------------- Unlike web servers, ServerIron switches don't 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.serv.er/index.pl http://web.serv.er/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 ------------------- 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 : Order deny,allow Deny from all <Files ~ "\.(html|shtml|jpg|png)$"> Order allow,deny Allow from all </Files> ------------------- VENDOR RESPONSE ------------------- That issue was reported to Foundry Networks support on 12/02/2002 to securityat_private (mail bounced) and supportat_private . 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 firmware version. 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> \/
This archive was generated by hypermail 2b30 : Fri Mar 15 2002 - 14:00:12 PST