exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

fedcirc.97.13.txt

fedcirc.97.13.txt
Posted Sep 23, 1999

fedcirc.97.13.txt

SHA-256 | 62a25825cfd35ff587428c904c7e3c989cd7d0309d4765966e1c0ddd4004c020

fedcirc.97.13.txt

Change Mirror Download
-----BEGIN PGP SIGNED MESSAGE-----


******************************************************************************
------ ----- ----- --- -----
| ----- ---- | | | | |
|--- | | | | | | | |
| |-- | | | | |-- |
| | | | | | | \ |
| ----- ---- ----- ----- | \ -----

A D V I S O R Y

97.13
******************************************************************************
Topic: Vulnerability in metamail
Source: CERT

Creation Date: May 21, 1997
Last Updated: May 21, 1997


To aid in the wide distribution of essential security information,
FedCIRC is forwarding the following information from CERT/CC Advisory
CA-97.14. FedCIRC urges you to act on this information as soon as
possible.

If you have any questions, please contact FedCIRC:

Telephone: +1 888 282 0870
Email: fedcirc@fedcirc.gov



=======================FORWARDED TEXT STARTS HERE============================


============================================================================
CERT* Advisory CA-97.14
Original issue date: May 21, 1997
Last revised: May 21, 1997
Appendix A, FreeBSD - changed release date of the patch

Topic: Vulnerability in metamail
- - - -----------------------------------------------------------------------------

The CERT Coordination Center has received reports of a vulnerability in
metamail, a program that implements MIME. By exploiting the vulnerability, a
sender of a MIME-encoded electronic mail message can cause the receiver of the
message to execute an arbitrary command if the receiver processes the message
using the metamail package. If the attacker has an account on the target
user's local system or if the target user's system supports AFS or another
distributed filesystem, then the attacker can arrange for the arbitrary
command to be one the attacker created. This affects versions of metamail
through 2.7 (the current version).

The CERT/CC team recommends installing a vendor patch, if one is available,
patching metamail yourself, or disabling metamail (see Section III).

We will update this advisory as we receive additional information.
Please check our advisory files regularly for updates that relate to your site.

- - - -----------------------------------------------------------------------------

I. Description

Multipurpose Internet Mail Extensions (MIME) is a standard format
for extended Internet electronic mail. The MIME format permits email
to include enhanced text, graphics, and audio in a standardized and
interoperable manner. MIME is described in RFCs 2045 through 2049.

metamail is a package that implements MIME (note: metamail can be
obtained from ftp://ftp.funet.fi/pub/unix/mail/metamail/mm2.7.tar.Z).
Using a configurable "mailcap" file, metamail determines how to treat
blocks of electronic mail text based on the content as described by email
headers. Some popular packages for handling electronic mail have hooks
that allow metamail to be called automatically while a message is being
processed.

A condition exists in metamail in which there is insufficient variable
checking in some support scripts. By carefully crafting appropriate
message headers, a sender can cause the receiver of the message to
execute an arbitrary command if the receiver processes the message
using the metamail package.


II. Impact

A sender of a MIME encoded mail message can cause the receiver to
execute an arbitrary command. If the attacker has an account on the
target user's local system or if the target user's system supports
AFS or another distributed filesystem, then the attacker can arrange for
the arbitrary command to be one the attacker created.


III. Solution

If your vendor supplies metamail with its distribution, then install a
patch from your vendor (Solution A). If your vendor does not distribute
metamail with their products or does not have a patch available, use the
workaround in Solution B. An alternative for those with sufficient
expertise is to patch the metamail scripts as described in Solution C.

A. Install a patch from your vendor, if appropriate

The vendors we have heard from so far are listed below, with details
in Appendix A. We will update the appendix as we receive more
information.

Cray Research - A Silicon Graphics Company
Digital Equipment Corporation
FreeBSD, Inc.
Hewlett-Packard Company
IBM Corporation
Linux
NEC Corporation
Silicon Graphics Inc.
Solbourne
Sun Microsystems, Inc.

B. Disable metamail scripts

To disable the metamail scripts, remove the execute permissions from
the scripts that are located in the mm2.7/src/bin directory of
metamail v2.7 (the latest version of metamail). Remember that,
depending on your installation of metamail, the scripts may be located
in other directories in your operating system.

C. Patch metamail yourself

Sites that need to use metamail and have the expertise may wish to
patch the scripts that are part of the metamail distribution. Note
that the guidance below is supplied as is, and you need to be sure
that you understand the impact (if any) that your modifications will
have on metamail functionality.

The scripts referred to in the following material are all located in
the mm2.7/src/bin directory of metamail v2.7 (the latest version of
metamail). They may be located in other directories in your operating
system.

1. Ensure that parameters supplied to the scripts do not contain any
white space. Using showexternal as an example, add the following code
before any argument processing:

# Check argument integrity. Don't trust mail headers
switch ("$1$2$3$4$5$6$7")
case "*[\t ]*":
echo "Illegal white space in arguments\!"
echo "Command was:"
echo "'$0' '$1' '$2' '$3' '$4' '$5' '$6' '$7'"
exit 2
endsw

Add this code to the showexternal script at the very least, prior to
any argument processing within that script. We encourage you to
add this code to other scripts in mm2.7/src/bin directory to ensure
that arguments in those scripts also exclude white space. You may need
to adapt the code for your particular system.

Note that this patch may affect functionality in cases (such as
filenames) where parameters may have legitimately included
white space.

This step addresses the problem referred to in this advisory. As
part of a more generally secure programming practice, please
also consider the following modifications.

2. Ensure that script parameter references are quoted. For
instance, in showexternal, change this line:

set name=$3
to
set name="$3"

This should be done for every reference to a command line argument
in each of the scripts.

Note that csh has a :q operator which is also intended for this
purpose. If you prefer, you can use this operator in each case
instead of quoting.

3. Any variables in these scripts that take their value (either directly
or indirectly) from a script parameter should also be quoted where
necessary. For instance, in the showexternal script, change the line

get $name $NEWNAME
to
get "$name" "$NEWNAME"

Also change the following line:

if ($NEWNAME != $name) then
to
if ("$NEWNAME" != "$name") then

Similarly, there will be other instances where $name specifically,
and other variables in general, should be quoted. The reason is that
these variables take their value from the script parameters (for
example, $name takes its value from $3, and $NEWNAME may take its
value from $name).

As before, the :q operator can be used in each case.

Note that in doing this step, some care will be required.

4. Make sure that users have an appropriate umask set for directory
and file creation. Although the value is subject to local
restrictions, you may want to use a default value of 027
(depending upon the local environment).

5. Make sure that users have an appropriate value set for the
environment variable METAMAIL_TMPDIR. This environment variable tells
metamail where to create the temporary files it needs while
processing. If the variable is not set in the user's environment, the
default value is /tmp. Since /tmp is accessible by all users, it is
possible that use of this value will allow exploitation of race
conditions. We recommend setting the value to a protected directory
belonging to the user.

6. To ensure that the METAMAIL_TMPDIR is used properly and in a
secure manner, consider modifications along the following lines,
using the showexternal scripts as an example. These modifications
should reflect and reinforce the suggestions outlined in the
previous two items, namely that the temporary directory metamail
uses should be protected and accessible only by the user.

Note that the following code fragments are for example only, and
sites should adapt this code according to local requirements.

Change these lines:

if (! $?METAMAIL_TMPDIR) then
set METAMAIL_TMPDIR=/tmp
endif

to

# Set a sensible value for the temporary directory, if its not
# already set. If TMPDIR is set previously, then we will
# assume it is adequately protected.
if (! $?METAMAIL_TMPDIR) then
if ($?TMPDIR) then
set METAMAIL_TMPDIR="$TMPDIR"
else
set METAMAIL_TMPDIR=~/metamail_tmp
endif
endif

# Set a sensible umask value
umask 077

# Make sure that the temporary directory is available
if (! -d "$METAMAIL_TMPDIR") then

if (! -e "$METAMAIL_TMPDIR") then
mkdir "$METAMAIL_TMPDIR"
else
echo "$METAMAIL_TMPDIR exists, but is not a directory"
exit 2
endif

if ( $status != 0 || ! -d "$METAMAIL_TMPDIR" ) then
echo "Error creating $METAMAIL_TMPDIR"
exit 2
endif

endif

...........................................................................

Appendix A - Vendor Information

Below is a list of the vendors who have provided information for this
advisory. We will update this appendix as we receive additional information.
If you do not see your vendor's name, please contact the vendor directly or
use the workaround in Section III.


Cray Research - A Silicon Graphics Company
==========================================
Cray Research does not ship metamail as part of either Unicos or Unicos/mk.

Digital Equipment Corporation
=============================
SOURCE: 19.MAY.1997

Digital Equipment Corporation
Software Security Response Team
Copyright (c) Digital Equipment Corporation 1997. All rights reserved.

This reported problem is not present for Digital's ULTRIX or
Digital UNIX Operating Systems Software.

- DIGITAL EQUIPMENT CORPORATION

FreeBSD, Inc.
=============

If you installed the metamail package or port then you are
vulnerable. All released versions of FreeBSD including 2.2.2R have
this flaw in them. The port was corrected as of May 21, 1997. Either
update your system from a more recent port, or apply the patches
contained in this advisory to those files affected.

Hewlett-Packard Company
=======================

HP-UX is vulnerable; patches are in progress.

IBM Corporation
===============

Not vulnerable, metamail is not shipped as part of AIX.

IBM and AIX are registered trademarks of International Business Machines
Corporation.

Linux
=====

Debian:

Debian uses its own bourne shell based metamail scripts not the standard
ones.

Red Hat:

All versions of Red Hat are vulnerable. A replacement RPM is available
at

ftp://ftp.redhat.com/pub/redhat/updates/4.1/i386/metamail-2.7-7.i386.rpm

NEC Corporation
===============

UX/4800 Not vulnerable for all versions.
EWS-UX/V(Rel4.2MP) Not vulnerable for all versions.
EWS-UX/V(Rel4.2) Not vulnerable for all versions.
UP-UX/V(Rel4.2MP) Not vulnerable for all versions.
EWS-UX/V(Rel4.0) Not vulnerable for all versions.
UP-UX/V Not vulnerable for all versions.

Silicon Graphics Inc.
=====================

At this time, Silicon Graphics does not have any public information
for the metamail issue. Silicon Graphics has communicated with CERT
and other external security parties and is actively investigating
this issue. When more Silicon Graphics information (including any
possible patches) is available for release, that information will
be released via the SGI security mailing list, wiretap.

For subscribing to the wiretap mailing list and other SGI security
related information, please refer to the Silicon Graphics Security
Headquarters website located at:

http://www.sgi.com/Support/Secur/security.html

Solbourne
=========
We do not ship the utility.
We do not anticipate providing a patch, since we do not ship
the utility.

Sun Microsystems, Inc.
======================
Sun does not ship metamail with any of our platforms.
Sun has no plans to produce patches.

- - - -----------------------------------------------------------------------------

The CERT Coordination Center staff thanks Olaf Kirch for contributing code to
the solution section and thanks BSDI and FreeBSD for their input on the
solution.

- - - -----------------------------------------------------------------------------

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (see http://www.first.org/team-info/).


CERT/CC Contact Information
- - - ----------------------------
Email cert@cert.org

Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
and are on call for emergencies during other hours.

Fax +1 412-268-6989

Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
USA

Using encryption
We strongly urge you to encrypt sensitive information sent by email. We can
support a shared DES key or PGP. Contact the CERT/CC for more information.
Location of CERT PGP key
ftp://info.cert.org/pub/CERT_PGP.key

Getting security information
CERT publications and other security information are available from
http://www.cert.org/
ftp://info.cert.org/pub/

CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce

To be added to our mailing list for advisories and bulletins, send
email to
cert-advisory-request@cert.org
In the subject line, type
SUBSCRIBE your-email-address

- - - ---------------------------------------------------------------------------
* Registered U.S. Patent and Trademark Office.

Copyright 1997 Carnegie Mellon University
This material may be reproduced and distributed without permission provided
it is used for noncommercial purposes and the copyright statement is
included.

The CERT Coordination Center is part of the Software Engineering Institute
(SEI). The SEI is sponsored by the U.S. Department of Defense.
- - - ---------------------------------------------------------------------------

This file: ftp://info.cert.org/pub/cert_advisories/CA-97.14.metamail

http://www.cert.org
click on "CERT Advisories"


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history

May 21, 1997 Appendix A, FreeBSD - changed release date of the patch


========================FORWARDED TEXT ENDS HERE=============================

The National Institute of Standards and Technology (NIST) has
established a Federal Computer Incident response Capability (FedCIRC)
to assist federal civilians agencies in their incident handling
efforts by providing proactive and reactive computer security related
services. FedCIRC is a partnership among NIST, the Computer Incident
Advisory Capability (CIAC), and the CERT* Coordination Center
(CERT/CC).

If you believe that your system has been compromised, please contact
FedCIRC:

Telephone: +1 888 282 0870
Email: fedcirc@fedcirc.gov
Web Server: http://www.fedcirc.gov/

* Registered in U.S. Patent and Trademark Office

The CERT Coordination Center is part of the Software Engineering
Institute. The Software Engineering Institute is sponsored by the
U.S. Department of Defense.

CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.

This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface

iQCVAwUBM6WFfXVP+x0t4w7BAQEBRgP+I25WHeAjpWOmbvm843crKk2PGjs9gceu
CsLTG3+TZ76SUbjV0WqvLoU+X1oZ2BZYZtabdqamQrCuEudX1Ze3Sqd1Zp9xMBNt
E2TYgaffq6zXDkwgYa77F3iJ/qAfo12bXkK8r2E4AnelcV7ArEJjk4lNGd8LkMgj
hgVD0jN/UFY=
=QoId
-----END PGP SIGNATURE-----
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close