[12129] in bugtraq
Time to update those CGIs again
daemon@ATHENA.MIT.EDU (Tymm Twillman)
Tue Oct 5 16:08:59 1999
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.SGI.4.05.9910051008450.149247-100000@tiger.coe.missouri.edu>
Date: Tue, 5 Oct 1999 10:50:45 -0500
Reply-To: Tymm Twillman <tymm@COE.MISSOURI.EDU>
From: Tymm Twillman <tymm@COE.MISSOURI.EDU>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
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
