Vulnerability Development mailing list archives
Re: CGI.pm may assist in IDS evasion
From: Lincoln Yeoh <lyeoh () pop jaring my>
Date: Wed, 27 Feb 2002 13:45:58 +0800
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 valuesThe 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 cannotice 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 ifthey 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
Current thread:
- CGI.pm may assist in IDS evasion SecurITeam BugTraq Monitoring (Feb 25)
- Re: CGI.pm may assist in IDS evasion Lincoln Yeoh (Feb 27)