lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
From: dendler at (David Endler)
Subject: iDEFENSE Security Advisory 10.01.02: Sendmail smrsh bypass vulnerabilities

Hash: SHA1

iDEFENSE Security Advisory 10.01.02 
Sendmail smrsh bypass vulnerabilities


It is possible for an attacker to bypass the restrictions imposed by
The Sendmail Consortium’s Restricted Shell (SMRSH) and execute a
binary of his choosing by inserting a special character sequence into
his .forward file.  SMRSH is an application intended as a replacement
for sh for use in Sendmail. There are two attack methods both of
which are detailed below.

This method takes advantage of the application's implementation of
'||' command. The process is best explained with an example:

$ echo "echo unauthorized execute" > /tmp/unauth
$ smrsh -c ". || . /tmp/unauth || ." 
  /bin/sh: /etc/smrsh/.: is a directory
  unauthorized execute

/tmp/unauth is executed despite the fact that it is not located in
the SMRSH restricted directory /etc/smrsh. This happens because SMRSH
first checks for '.', which exists, and does no further verification
on the files listed after '||'. The same attack would look like the
following in the attackers .forward file: 

"| . \|| . /tmp/unauth \|| ."

This method takes advantage of the following routine from smrsh.c:

    /* search backwards for last / (allow for 0200 bit) */
    while (cmd > q)
            if ((*--cmd & 0177) == '/')

It is possible to feed SMRSH a command line that will be internally
converted to a space thereby bypassing all filters, yet will still
execute. Examples of these include:

    smrsh -c "/ command"
    smrsh -c "../ command"
    smrsh -c "./ command"
    smrsh -c "././ command"

The listed routine will convert any of the above examples to a space.
However, when the following execle() call is reached:

(void) execle("/bin/sh", "/bin/sh", "-c", newcmdbuf, NULL, newenv);

SMRSH will execute:

/bin/sh -c  command

Notice that despite the double space ‘command’ will still execute.
The .forward variation of this attack works the same way.

The Common Vulnerabilities and Exposures project ( has
assigned the name CAN-2002-1165 to this issue. 


The following are required conditions for successful and meaningful
exploitation of this vulnerability:

- - -	The target system must be utilizing SMRSH.
- - -	The attacker must have a valid local account on the system.
- - -	In method one the attacker must be able to create files.

While this exploit obviously removes the restrictions imposed by
SMRSH it also allows users to execute programs on systems that they
do not have shell access to. Utilizing either of the above-described
methods, an attacker who can modify his own .forward file can execute
arbitrary commands on the target system with the privileges of his
own account. Systems that forbid shell access generally do not have
tightened local security, the ability to execute arbitrary commands
through the SMRSH vulnerablity opens the target system to local
privilege escalation attacks that otherwise would not be possible.

The latest versions of SMRSH are vulnerable. Including the version
packaged with Sendmail 8.12.6 and Sendmail 8.11.6-15 (default install
of Redhat 7.3). Older versions of SMRSH do not appear to be
vulnerable (8.11 5/19/1998). The version of SMRSH available at is also not vulnerable.

WORKAROUND has provided a patch addressing the above-described
The patch is available for download at

VENDOR FIX/RESPONSE's official comment: 

"We would like to thank iDEFENSE, zen-parse, and Pedram Amini for
bringing these problems to our attention.

If you actually use a vulnerable smrsh version (which can be tested
according to the descriptions given before), please apply the patch
that has been made available. To figure out whether your
uses smrsh, check your file, i.e., look for


and check your file (usually located in /etc/mail or

grep '^Mprog.*smrsh'

Also consider whether you actually need this feature, e.g., if you
make procmail available to your users then smrsh is basically


9/1/2002 Disclosed to iDEFENSE
9/24/2002 Disclosed to
9/24/2002 Disclosed to iDEFENSE clients
9/24/2002 Response from Greg Shapiro
9/25/2002 Coordination from Claus Assmann
10/1/2002 Public Coordinated Disclosure


Method One was exclusively disclosed to iDEFENSE by zen-parse

Method Two was discovered during the verification process by Pedram
Amini (

Get paid for security research

Subscribe to iDEFENSE Advisories:
send email to, subject line: "subscribe"

- -dave

David Endler, CISSP
Director, Technical Intelligence
14151 Newbrook Drive
Suite 100
Chantilly, VA 20151
voice: 703-344-2632
fax: 703-961-1071

Version: PGP 7.1.2


Powered by blists - more mailing lists