suse 8.1 : ptrace exploit still working fine!?
A suse 8.1 based server has been cracked, and the "visitor" left all his tools, so I've been able to play with it as well. The server was kept "up to date", but look at that: om@box:~/tmp> uname -a Linux box 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown om@box:~/tmp> cat /etc/issue Welcome to SuSE Linux 8.1 (i386) - Kernel \r (\l). om@box:~/tmp> rpm -qa|grep k_ k_deflt-2.4.19-340 om@box:~/tmp> id uid=400(om) gid=500(nofiles) groups=500(nofiles) om@box:~/tmp> ./ptrace [*] PID of Parent: 22768 [*] PID of Child: 22769 [*] Attaching to PID 22770 [*] Got registers! [!] EIP: 0x4000eaed [!] ESP: 0xbffffa48 [!] EBP: 0xffffffda [!] EAX: 0xbffffa8c [!] EBX: 0xbffffc74 [!] ECX: 0xbfffff7c [!] EDX: 0x400130ec [!] EDI: 0x00000000 [!] ESI: 0x400135fc [*] Injecting shellcode (0x4000eaed) [*] Detaching from PID 22770 [*] Voila baby, entering rootshell! sh-2.05b# [*] waiting for SIGCHLD... sh-2.05b# id uid=0(root2) gid=0(root) groups=500(nofiles) sh-2.05b# Well... I thought that ptrace problem has been fixed... ? (in suse 8.2 it's fine, the exploit is not working) Regards, Olivier -- _________________________________________________________________ Olivier Mueller - om@8304.ch - PGPkeyID: 0E84D2EA - Switzerland
On Sun, Nov 30, 2003 at 12:48:23AM +0100, Olivier M. wrote:
A suse 8.1 based server has been cracked, and the "visitor" left all his tools, so I've been able to play with it as well. The server was kept "up to date", but look at that:
om@box:~/tmp> uname -a Linux box 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This date looks suspicious. The kernel from k_deflt-2.4.19-340 has time stamp Mon Aug 4 23:38:42 UTC 2003
om@box:~/tmp> rpm -qa|grep k_ k_deflt-2.4.19-340
I doubt the kernel you are running belongs to this package. Did you try to verify k_deflt package? What's the output of rpm -V k_deflt ? Also check your bootloader, what kernel is actually gets booted. Regards, -Kastus
Hi & thx for the feedback, On Sat, Nov 29, 2003 at 05:00:30PM -0800, Kastus wrote:
Linux box 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This date looks suspicious. The kernel from k_deflt-2.4.19-340 has time stamp Mon Aug 4 23:38:42 UTC 2003
interesting...
om@box:~/tmp> rpm -qa|grep k_ k_deflt-2.4.19-340
I doubt the kernel you are running belongs to this package. Did you try to verify k_deflt package? What's the output of rpm -V k_deflt ?
box:~ # rpm -V k_deflt .......T /lib/modules/2.4.19-4GB/kernel/drivers/char/i810_rng.o .......T /lib/modules/2.4.19-4GB/kernel/drivers/char/i8k.o .......T /lib/modules/2.4.19-4GB/kernel/drivers/char/ip2.o .......T /lib/modules/2.4.19-4GB/kernel/drivers/mtd/mtdchar.o .......T /lib/modules/2.4.19-4GB/kernel/drivers/mtd/mtdconcat.o .......T /lib/modules/2.4.19-4GB/kernel/drivers/mtd/mtdcore.o .......T /lib/modules/2.4.19-4GB/kernel/drivers/mtd/mtdpart.o .......T /lib/modules/2.4.19-4GB/kernel/drivers/net/arlan-proc.o .......T /lib/modules/2.4.19-4GB/modules.dep .......T /lib/modules/2.4.19-4GB/modules.generic_string .......T /lib/modules/2.4.19-4GB/modules.ieee1394map .......T /lib/modules/2.4.19-4GB/modules.parportmap .......T /lib/modules/2.4.19-4GB/modules.pnpbiosmap so just "timestamps" problems... box:~ # rpm -qf /boot/vmlinuz k_deflt-2.4.19-340 box:~ # uname -a Linux box 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown box:~ # ls -la /boot/vmlinuz -rw-r--r-- 1 root root 1191127 Aug 5 01:43 /boot/vmlinuz box:~ # md5sum /boot/vmlinuz e61b2a82e9089e8ca4dea2ed8ecbb0a1 /boot/vmlinuz
Also check your bootloader, what kernel is actually gets booted.
looks fine, setup is quite "standard": no special things: box:~ # more /boot/grub/menu.lst default 0 title linux kernel (hd0,0)/vmlinuz root=/dev/cciss/c0d0p3 vga=788 initrd (hd0,0)/initrd regards, Olivier -- _________________________________________________________________ Olivier Mueller - om@8304.ch - PGPkeyID: 0E84D2EA - Switzerland
On Sunday 30 November 2003 13:19, Olivier M. wrote:
Hi & thx for the feedback,
On Sat, Nov 29, 2003 at 05:00:30PM -0800, Kastus wrote:
Linux box 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This date looks suspicious. The kernel from k_deflt-2.4.19-340 has time stamp Mon Aug 4 23:38:42 UTC 2003
interesting...
om@box:~/tmp> rpm -qa|grep k_ k_deflt-2.4.19-340
I doubt the kernel you are running belongs to this package. Did you try to verify k_deflt package? What's the output of rpm -V k_deflt ?
box:~ # rpm -V k_deflt .......T /lib/modules/2.4.19-4GB/kernel/drivers/char/i810_rng.o .......T /lib/modules/2.4.19-4GB/kernel/drivers/char/i8k.o .......T /lib/modules/2.4.19-4GB/kernel/drivers/char/ip2.o .......T /lib/modules/2.4.19-4GB/kernel/drivers/mtd/mtdchar.o .......T /lib/modules/2.4.19-4GB/kernel/drivers/mtd/mtdconcat.o .......T /lib/modules/2.4.19-4GB/kernel/drivers/mtd/mtdcore.o .......T /lib/modules/2.4.19-4GB/kernel/drivers/mtd/mtdpart.o .......T /lib/modules/2.4.19-4GB/kernel/drivers/net/arlan-proc.o .......T /lib/modules/2.4.19-4GB/modules.dep .......T /lib/modules/2.4.19-4GB/modules.generic_string .......T /lib/modules/2.4.19-4GB/modules.ieee1394map .......T /lib/modules/2.4.19-4GB/modules.parportmap .......T /lib/modules/2.4.19-4GB/modules.pnpbiosmap
so just "timestamps" problems...
No not just timestamps problems, that timestamp is embedded in the kernel, so you are actually still running an older kernel which still has the exploit. The fact that rpm -V checks out ok does not mean you are running that kernel, it ony means that you indeed installed the update, to run the new kernel your bootloader has to point to it and you must reboot. Did you reboot that machine after updating the kernel?
box:~ # rpm -qf /boot/vmlinuz k_deflt-2.4.19-340 box:~ # uname -a Linux box 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown box:~ # ls -la /boot/vmlinuz -rw-r--r-- 1 root root 1191127 Aug 5 01:43 /boot/vmlinuz box:~ # md5sum /boot/vmlinuz e61b2a82e9089e8ca4dea2ed8ecbb0a1 /boot/vmlinuz
Also check your bootloader, what kernel is actually gets booted.
looks fine, setup is quite "standard": no special things:
box:~ # more /boot/grub/menu.lst default 0 title linux kernel (hd0,0)/vmlinuz root=/dev/cciss/c0d0p3 vga=788 initrd (hd0,0)/initrd
regards, Olivier
-- GertJan Email address is invalid, so don't reply directly, I'm on the list.
On Sun, Nov 30, 2003 at 03:10:43PM +0100, GertJan Spoelman wrote:
No not just timestamps problems, that timestamp is embedded in the kernel, so you are actually still running an older kernel which still has the exploit.
ok
The fact that rpm -V checks out ok does not mean you are running that kernel, it ony means that you indeed installed the update, to run the new kernel your bootloader has to point to it and you must reboot.
yes, that is clear. I don't remember when the update has been installed, so I can't tell if server has been rebooted since then.
Did you reboot that machine after updating the kernel?
box:~ # uptime 12:20am up 103 days, 15:23, 1 user, load average: 0.05, 0.26, 0.14 I guess that will be the point. I can't reboot it right now (it's not my server), but I'll try ASAP. Thanks for the hint: this is quite logical! regards, Olivier
On Mon, Dec 01, 2003 at 12:22:52AM +0100, Olivier M. wrote:
I don't remember when the update has been installed, so I can't tell if server has been rebooted since then.
rpm -qi k_deflt It tells package installation date. Regards, -Kastus
so just "timestamps" problems...
box:~ # rpm -qf /boot/vmlinuz k_deflt-2.4.19-340 box:~ # uname -a Linux box 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown box:~ # ls -la /boot/vmlinuz -rw-r--r-- 1 root root 1191127 Aug 5 01:43 /boot/vmlinuz box:~ # md5sum /boot/vmlinuz e61b2a82e9089e8ca4dea2ed8ecbb0a1 /boot/vmlinuz
I am running exactly the same kernel, also after some YOU run. My system is an 8.1. (1:59 draht@silence:~ ) md5sum /boot/vmlinuz e61b2a82e9089e8ca4dea2ed8ecbb0a1 /boot/vmlinuz (1:59 draht@silence:~ ) uname -a Linux silence 2.4.19-4GB #1 Mon Aug 4 23:38:42 UTC 2003 i686 unknown (1:59 draht@silence:~ ) Just regularly run YOU, always... Thanks, Roman.
On Sun, Nov 30, 2003 at 12:48:23AM +0100, Olivier M. wrote:
sh-2.05b# id uid=0(root2) gid=0(root) groups=500(nofiles) sh-2.05b# Well... I thought that ptrace problem has been fixed... ? (in suse 8.2 it's fine, the exploit is not working)
At least one of the exploits currently in the wild make the exploit binary suid root after working for the first time. So, if you boot an old kernel, run the exploit (it works), then boot the fixed kernel and run the exploit again, you will get root again, but because of the SUID root bit. You might want to check if this is not the case.
On Sun, Nov 30, 2003 at 12:48:23AM +0100, Olivier M. wrote:
Well... I thought that ptrace problem has been fixed... ? (in suse 8.2 it's fine, the exploit is not working)
Conclusion: after a reboot: om@box:~/tmp2> ./ptrace [*] PID of Parent: 23839 [*] PID of Child: 23840 [*] Attaching to PID 23841 Killed So the system was uptodate and correctely patched all the time, but the "problem" was just the uptime of 103 days. Server should have been rebooted to activate the protection, which is indeed pretty logical in case of kernel upgrade (openssh update : restart ssh service, kernel update: restart server). Thanks to all for the great support & advices and sorry for all that noise. At least we won't make the same mistake again later :) Something is still strange: the ptrace exploit appeared around March/April 2003, and the fixed (suse-)kernel for 8.1 only in August ? Regards, Olivier
Hi, so what do we learn about this? Never do a automatic Update and run YOU interactive. It would have mentioned about rebooting ;-) Or didn`t you read the messages? SCNR Now a Question to the List and to SuSE ;-) What about a YOU option to spezify the Mailaddress where YOU-Messages are mailed to in auto-Mode? Or did i just overread this in the MAN-Pages ?!? Greetings Dirk Olivier M. schrieb:
On Sun, Nov 30, 2003 at 12:48:23AM +0100, Olivier M. wrote:
Well... I thought that ptrace problem has been fixed... ? (in suse 8.2 it's fine, the exploit is not working)
Conclusion: after a reboot:
om@box:~/tmp2> ./ptrace [*] PID of Parent: 23839 [*] PID of Child: 23840 [*] Attaching to PID 23841 Killed
So the system was uptodate and correctely patched all the time, but the "problem" was just the uptime of 103 days. Server should have been rebooted to activate the protection, which is indeed pretty logical in case of kernel upgrade (openssh update : restart ssh service, kernel update: restart server).
Thanks to all for the great support & advices and sorry for all that noise. At least we won't make the same mistake again later :)
Something is still strange: the ptrace exploit appeared around March/April 2003, and the fixed (suse-)kernel for 8.1 only in August ?
Regards, Olivier
On Dec 3, Dirk Schreiner <dirk.schreiner@tria.de> wrote:
Hi,
so what do we learn about this? Never do a automatic Update and run YOU interactive. [...] What about a YOU option to spezify the Mailaddress where YOU-Messages are mailed to in auto-Mode? That's why fou4s sends you a detailed report about all necessary updates and lets you decide what to do. Most kernel updates also have pre-install information that requires interactive mode (so you have to confirm that you want a kernel update). I would only automate such things, if I had a huge amount of equal workstations ...
Markus http://fou4s.gaugusch.at/ -- __________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus@gaugusch.at X Against HTML Mail / \
participants (7)
-
Andreas -
Dirk Schreiner -
GertJan Spoelman -
Kastus -
Markus Gaugusch -
Olivier M. -
Roman Drahtmueller