[12164] in bugtraq
Re: Time to update those CGIs again
daemon@ATHENA.MIT.EDU (Leif Sawyer)
Fri Oct 8 16:06:24 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <BF9651D8732ED311A61D00105A9CA3155EBE48@berkeley.gci.com>
Date: Wed, 6 Oct 1999 14:11:12 -0800
Reply-To: Leif Sawyer <lsawyer@GCI.COM>
From: Leif Sawyer <lsawyer@GCI.COM>
X-To: Chon-Chon Tang <ztang@WEBER.LCS.MIT.EDU>,
BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
FWIW,
Netscape 4.08 for Wintel is immune to this, as is I.E. 5
however Netscape 4.6 for Solaris succombs to it.
Lynx is immune as well. Long live lynx!
> -----Original Message-----
> From: Chon-Chon Tang [mailto:ztang@WEBER.LCS.MIT.EDU]
> Sent: Tuesday, October 05, 1999 12:52 PM
> To: BUGTRAQ@SECURITYFOCUS.COM
> Subject: Re: Time to update those CGIs again
>
>
> 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
> >
>
