[EMAIL PROTECTED] (David Endler) writes:
> -----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-----
-------------------------------------------------------
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server
today at http://www.ServePath.com/indexfm.htm
_______________________________________________
linux-india-help mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/linux-india-help
