I don't think this is a vulnerability in CGI.pm. The behaviour is according to the HTML4 recommendation. It is more of an IDS vulnerability. http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2 B.2.2 Ampersands in URI attribute values The URI that is constructed when a form is submitted may be used as an anchor-style link (e.g., the href attribute for the A element). Unfortunately, the use of the "&" character to separate form fields interacts with its use in SGML attribute values to delimit character entity references. For example, to use the URI "http://host/?x=1&y=2" as a linking URI, it must be written <A href="http://host/?x=1&y=2"> or <A href="http://host/?x=1&y=2">. We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner. At 10:38 PM 25-02-2002 +0200, SecurITeam BugTraq Monitoring wrote: >Evading IDS detection on CGI attacks > >Vulnerable systems: >CGI.pm > >Not Vulnerable: >ASP, EXE based CGIs, and most other UNIX based CGIs (non CGI.pm) seem to be >immune > >Summary: >CGI.pm seems to have a different behavior from other CGI parsers. As you can >notice from the CGI query structure, every value name pair is separated by >a '&' >sign. It seems that CGIs based on CGI.pm can parse such value name pairs >even if >they are separated by a ';'. The RFC is not very clear on whether '&' and ';' >should be used, but rather refers them both to Reserved characters. The >replacing of '&' and ';' enables launching CGI attacks while evading IDS >detection, because the name value pair breakdown would be done differently. > >For example: >A CGI running under the CGI.pm environment would understand both: >http://host/cgi-bin/test.cgi?a=b&c=d&e=f >And >http://host/cgi-bin/test.cgi?a=b;c=d;e=f >As: >A CGI query to test.cgi, with the names of a, c, d, and their corresponding >values. > >Impact: > >The next step would be to confirm: >1) What IDSes are fooled by this attack? >2) Can this be used to attack other CGI checking mechanisms such as content >filters, etc? >3) Perhaps knowing that the remote CGI is based on CGI.pm is dangerous by >itself? > >Thanks >Noam Rathaus >http://www.SecurITeam.com >http://www.BeyondSecurity.com
This archive was generated by hypermail 2b30 : Wed Feb 27 2002 - 19:44:06 PST