Re: CGI.pm may assist in IDS evasion

[Lincoln Yeoh <lyeoh () pop jaring my>]

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&#38;y=2";> or <A 
href="http://host/?x=1&amp;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