Message-ID: <200306132124.h5DLOp33011987@mailserver2.hushmail.com>
From: hack4life at hushmail.com (hack4life@...hmail.com)
Subject: -10Day CERT Advisory on PDF Files

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi Hackers

Ok, so I’ve been a bit quiet recently, what with college and exams. But
the semesters nearly over now so I’ll have plenty of time to keep you
all up to date with what those fools at CERT are up to once college is
finished.

Anyway, on with the show, here we have a nice little hole allowing you
to execute shell commands by embedding them in PDF files. Obviously no
one’s likely to be reading PDF’s as root on a production server, but
nice for rm’ing those ankle biting Linux lusers. You’ll also some example
code. There was also some example code for mapping untrusted URIs to
a safer format, but I’m not releasing that, we’re here to *HACK* boxes
not to Patch them!

You’ll also notice that this takes the format of the form used to report
holes to CERT rather than my usual draft advisory format. If you want
to wait for the actual CERT advisory (probably with out details of how
to exploit it) they will be releasing it on Monday 23rd June 2003, making
my release –10 Day!

Hack4Life



#####NOT FOR PUBLIC DISTRIBUTION#####

CONTACT INFORMATION
Let us know who you are:
Name: Martyn Gilmore
E-mail: gilmore@...raxion.com
Phone / fax: 513-374-1586
Affiliation and address: 1068 Archland Drive, Cincinnati, OH 45224


Have you reported this to the vendor?  [yes/no] no

Please describe the vulnerability.

Valid PDF files can contain malicious external-type hyperlinks that can
execute arbitrary shell commands underneath Unix with various PDF viewers/readers.
The hyperlinks must be activated or followed for the malicious script
to run.  The obvious case is for a user to click on one.

The PDF viewers/readers, which are known to be vulnerable
at this time, appear to spawn (exec) the associated
external program handlers with "sh -c".

"sh -c <registered-program> <embedded-hyperlink>"


What is the impact of this vulnerability?
- - - ----------------------------------------
(For example: local user can gain root/privileged access, intruders can
create root-owned files, denial of service attack,  etc.)
a)	What is the specific impact:

Under probable conditions, arbitrary Unix shell commands can be executed
with the PDF reader/viewer user's privileges when malicious hyperlinks
are activated.
b)	How would you envision it being used in an attack scenario:

Many are possible (especially if the user has more privileges).  I don't
know, if there are any real restrictions on the embedded shell script's
length.
To your knowledge is the vulnerability currently being exploited?
- - - ----------------------------------------------------------------
[yes/no] no
If there is an exploitation script available, please include it here.
- - - -----------------------------------------------------------------
- ---
Attachment evil.pdf contains the embedded command
`rm -rf $HOME/monkey`

Preconditions:
1. User's home directory does NOT contain a file or directory
named 'monkey'
2. Run 'touch $HOME/monkey'
3. Adobe Acrobat 5.06 on Redhat 8.0 only performs the "sh -c" type of
action when there is no current running browser/email program (i.e. mozilla).
Exploit:
Open PDF file and click on gilmore@...raxion.com hyperlink
Proof of exploit:
Absence of $HOME/monkey
With the help of pdflatex, the attachment evil.tex is the source document
for evil.pdf.  Other "flexible" PDF authoring solutions probably would
work too.
Do you know what systems and/or configurations are vulnerable?
- - - -------------------------------------------------------------
[yes/no]  (If yes, please list them below)
System        :   PDF viewers/readers, which spawn external
programs with "sh -c" to handle certain
types of hyperlinks.
OS version    :   Most Unix versions
Verified/Guessed: Guessed (beyond what I report below)


I've only verified the following programs on Redhat Linux 8.0.
Xpdf                 1.01
Adobe Acrobat Reader 5.06

Xpdf executes the malicious embedded script, regardless of whether the
handler is currently running or not.
The Ghostview derivative on my machine, doesn't have hyperlinks enabled
(ignores that aspect of the PDF file).  Others readers maybe affected
as well.
Are you aware of any workarounds and/or fixes for this vulnerability?
- - - -----------------------------------------------------------------
- ---
[yes/no] (If you have a workaround or are aware of patches please include
the information here.)
I'm aware of no fixes in any PDF readers/viewers.
Each program's implementation may differ (languages, dynamic memory libraries)
to prevent a universal fix, however suggested guidelines are given below.
 These guidelines are an attempt to offer a robust solution with a minimal
effect on existing behavior.
If the "sh -c" type of invocation is a necessary way to spawn external
browser/email program(s), then the embedded hyperlink should be properly
quoted/escaped.
The "sh -c" type of invocation maybe desirable to allow, the configuration
of the external programs to contain environmental variables.

i.e. "sh -c $USER_BROWSER args"

The easiest solution (IMHO) underneath these types of scenarios
is to enclose the embedded hyperlink within single quotes (avoids
escaping the entire Unix shell meta-character soup).

In addition, any single quotes found within the original embedded
hyperlink, should be replaced with '"'"'
(i.e. "\'\"\'\"\'" for C/C++ programs).  Programs will have to
deal correctly with possibilities of unknown-length string expansion
or risk overwrites of the heap or stack; use of std::string or RWCString
in C++ would simplify the design, if they are available.
Testing will require conditions to trigger the "sh -c" type of invocation
(i.e. browser/email program not running) for each PDF reader/viewer.
1.) Hyperlinks with embedded shell exploits will not be executed.
2.) Proper email addresses such as
"Martyn%20Gilmore<gilmore@...raxion.com>" and
"gilmore@...raxion.com(Martyn%20Gilmore)" should now
work as "mailto:" targets.  These legitimate uses
are how the exploit was discovered, since some Unix
shell meta-characters are present and prevent positive functionality
from occurring.

Caveats/Notes:
The solution above is a result of correcting the direct actions of the
PDF viewer/reader against misuse.
The user configurable spawned programs are trusted to not eval their
arguments further, otherwise the original exploit returns.
The potential security breach of additional evals is the onus of the
configured handler or the end-user (not having a secured environment
or not having an responsible entrusted handler).
Clarification of initial report:
Besides the potential for explicit "sh -c" in an exec*() Unix system
calls, the C StdLib system() call performs one implicitly.  Better Proposed
Fix: I think that my first proposed fixed was too naive.?  Mozilla 1.3
has a shell wrapper that calls eval.? Other configured browers/handlers
could have the same problem or could easily introduce one, even if unintentional
(check-in of a developer copy).
Granted the programs I originally cited as guilty parties execute the
malicious code first, however they are only the first in a potential
chain.
Rather than trying to correct the whole round trip (more programs), it
is more feasible for PDF viewer/reader party to make sure their "Untrusted
URIs" don't have immediate or long-term potential for problems.? The
effort is about the same as the original suggestion.
I've attached a small example C++ program that maps untrusted URIs to
a safer format, which is a far better alternative to the Unix-based quoting
that only lasts one round and has potential to pass the buck.

-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.3
Charset: UTF8

wkYEARECAAYFAj7qQNQACgkQgSjHzuae7+okUQCfWQfknodvOKkIMHWuxEtei0QgTfEA
njzg8owJH9nYZ1KTKun+/eey3Wgn
=1m0Y
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: evil.tex.uu
Type: application/octet-stream
Size: 8607 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030613/238032b4/evil.tex.obj
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: evil.tex.uu.sig
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030613/238032b4/evil.tex.uu.ksh

Powered by blists - more mailing lists