Re: [apps-discuss] Discussion Place for CGI/1.1

[Mark Nottingham <[e-mail]>]

I think at a minimum there needs to be an errata against CGI. 

Also worth a look is RFC3050 and Python's PEP-0333, which may have similar vulnerabilities. 

apps-discuss is probably the right starting place. 

HTTPbis already defers to RFC3864 for field-names, and I think that covers your concerns:
  http://tools.ietf.org/html/rfc3864#section-4.1

Cheers,


On 05/12/2011, at 2:30 PM, Yutaka OIWA wrote:

> Dear experts in apps-discuss and httpbis,
> 
> where should we have talks on CGI/1.1 (RFC 3875), do you think?
> 
> # It may propose a small textual addition to httpbis, depending on the
> # result of discussions.
> 
> 
> A long description of topic is:
> 
> I heard of some Japanese discussion on the interfaces and its side-effect
> of HTTP/1.1 and CGI/1.1 (RFC 3875, Informational).  It was a security issue,
> but the problem itself was not a very interesting thing in context of IETF and a
> workaround has been taken, so I'm not in scramble.
> 
> When I heard of that, I read RFC 3875.  It translates the names of HTTP headers
> to environmental variable names (called in a different name in the spec) in the
> following fashion: make it upper-case, replace all hyphens by underscores and
> then prepend with "HTTP_".  The original author of CGI spec seems to be defining
> the rule as translating "proper" HTTP names (e.g. Forwarded-for) into a
> Unix-like good-looking environment variable name (HTTP_FORWARDED_FOR).
> 
> However, HTTP/1.1 allows so many "weired" characters in tokens, and the header
> names are defined as tokens.  So, "X`Y'Z!" is a valid name for an HTTP header.
> Under the current CGI spec, this weired name will result to "HTTP_X`Y'Z!", which
> is the thing many people probably think not acceptable for variable name
> (including common Unix shell meta characters).
> 
> Implementations of CGI/1.1 actually translate all special characters to
> underscore, in this example "HTTP_X_Y_Z_".  Some intermediate gateway
> did not expect this behavior, and the combination of these has caused
> header forging (using X.Y.Z to override existing X-Y-Z header.)
> 
> # For curious people: the intermediate was actually a mobile carrier gateway,
> # and the forged header was for a mobile device identifier number.
> # The gateway removes any occurrence of it and added a proper one.
> # Receivers check the source IP address, and if it is in some predefined
> # range, they trust the content of such a header.
> # Yes, it is really a bad idea, but do not claim its badness on me
> # as I know it and it's not my fault :-)
> ## The gateway was aware of the fact that - and _ will be translated to
> ## indistinguishable ones in CGI interface.
> 
> Strictly following the spec, the web server behavior was against RFC 3875.
> However, given the Unix customs and restrictions (which was obviously
> the base of CGI specification), the actually-implemented behavior is
> more-or-less understandable.  So, what should we do?
> 
> Possible solutions are:
>  1) to explicitly allow the behavior of current implementations by
>     appending rules that non-alnum MAY be translated to underscore.
>     By this way, the responsibility will move to the intermediate
>     in this case (it should filter out all like X.Y.Z, X!Y%Z, etc).
> 
>  2) Appending a text that headers with "weired" characters SHOULD be
>     filtered out completely, instead of masking by underscores.
>     Existing server implementations to be changed accordingly.
>     (Actually, CGI/1.1 already allows some protocol-specific
>      filtering of headers, with examples for Authorization-related ones).
> 
>  3) Do nothing.  Servers should pass weired characters as is, and
>     CGI programmers should take care of that.
>     Again, existing server implementations to be changed accordingly,
>     and CGI programmers must be really careful to handle these weired things.
> 
>  4) Do really nothing: CGI is too old technology (!?) :-)
> 
> The solution 1) or 2) may be result as an errata or an update document.
> If either 1) or 2) is a good thing, we may also want httpbis to add
> a text for future header extensions suggesting that non-alnums except hyphens
> are discouraged for any new header specifications.
> 
> Original source of problem description along with deployed workaround is in
> <http://blog.tokumaru.org/2011/11/kddigw_29.html> in Japanese.
> 
> -- 
> Yutaka OIWA, Ph.D.                                       Research Scientist
>                            Research Center for Information Security (RCIS)
>    National Institute of Advanced Industrial Science and Technology (AIST)
>                      Mail addresses: <[e-mail]>, <[e-mail]>
> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/