COMMAND

    netscape

SYSTEMS AFFECTED

    UNIX only

PROBLEM

    Tymm Twillman  found following.   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.

    This was tested this on Linux with Netscape versions 4.51 and 4.7;
    others have  confirmed that  Solaris versions  behave the  same...
    Chon-Chon Tang tested this on Linux 2.0.34, Netscape  Communicator
    4.61 and the same problem exists.  Apparently Mac/Windows versions
    just  display  the  characters  instead  of  using  them  as   tag
    delimiters.   Netscape 4.08  for Wintel  is immune  to this, as is
    I.E. 5 however Netscape 4.6 for Solaris succombs to it.  Confirmed
    on Communicator 4.7/Solaris 2.7 (SPARC),  as well.  This works  on
    FreeBSD  with  4.6  too   but:  only  with  (default)   iso-8859-1
    encoding.  It doesn't work if the page has different codepage, for
    example iso-8859-2 or iso8859-15 or koi8-r.  So it seems to be the
    problem with Netscape translation  table for this codepage.   Lynx
    is immune  as well.  Long live  lynx!   The default  netscape with
    RH5.2  (4.08),  and  glibc  Netscape  4.61  for  linux  are   both
    vulnerable.  Netscape 4.04, 4.07, 4.51, and 4.6 under solaris  are
    all vulnerable.  Netscape 3.03 under solaris is *not*  vulnerable.
    Here's a glob of code to show the problem:

        #!/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;

    Run this and point Netscape at the resulting uhoh.html file...

SOLUTION

    It looks like this may  be the result of some  alternate character
    set compatability feature, but it's rather hard to tell...