Netscape Logic Bomb detailed by IETF

[anonymous-remailer@shell.portal.com]

With all of the Noise on this list, and all of the opinion that has been
expressed, opinion which would seek to slander, misrepresent or opinion
which would like to represent itself as fact, it has increasingly become
difficult to separate the wheat from the chaff. 

Clearly, someone has a vested interest which they are expending a 
great deal of effort to protect.  My email to Netscape detailing their 
logic bomb has gone unanswered, and unacknowledged for ten days now.

Ten days is a long time for no "official" comment.  Just as ten days is a
long time not to answer email.

Rather than attacking individual posters, rather than questioning
credentials, rather than scaring journalists, rather than intimidating and
wilfully spreading misinformation to create confusion, rather than doing
any of this, I will simply quote the official minutes of the Internet
Engineering Task Force (IETF) which is the protocol engineering,
development and standardization arm of the Internet Architecture Board
(IAB).

The IETF is a large open international community of network designers,
operators, vendors, and researchers concerned with the evolution of the
Internet protocol architecture and the smooth operation of the Internet. 

Request-For-Comments are a series of memorandums which act as official 
minutes of the IETF.  Request-For-Comments No. 1521 (RFC-1521) Subsection 
7.4.2 is authoritative and has been reviewed and has received 
international approval.

To avoid the accusation, of misquoting, I will simply quote Section 7.4.2
of RFC1521 in its entirety. 

This memorandum has unlimited distribution and is available by FTP from
DS.INTERNIC.NET, NIS.NSF.NET, NISC.JVNC.NET, FTP.ISI.EDU,
WUARCHIVE.WUSTL.EDU, FTP.CONCERT.NET, or FTP.SESQUI.NET. European readers
might be advised to use the United Kingdom repository at SRC.DOC.IC.AC.UK. 
Asian & Pacific Users should probably use the local mirror for
WUARCHIVE.WUSTL.EDU, or alternatively, their local National RFC
repository. 

>7.4.2.     The Application/PostScript subtype
>
>   A Content-Type of "application/postscript" indicates a PostScript
>   program.  Currently two variants of the PostScript language are
>   allowed; the original level 1 variant is described in [POSTSCRIPT]
>   and the more recent level 2 variant is described in [POSTSCRIPT2].
>
>   PostScript is a registered trademark of Adobe Systems, Inc.  Use of
>   the MIME content-type "application/postscript" implies recognition of
>   that trademark and all the rights it entails.
>
>   The PostScript language definition provides facilities for internal
>   labeling of the specific language features a given program uses. This
>   labeling, called the PostScript document structuring conventions, is
>   very general and provides substantially more information than just
>   the language level.
>
>   The use of document structuring conventions, while not required, is
>   strongly recommended as an aid to interoperability.  Documents which
>   lack proper structuring conventions cannot be tested to see whether
>   or not they will work in a given environment.  As such, some systems
>   may assume the worst and refuse to process unstructured documents.
>
>   The execution of general-purpose PostScript interpreters entails
>   serious security risks, and implementors are discouraged from simply
>   sending PostScript email bodies to "off-the-shelf" interpreters.
>   While it is usually safe to send PostScript to a printer, where the
>   potential for harm is greatly constrained, implementors should
>   consider all of the following before they add interactive display of
>   PostScript bodies to their mail readers.
>
>   The remainder of this section outlines some, though probably not all,
>   of the possible problems with sending PostScript through the mail.
>
>   Dangerous operations in the PostScript language include, but may not
>   be limited to, the PostScript operators deletefile, renamefile,
>   filenameforall, and file.  File is only dangerous when applied to
>   something other than standard input or output. Implementations may
>   also define additional nonstandard file operators; these may also
>   pose a threat to security.  Filenameforall, the wildcard file search
>   operator, may appear at first glance to be harmless. Note, however,
>   that this operator has the potential to reveal information about what
>   files the recipient has access to, and this information may itself be
>   sensitive.  Message senders should avoid the use of potentially
>   dangerous file operators, since these operators are quite likely to
>   be unavailable in secure PostScript implementations.  Message-
>   receiving and -displaying software should either completely disable
>   all potentially dangerous file operators or take special care not to
>   delegate any special authority to their operation. These operators
>   should be viewed as being done by an outside agency when interpreting
>   PostScript documents.  Such disabling and/or checking should be done
>   completely outside of the reach of the PostScript language itself;
>   care should be taken to insure that no method exists for re-enabling
>   full-function versions of these operators.
>
>   The PostScript language provides facilities for exiting the normal
>   interpreter, or server, loop. Changes made in this "outer"
>   environment are customarily retained across documents, and may in
>   some cases be retained semipermanently in nonvolatile memory. The
>   operators associated with exiting the interpreter loop have the
>   potential to interfere with subsequent document processing. As such,
>   their unrestrained use constitutes a threat of service denial.
>   PostScript operators that exit the interpreter loop include, but may
>   not be limited to, the exitserver and startjob operators.  Message-
>   sending software should not generate PostScript that depends on
>   exiting the interpreter loop to operate. The ability to exit will
>   probably be unavailable in secure PostScript implementations.
>   Message-receiving and -displaying software should, if possible,
>   disable the ability to make retained changes to the PostScript
>   environment, and eliminate the startjob and exitserver commands.  If
>   these commands cannot be eliminated, the password associated with
>   them should at least be set to a hard-to-guess value.
>
>   PostScript provides operators for setting system-wide and device-
>   specific parameters. These parameter settings may be retained across
>   jobs and may potentially pose a threat to the correct operation of
>   the interpreter.  The PostScript operators that set system and device
>   parameters include, but may not be limited to, the setsystemparams
>   and setdevparams operators.  Message-sending software should not
>   generate PostScript that depends on the setting of system or device
>   parameters to operate correctly. The ability to set these parameters
>   will probably be unavailable in secure PostScript implementations.
>   Message-receiving and -displaying software should, if possible,
>   disable the ability to change system and device parameters.  If these
>   operators cannot be disabled, the password associated with them
>   should at least be set to a hard-to-guess value.
>
>   Some PostScript implementations provide nonstandard facilities for
>   the direct loading and execution of machine code.  Such facilities
>   are quite obviously open to substantial abuse.  Message-sending
>   software should not make use of such features. Besides being totally
>   hardware- specific, they are also likely to be unavailable in secure
>   implementations of PostScript.  Message-receiving and -displaying
>   software should not allow such operators to be used if they exist.
>
>   PostScript is an extensible language, and many, if not most,
>   implementations of it provide a number of their own extensions. This
>   document does not deal with such extensions explicitly since they
>   constitute an unknown factor.  Message-sending software should not
>   make use of nonstandard extensions; they are likely to be missing
>   from some implementations. Message-receiving and -displaying software
>   should make sure that any nonstandard PostScript operators are secure
>   and don't present any kind of threat.
>
>   It is possible to write PostScript that consumes huge amounts of
>   various system resources. It is also possible to write PostScript
>   programs that loop infinitely.  Both types of programs have the
>   potential to cause damage if sent to unsuspecting recipients.
>   Message-sending software should avoid the construction and
>   dissemination of such programs, which is antisocial.  Message-
>   receiving and -displaying software should provide appropriate
>   mechanisms to abort processing of a document after a reasonable
>   amount of time has elapsed. In addition, PostScript interpreters
>   should be limited to the consumption of only a reasonable amount of
>   any given system resource.
>
>   Finally, bugs may exist in some PostScript interpreters which could
>   possibly be exploited to gain unauthorized access to a recipient's
>   system.  Apart from noting this possibility, there is no specific
>   action to take to prevent this, apart from the timely correction of
>   such bugs if any are found.

Hopefully this sets the record clear, once and for all with authority 
whose credentials cannot be questioned nor attacked.

I wonder though, did Netscape not know about RFC1521??

You'd expect them to, wouldn't you??




Alice de 'nonymous ...

                                  ...just another one of those...


P.S.  This post is in the public domain.
                  C.  S.  U.  M.  O.  C.  L.  U.  N.  E.