(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:
pgp1BQw03DyaE.pgp
Description: PGP signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/