Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: PostScript security research
From: Valdis.Kletnieks () vt edu
Date: Sun, 04 Mar 2007 14:01:51 -0500

(First attempt to post fell afoul of an RBL)

On Sat, 03 Mar 2007 20:06:46 +0100, Paul Sebastian Ziegler said:

1) Has anybody researched this before (no need to crash open doors)
2) Is PostScript capable of using the system()-call or something similar?

Hardly news. Quoting RFC1341, section 7.4.2, issued in June 1992, as part
of the original specification of MIME:

            7.4.2     The Application/PostScript subtype

            A  Content-Type  of  "application/postscript"  indicates   a
            PostScript    program.    The   language   is   defined   in
            [POSTSCRIPT].  It is recommended  that  Postscript  as  sent
            through  email  should  use  Postscript document structuring
            conventions if at all possible, and correctly.

            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
            reenabling 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. Eliminate the startjob and exitserver commands.
            If  these  commands  cannot  be eliminated, at least set the
            password associated with them 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,  at least set the password associated with them 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.

Attachment: _bin

Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]