Linux Users - Kernel Exploit released~~!

[gumdrop]

which unfortunately is just about everyone running 64-bit Linux. To make matters worse, in the last day we?ve received many reports of people attacking production systems using an exploit for this vulnerability, so if you run Linux systems, we recommend that you strongly consider patching this vulnerability. (Linux vendors release important security updates every month, but this vulnerability is particularly high profile and people are using it aggressively to exploit systems).

PLEASE STICKY THIS!

http://blog.ksplice.com/2010/09/cve-2010-3081/

[Brujah]

It's a very sloppy update too, one of my servers anyway.... /tmp is noexec, and it failed to exec the configs for it as a result.

[gumdrop]

It's a very sloppy update too, one of my servers anyway.... /tmp is noexec, and it failed to exec the configs for it as a result.

There is no update for CenOS yet as of today.

[Zyber]

thanks for sharing this

[Barry-xlovecam]

It doesn't even say what kernels are vulnerable ...

$.uname -a

I updated the kernel some days ago.

[gumdrop]

ALL 64-Bit kernels.

[borked]

why "ALL" 64-bit kernels... it states:

The flaw identified by CVE-2010-3081 (Red Hat Bugzilla bug 634457) describes an issue in the 32/64-bit compatibility layer implementation in the Linux kernel, versions 2.6.26-rc1 to 2.6.36-rc4.

2.6.18 looks good to me...

[ladida]

Rofl. Do you realize how many of these are found each and every day? And how many stay hidden for years? Lol@sticky this

[gumdrop]

why "ALL" 64-bit kernels... it states:



2.6.18 looks good to me...

NO!

The published workarounds that we?ve seen, including the workaround recommended by Red Hat, can themselves be worked around by an attacker to still exploit the system.

You can use the test tool:
https://www.ksplice.com/uptrack/cve-2010-3081

[gumdrop]

Rofl. Do you realize how many of these are found each and every day? And how many stay hidden for years? Lol@sticky this

Terrible!
LOL@youbeenhackedby this.

[roly]

i use yum to update my kernel but there's no updates showing on any of the repositories that i use yet.

[borked]

NO!



You can use the test tool:
https://www.ksplice.com/uptrack/cve-2010-3081

I don't understand why you say NO!? The exploit says the .26-.34 kernels are affected, and the test from ksplice is simply a tool to see if the system has been exploited....

Although this doesn't suggest your system hasn't been compromised already, if exploited, a reboot will close the holes. Kind of like closing the stable door after the horse went for a piss, but still.

to me looks like .18 kernels are fine?

[borked]

i use yum to update my kernel but there's no updates showing on any of the repositories that i use yet.

It's takes ages for anything to reach yum if it's a simple patch.

Someone released a patch for my kernel -
https://bugzilla.redhat.com/show_bug.cgi?id=634457#c20

when it gets approved, I'll load it on, whether the .18 kernel is vulnerable or not

[gumdrop]

If you are using CentOS there has been some progress:

http://bugs.centos.org/view.php?id=4518

[gumdrop]

I don't understand why you say NO!? The exploit says the .26-.34 kernels are affected, and the test from ksplice is simply a tool to see if the system has been exploited....

Although this doesn't suggest your system hasn't been compromised already, if exploited, a reboot will close the holes. Kind of like closing the stable door after the horse went for a piss, but still.

to me looks like .18 kernels are fine?

According to the CentOS team it's not:

1) public exploit (with backdoor) for gaining root on a CentOS-5 x86_64 machine
2) only x86_64 machine are affected from kernel-2.6.18-164 and onward (CentOS-5.4 too)

http://bugs.centos.org/view.php?id=4518

[zagi]

Doesn't look like it affects CentOS that much:


$ ./diagnose-2010-3081
Diagnostic tool for public CVE-2010-3081 exploit -- Ksplice, Inc.
(see http://www.ksplice.com/uptrack/cve-2010-3081)

$$$ Kernel release: 2.6.18-194.11.1.el5xen
$$$ Backdoor in LSM (1/3): not available.
$$$ Backdoor in timer_list_fops (2/3): not available.
$$$ Backdoor in IDT (3/3): checking...not present.

Your system is free from the backdoors that would be left in memory
by the published exploit for CVE-2010-3081.


$ cat /etc/redhat-release
CentOS release 5.5 (Final)

[Klen]

Well this exploit can be resolved simply by adding ip restriction to ssh.

[signupdamnit]

https://access.redhat.com/kb/docs/DOC-40265

Note that they need to gain access to a local account before it is of any use to an attacker.

Also:

As suggested on the Full Disclosure mailing list, it is possible to temporarily mitigate this issue. However, the steps provided below are only meant for the publicly-circulated exploit - they are insufficient for completely mitigating this vulnerability. As such, we strongly encourage you to install the updated kernel packages for Red Hat Enterprise Linux 5 when they become available soon.

[mrsmut]

I've seen today a server with Centos being hacked this way through an old install of oscommerce

as usual, the atacker uploaded a phpshell and downloaded the exploit to gain root, after that defaced all sites on server

Server was running Centos 5 64bit with kernel 2.6.18-194.8.1
attacker overwrote every index* file, when atacker was discovered, tried to rm -rf * whole drive, luckily we caught it on time.

Centos 5 IS vulnerable now

[borked]

i use yum to update my kernel but there's no updates showing on any of the repositories that i use yet.

it's now in the repository...

 kernel	x86_64	2.6.18-194.11.4.el5	updates	19 M
 kernel-devel	x86_64	2.6.18-194.11.4.el5	updates	5.4 M

2.6.18-194.11.4 closes this flaw
http://lwn.net/Articles/406414/

[roly]

it's now in the repository...

 kernel	x86_64	2.6.18-194.11.4.el5	updates	19 M
 kernel-devel	x86_64	2.6.18-194.11.4.el5	updates	5.4 M

2.6.18-194.11.4 closes this flaw
http://lwn.net/Articles/406414/

yes all updated thanks

[borked]

Don't forget to reboot after kernel update....

[roly]

Don't forget to reboot after kernel update....

that's what i don't understand when people show uptime on their servers of 1 year or something, i seem to be updating my kernel every 4-6 weeks or so.