See here: http://isec.pl/vulnerabilities/isec-0021-uselib.txt

I love FreeBSD more every day.. ;)

Oh boy ... what a nightmare :(

I love my Windows 95 :P

Wonder what impact having GRSec would be on that. From what it looks like, it might prevent it. Not sure though. Any thoughts?

So, is that anything to worry about if we do not allow other users to have shell access to our boxes?

Originally posted by accyroy
So, is that anything to worry about if we do not allow other users to have shell access to our boxes?

Yes, this can be exploited via Perl or PHP with the system function or via cron. ;)

Originally posted by Sheps
Wonder what impact having GRSec would be on that. From what it looks like, it might prevent it. Not sure though. Any thoughts?

http://grsecurity.net/download.php

Brad released patches, so i dont think it fixes it

I talked with somebody earlier today that was able to block it using grsecurity so I think that some configurations of it will block it. It certaintly looks like in the code that it is possible.

[rack911@rubix rack911]$ gcc -O2 -fomit-frame-pointer test.c -o elflbl
[rack911@rubix rack911]$ ls
elflbl test.c
[rack911@rubix rack911]$ ./elflbl

child 1 VMAs 0
[+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xf8400000 - 0xffffd000

[-] FAILED: uselib (Operation not permitted)
Killed

[rack911@rubix rack911]$ exit
exit



ok hrmmz...


i go look at the exploit again..


// temp lib location
#define LIBNAME "/dev/shm/_elf_lib"


Interesting.. lets take it off noexec and try again




[root@rubix root]# mount
/dev/hda3 on / type ext3 (rw,usrquota,grpquota)
none on /proc type proc (rw)
/dev/hda1 on /boot type ext3 (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
none on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
/dev/hdb1 on /backup type ext3 (rw)
/dev/tmpMnt on /tmp type ext3 (rw,noexec,nosuid,nodev,loop=/dev/loop0)
[root@rubix root]# pico /etc/fstab
[root@rubix root]# umount -l /dev/shm
[root@rubix root]# mount -a
[root@rubix root]# su rack911
[rack911@rubix root]$ cd /home/rack911
[rack911@rubix rack911]$ ls
elflbl test.c
[rack911@rubix rack911]$ ./elflbl

[+] SLAB cleanup
child 1 VMAs 25850
[+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xf8400000 - 0xffffd000
Wait... |
[-] FAILED: try again (-f switch) and again (Cannot allocate memory)
Killed


very interesting.. havin it noexec stopped it its tracks before it could allocate the memory..

Now you are thinking, what if they change it to /tmp, /var/tmp, etc?

well those are noexec on alot of servers so...hrmm

I haven't tried the exploit yet but redhat hasn't even said anything about it yet - maybe it's just someone blowing hot air.

Still worth a second look :)

*Nothing on cert.

Thanks for the info steve, now atleast we know it can be blocked from executing via php. Now just have to worry about shell users.

Originally posted by nybble
I haven't tried the exploit yet but redhat hasn't even said anything about it yet - maybe it's just someone blowing hot air.

Still worth a second look :)

*Nothing on cert.

Usually takes a day or two or three for redhat to patch anything

Crazy.
After all they now market themselves as a "server software maker" with their RHE.

That's just.... wack.
Then again I don't see new kernels for anyone else yet either.

Originally posted by LP-Trel
Yes, this can be exploited via Perl or PHP with the system function or via cron. ;)

so how do you fix this situation ?

best way is to compile from source and patch it

Originally posted by thelinuxguy
best way is to compile from source and patch it

would you explain alittle bit about compile from source and patch it ? my OS linux and cpanel, thanks

Down load the kernel and move it to /usr/src (this will use .tar.gz for this example )
untar the kernel

type:

tar -xzvf linux-kernel-name.tar.gz

Now download the patch to /usr/src
Type
gunzip patch-file-name
patch -p0 < patch-file-name
cd linux-kernel-name
make xconfig (if you do not have x-windows us 'make menuconfig')

Choose the hardware that you have and kernel options you want...

now compile the kernel with

make
make modules_install
make install (if this fails you may have to edit lilo.conf to make use of your new kernel and run lilo manually 'lilo -v')

BTW most of the time, patches can only be use against the vanilla kernel.

Thanks for that info!

Originally posted by thelinuxguy

very interesting.. havin it noexec stopped it its tracks before it could allocate the memory..

Now you are thinking, what if they change it to /tmp, /var/tmp, etc?

well those are noexec on alot of servers so...hrmm
plain dev, no tmpfs

[-] FAILED: open lib (/dev/shm/_elf_lib not writable?) (Permission denied)

default permissions to /dev/shm are 755
beside there is no need of changing source it seems

Usage: ./elflbl -f forced stop
-s silent mode
-r mem limit bytes
-c command to run
-n SMP iterations
-d race delta usecs
-w kswapd wait seconds
-l alternate lib name
-a alternate addr hex


$ ./elflbl -l ./lib
<snip>
[+] vmalloc area 0xe0000000 - 0xffff1000
Wait... |
[-] FAILED: uselib (Cannot allocate memory)
Killed
$

I could not manage to compile the file from various servers.


# gcc -O2 -fomit-frame-pointer elflbl.c -o elflbl
elflbl.c: In function `scan_mm_start':
elflbl.c:430: error: storage size of `l' isn't known
elflbl.c:430: error: storage size of `l' isn't known



# gcc -O2 -fomit-frame-pointer elflbl.c -o elflbl
elflbl.c:152: error: syntax error before "sys_mmap2"
elflbl.c:154: error: syntax error before "sys_mremap"
elflbl.c:156: error: syntax error before "sys_madvise"
elflbl.c:157: error: syntax error before "sys_mprotect"
elflbl.c:158: error: syntax error before "modify_ldt"
elflbl.c:160: error: syntax error before "sys_gettimeofday"
elflbl.c:161: error: syntax error before "sys_munmap"
elflbl.c:163: error: syntax error before "sys_uselib"
elflbl.c:165: error: syntax error before "sys_sched_yield"


Can someone send me the binary?

We are running 2.4.28 on our servers which is listed as the most recent version at kernel.org - is there an official patch (besides grsec) which fixes this?

Not that I know of.

There is also word going around that EL kernels are immune to this exploit.

Got another one for you hot off the presses..

http://www.securityfocus.com/archive/1/386875/2005-01-10/2005-01-16/0

Oh for crying out loud! :|

I suppose now we just sit and wait for an official kernel patch?

There is also another similar exploit:

"Locally exploitable flaw has been found in the Linux page fault handler code that allows users to gain root privileges if running on multiprocessor machine."

http://www.securiteam.com/unixfocus/5AP0H0KEKU.html

Its really a matter of concern.

Matter of concern is an understatement.. :rolleyes:

Well, yes the security flaws are a concern, but I'm happy they are finding them if they exist :)

My biggest issue with these latest releases is that they were posted to the public before a patch was issued - although I realize that sounds a tad wrong because the kernel is openly developed through the work of thousands of people - so keeping it quiet would not be a realy possibility. However, a timely response to such security alerts would be nice.

Originally posted by MaB
My biggest issue with these latest releases is that they were posted to the public before a patch was issued - although I realize that sounds a tad wrong because the kernel is openly developed through the work of thousands of people - so keeping it quiet would not be a realy possibility. However, a timely response to such security alerts would be nice.

Yes that really is becoming a bad trend of many of these people when they release exploits. I would not really care if they released it a week or two after a patch but the last few they are not. It is not like they were actively using them to hack servers, if they were they should not have published them in the first place.

My understanding is that these exploits are only for local users. If that is true, then while still a concern, the opportunity for exploiting a server is reduced.

Local exploits can be exploited by many of the thousands of exploits that exist in CGI and PERL programs that reside on a customers website. The user that your web server (apache) runs under is a local user and therefore any perl/php script with a certain security exploit can be used to take advantage of any of these recent findings. SSH/Telnet is not required

Local exploits can be taken advantage of not just by shell access, but by vulnerabilities in, and for example, php and perl scripts. No host has a perfect map as to what a customer has installed script wise and its hard to manage that aspect in full.

As for loving freebsd or any other OS over linux. What you have to understand is that linux is a popular OS. Yes, its true, and with popularity, comes more users, with more users comes more abusers. That in and of itself may not be a good thing, however the more vulnerabilities found and fixed, the less chance there are of others being available to find. FreeBSD and others are not free of vulnerabilites. I'm not putting any of them down, im only saying that just because a few vulnerabilities are found doesn't make it a bad thing. Programmers aren't perfect, and we shouldn't expect them to be. As my father in-law says, "Lifes a ****, you work, you eat, you pay taxes, do it all over again in the morning, and you die".. words we live bie IMHO.