[9014] in bugtraq
Re: HTTP REQUEST_METHOD flaw
daemon@ATHENA.MIT.EDU (Kenneth Albanowski)
Sat Jan 9 17:06:33 1999
Date: Fri, 8 Jan 1999 17:00:30 -0500
Reply-To: Kenneth Albanowski <kjahds@kjahds.com>
From: Kenneth Albanowski <kjahds@KJAHDS.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <Pine.BSI.4.05L.9901071558040.20401-100000@cartman.netrail.net>
If I may pipe in, in my opinion this is strictly a failure of the logging
mechanism, and the HTTP implementation (regardless of whether control
characters are allowed or not allowed) is irrelevant. If data is being
logged, that data should be logged unambigously, in a manner suitable for
retrieval, and should be retrieved by an appropriate agent. If the logging
mechanism cannot reliably or safely log some bytes, then something should
be changed (I don't care what) so that those bytes are not logged. Very
simple.
The log format that fails to escape double quotes is a good example of an
ambiguous logging format, and using cat or more (as opposed to less in
non-raw mode) is a good example of using an improper log review mechanism.
(The log is the place where concentrated evil is stored. Why would you
feed that directly to your terminal? Do you know what back doors are in
your terminal emulation code?)
More constructively, how about changing the logging library used here so
that is smart enough to reformat control characters safely and
unambiguously (perhaps ^A => \01, ^B => \02, \ => \\, or something
similar) and if the output of quoted strings is necessary, some method of
telling it to escape the quotes used for a particular string.
However, there is one trick available that can help decode strings with
embedded quotes: if there is only _one_ such string in a block of data,
and the end of the data is known with precision, just scan backwards from
the end for the unambiguous last quote, and forwards from the beginning
for the unambiguous first quote.
--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
