bugtraq - Re: ISA Server 2004 Log Manipulation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <200605090321.k493LXoE021230@cairo.mitre.org>
Date: Mon, 8 May 2006 23:21:33 -0400 (EDT)
From: "Steven M. Christey" <coley@...re.org>
To: beSIRT@...ondsecurity.com
Cc: bugtraq@...urityfocus.com
Subject: Re: ISA Server 2004 Log Manipulation

>You can insert the 'tab' value and possibly break 3rd party log
>analyzers.

OK, this makes sense - if ISA supports tab-separated format, then tab
is a special character within such a log file, and attackers should be
prevented from injecting it (by filtering, quoting, whatever...)

>Other interesting characters may be ... a "<" character for CSS, and
>whatever else your heart desires.

This is a bit more difficult.

Are you saying that there's a web interface or static HTML reports,
provided by ISA, that don't handle "<" characters when they are
processing ISA log files?  Then I would view it as a vuln in the web
interface or HTML page generator.

Are you saying that ISA should protect against all possible XSS
attacks that might be launched against third-party or external
applications that might happen to have XSS issues when they parse log
files from ISA?  If so - then I don't think that should be ISA's
responsibility.

How might one handle this?  To protect against XSS, you could quote
the "<" to be "&lt;" - but then, your quoting has just allowed the
attacker to exploit shell metacharacter vulnerabilities in any
applications that process the log file.  Well, you could remove the
"<" completely - but then you've mis-represented the actual inputs
that the attacker provided, hampering possible forensics activities.

I don't think it should be one application's responsibility to protect
against all the possible attacks that could be launched against
third-party products that happen to parse the original application's
output - unless either the application's core functionality is to
protect against such an attack (e.g. an anti-virus product that sits
between the Internet and a desktop machine).

More to the point - I don't think it's *possible* for one application
to protect against all the ways that its own outputs could be
mis-interpreted by other downstream products that are outside of its
own control.  A gray area occurs with interaction errors between two
products that function correctly when separate, but somehow have
issues when they work together - but this is rarely encountered.

Sorry if this was not what you originally meant - but it's a useful
point of discussion, regardless :)

- Steve