[12153] in bugtraq
Re: Time to update those CGIs again
daemon@ATHENA.MIT.EDU (Chon-Chon Tang)
Wed Oct 6 16:44:56 1999
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.LNX.3.96.991005165049.3437M-100000@weber.lcs.mit.edu>
Date: Tue, 5 Oct 1999 16:51:35 -0400
Reply-To: Chon-Chon Tang <ztang@WEBER.LCS.MIT.EDU>
From: Chon-Chon Tang <ztang@WEBER.LCS.MIT.EDU>
X-To: Tymm Twillman <tymm@COE.MISSOURI.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.SGI.4.05.9910051008450.149247-100000@tiger.coe.missouri.edu>
I just tested this on Linux 2.0.34, Netscape Communicator 4.61 and the
same problem exists.
On Tue, 5 Oct 1999, Tymm Twillman wrote:
> Seems that at least some Unix versions of Netscape treat characters 0x8b
> and 0x9b (NOT the strings "0x8b" and "0x9b" but the characters with these
> ascii values) just like < and > respectively...
>
> This could be a problem for guestbooks/web email/filtering programs which
> remove tags by filtering based on greater/less than characters.
>
> I've tested this on Linux with Netscape versions 4.51 and 4.7; others have
> confirmed that Solaris versions behave the same... Apparently Mac/Windows
> versions just display the characters instead of using them as tag
> delimiters.
>
> Here's a glob of code to show the problem:
>
> --- cut ---
>
> #!/usr/bin/perl
>
> $opentag = chr(0x8b).'a href="http://www.netscape.com"'.chr(0x9b);
> $closetag = chr(0x8b).'/a'.chr(0x9b);
>
> open OUT, '>uhoh.html' || die ("Couldn't open");
>
> print OUT "If this $opentag link $closetag works, it could be bad.";
>
> close OUT;
>
> --- cut --
>
> run this and point Netscape at the resulting uhoh.html file...
>
> It looks like this may be the result of some alternate character set
> compatability feature, but it's rather hard to tell... I have not seen
> this documented anywhere however.
>
> -Tymm
>
