Ptrace hole in 2.4

[Cyrus]

Read more from
http://marc.theaimsgroup.com/?l=linux-kernel&m=104791735604202&w=2

make-kpkg produces this error:

i386_ksyms.c:70: `kernel_thread' undeclared here (not in a function)
i386_ksyms.c:70: initializer element is not constant
i386_ksyms.c:70: (near initialization for `__ksymtab_kernel_thread.value')
make[2]: *** [i386_ksyms.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.4.20/arch/i386/kernel'
make[1]: *** [_dir_arch/i386/kernel] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.20'
make: *** [stamp-build] Error 2

Any fixes/ideas?

[spender]

You didn't patch the failed hunk in include/linux/sched.h

We'll be releasing 1.9.9d soon (tonight or tomorrow) that fixes this ptrace bug (btw people using the ACL system were not affected), and adds in the new PaX ports for several new archs.

-Brad

[miha]

stange.. 2.4.19 with grsec isn't affected, however 2.4.20 with grsec with the same settings is affected..
really waiting for new version of grsec, Brad.

[spender]

How have you been able to verify that? I've not seen an exploit released for the hole yet. I would imagine it would be difficult to exploit on a grsec system even without the ACL system. PaX would keep them from injecting arbitrary code into the task via ptrace, and randomized PIDs would make it difficult for the attacker to find the pid of the process spawned by the kernel.

-Brad

[spender]

I just tested the exploit. It won't work if PaX is enabled on the system. It would work, however, if someone wrote a ret2libc exploit for it. Of course, if you had an ACL on modprobe in the ACL system, not even that attack would work.

-Brad

[h4x0r]

I'm assuming this exploit has no bearing on 2.4.x kernels compiled without loadable module support?

cat: /proc/sys/kernel/modprobe: No such file or directory

[spender]

This exploit, yes, but it would still be possible I think to exploit the hole if you have hotplug support built in (it's enabled by default).

-Brad

[miha]

How have you been able to verify that? I've not seen an exploit released for the hole yet. I would imagine it would be difficult to exploit on a grsec system even without the ACL system. PaX would keep them from injecting arbitrary code into the task via ptrace, and randomized PIDs would make it difficult for the attacker to find the pid of the process spawned by the kernel.

-Brad

Brad, which exploit have you tried? I used isec-ptrace-kmod-exploit.c
On machine running 2.4.19-grsec it doesn't work, however it works with 2.4.20-grsec which has the same ACL/grsec settings as 2.4.19-grsec

[spender]

You must not have PaX enabled on modprobe. I tried the same exploit as you.

-Brad

[h4x0r]

Can the possibility of using the vulnerablility through hotplug be eliminated if sbin/hotplug is renamed or /proc/sys/kernel/hotplug is pointed to a non-existant binary?

[spender]

Yes. I think /sbin/loader can be used for the exploit as well, if misc binary support is compiled in.

-Brad

[humpback]

I ma running gentoo. The kernel i use is gentoo-sources-2.4.19-r10.
This kernel comes with grsecurity-1.9.7 .
In this system and using the exploit available at http://hack.co.za the exploit just eats cpu.
If you want to see my grsec options please take a look at http://student.dec.uc.pt/~humpback/grsec.txt

[AverageUser]

In case you aren't aware, this patch reportedly causes system crashes under heavy load:

http://groups.google.com/groups?threadm ... at.bofh.it

A fix is proposed.

[spender]

Thanks for the link. I've committed the change to current CVS. It will be included in grsec 1.9.9f.

-Brad