CGI.pm vulnerable to Cross-site Scripting From: obscure <dontreply@eyeonsecurity.org> (EyeonSecurity.org) To: bugtraq@securityfocus.com Date: 2003-07-21 00.06 Advisory Title: CGI.pm vulnerable to Cross-site Scripting. Release Date: July 19 2003 Application: CGI.pm - which is by default included in many common Perl distributions. Platform: Most platforms. Tested on Apache and IIS. Version: CGI.pm Severity: Effects scripts which make use of start_form() Author: Obscure^ [ obscure@eyeonsecurity.org ] Vendor Status: first informed on 30th April 2003 Although the author told EoS that he will be releasing a fix within a week from his last correspondence (May15), no fix is out yet on his website. Web: http://stein.cshl.org/WWW/software/CGI/ http://eyeonsecurity.org/advisories/ Background. (extracted from http://stein.cshl.org/WWW/software/CGI/) This perl 5 library uses objects to create Web fill-out forms on the fly and to parse their contents. It provides a simple interface for parsing and interpreting query strings passed to CGI scripts. However, it also offers a rich set of functions for creating fill-out forms. Instead of remembering the syntax for HTML form elements, you just make a series of perl function calls. An important fringe benefit of this is that the value of the previous query is used to initialize the form, so that the state of the form is preserved from invocation to invocation. . Problem CGI.pm has the ability to create forms by making use of the start_form() function. The developer/perl scripter can also makes use of start_multipart_form() which relies on start_form() and is therefore vulnerable to the same issue. When the action for the form is not specified, it is given the value of $self->url(-absolute=>1,-path=>1) - which means that when the url is something like the following : http://host/script.pl?">some%20text<!--%20 .. the form becomes <form action="http://host/script.pl">some text<!-- " > In such case, it is possible to exploit this issue to launch a Cross Site Scripting attack. Exploit Examples. -- #!/usr/bin/perl # example of exploitable script # use CGI; $q = new CGI; print $q->header; print $q->start_html('CGI.pm XSS'); print $q->start_form(); print $q->end_form(); print $q->end_html; -- Fix. I fixed my CGI.pm by adding the following code at line 1537 $action =~ s/\"/\%22/g; Disclaimer. The information within this document may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any consequences whatsoever arising out of or in connection with the use or spread of this information. Any use of this information lays within the user's responsibility. Feedback. Please send suggestions, updates, and comments to: Eye on Security mail : obscure@eyeonsecurity.org web : http://www.eyeonsecurity.org
The fix for this has been in portage for some time, marked stable.
A recant of sorts. The security report you have below was fixed in 2.9x, but the fix apparently had a bug which merely re-introduced the problem. Soon as CVS is up and working again I have the 3.0 version to post which should fix the fix of the fix.
CGI-3.0 is now in portage.
Thanks for fixing this Michael Cummings. Changing resolution to FIXED
