Dossy,
I agree that the problem is not with AOLserver, wrt reading the log
file, but AOLserver should probably not accept url bytes outside of
the accepted range.
Headers are slightly more difficult to handle. I have a test http
client (htclient) which only accepts context appropriate bytes. For
IOW, fix the consumer (where the real bug is), not every producer.
On 13/09/2010 2:16 PM, Dossy Shiobara wrote:
Actually, someone made the point -- what if you log request *headers*
and someone puts a malicious byte sequence in that header? What's the
rule around escaping the header values?
Actually, someone made the point -- what if you log request *headers*
and someone puts a malicious byte sequence in that header? What's the
rule around escaping the header values? What about every other code
path where a remote user can write unfiltered bytes to a file on the
server (logfile, et
After looking at the URI RFCs (twilight zone), here is a basic
algorithm which should be applied to the request:
1: Unreserved chars should always be unescaped (if they are escaped),
producing a normalized request uri (assuming no #3 illegal chars, this
is what will go into the log file):
unreser
This is not an AOLserver issue to write a log file that is safe for
broken programs. If there are illegal chars in the URL, maybe reject
the request outright. If the chars are legal, then there isn't much
else to be done.
Chances are the chars in question should be escaped in the URL, so the
reque
Fair enough. ;-)
On 9/10/10 2:07 AM, Gustaf Neumann wrote:
> The information loss (changing ESC to the bell character 7) is very
> little;
> under normal operation, you should never have a bell character in the
> log file, and now, if you see one, it should ring a bell
--
Dossy Shiobara
The problem is a very old one, known at least since the
1980ies. There are discussions, whether this qualifies
as a security problem of some software writing to a logfile or
as a problem of the terminal emulators (which it actually is).
IMHO, this discussion is worthless. Some vendors of
webserve
as i said, a quick fix to close the logging exploit.
The information loss (changing ESC to the bell character 7)
is very little;
under normal operation, you should never have a bell
character in the
log file, and now, if you see one, it should ring a bell
the incoming url might be url-en
tl;dr: Yes, this is remotely exploitable.
Longer explanation:
It is if and only if you use a terminal emulator that implements various
exploitable escape sequences *and* cat/tail files that an attacker can
write to, even indirectly, such as webserver access logs.
For various attack vectors, rea
The exploit works like this:
1) Attacker sends HTTP request with ANSI escape sequence embedded in URL
2) Escape sequence is logged to access log.
3) Administrator on web server views log via cat, tail, etc.'
4) Escape sequences are interpreted by terminal emulator.
In the case of extremely braind
Did I read this correctly: this is a remotely exploitable?
Jade
Jade Rubick | Director of Development | TRUiST
2201 Wisconsin Ave NW, Suite 250 | Washington, DC 20007 | www.truist.com | +1
202 903 2564
P Please consider the environment before printing
The information contained in this email/doc
As a short-term solution, this is probably adequate, but there's
information loss -- it'd be nice to indicate the original byte sequence
somehow in the log entry by escaping characters so that log analysis
tools could detect such attacks, etc.
Perhaps the right answer is to log the URI with prope
Hi brian,
i have just now committed a quick fix for the problem into
the aolserver/nslog/nslog.c
into the sourceforge module. please check, if this is in all
cases sufficient.
-gustaf neumann
On 09.09.10 13:32, Fenton, Brian wrote:
Hi all
just came across this when looking for something e
13 matches
Mail list logo
