64 bit root exploit checking tool

LeeF · 2010-09-20 08:39:06

I know there's already a thread about the actual exploit asking if it was patched, so this is slightly related. There's a tool you can download from Kslpice, to check if your kernel has already been compromised, you can get the source here. I compiled it using "gcc diagnose-2010-3081.c" which produced a.out as expected, with no errors, but when I ran it I got this:

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

$$$ Kernel release: 2.6.35-fbcondecor
!!! Error in setting cred shellcodes

I'm nowhere near proficient enough with C++ to understand what this is doing or where to start, so can someone who does please let me know what's going on?

EDIT: I know it's not much help, but the error is happening around lines 470-80 when checking the "_m_cred" array.

Last edited by LeeF (2010-09-26 23:09:40)

tomk · 2010-09-20 09:46:56

Why not just apply the required patch to your kernel?

Allan · 2010-09-20 09:51:12

A nice part of the expliot is that you can leave backdoor for later use:
http://linux.slashdot.org/story/10/09/2 … t-Machines

LeeF · 2010-09-20 10:03:12

tomk wrote:

Why not just apply the required patch to your kernel?

I have, the point is to check for the persisting backdoor that Allan mentioned. This backdoor stays there even after you've applied that patch, if your system was already compromised before you patched it. It's quite a nasty situation that not many people are fully aware of.

Last edited by LeeF (2010-09-20 10:04:19)

tomk · 2010-09-20 10:07:56

Allan wrote:

A nice part of the expliot...

Nice?? Who's side are you on?

Allan · 2010-09-20 10:12:53

I'll just point out, even with the original exploit (which did not leave a backdoor), you are still in trouble if someone has had root access to your system...

Allan · 2010-09-20 10:16:11

tomk wrote:

Allan wrote:
A nice part of the expliot...
Nice?? Who's side are you on?

I'm not a sysadmin

LeeF · 2010-09-20 10:17:28

Allan wrote:

I'll just point out, even with the original exploit (which did not leave a backdoor), you are still in trouble if someone has had root access to your system...

Which is exactly why I want to check if that backdoor is there... Call me paranoid, but you never can be too careful when your system stores sensitive information.

So, any thoughts gents?

tomk · 2010-09-20 10:19:01

Getting the same error here, Leef, and I don't have the skills to debug it either (although I think that's C, not C++).

Personally, I'm not worried, as I'm the only user of my systems, and none of them are public.

LeeF · 2010-09-20 10:19:58

Allan wrote:

tomk wrote:
Allan wrote:
A nice part of the expliot...
Nice?? Who's side are you on?
I'm not a sysadmin

I can tell, cause I'm the one whose sweating, while you're making jokes.

LeeF · 2010-09-20 10:32:13

tomk wrote:

Getting the same error here, Leef, and I don't have the skills to debug it either (although I think that's C, not C++).
Personally, I'm not worried, as I'm the only user of my systems, and none of them are public.

If you browse the web with one of them, that's all it could take for the exploit (in theory, there's no confirmed cases of this, that I know of), from there, depending on your internal network architecture and permission settings they could potentially gain access to those systems.... DOOM, DOOM.... DOOOOOM!!!!!

Sorry for the melodramatics, I couldn't resist. But I am genuinely concerned as my netbook holds critical client information, albeit in 2 to 3 layers of encryption. So there should be no risk, but if an attacker had root, he could log my key stokes and overcome that protection quite quickly, if I was unaware my system had been exploited.

madeye · 2010-09-20 10:36:18

Isn't there a livecd somewhere with this tool that could be used for checking a system? Or does it need to be installed on the infected system to actually be able to check for the exploit?

LeeF · 2010-09-20 10:39:05

madeye wrote:

Isn't there a livecd somewhere with this tool that could be used for checking a system? Or does it need to be installed on the infected system to actually be able to check for the exploit?

I'm not entirely sure, but I think the affected kernel would need to be the one that's loaded into memory to check it properly. But, I could be entirely wrong, so who knows, the kernel isn't a beast I understand enough, I just utilize it's wicked power.

hidefromkgb · 2010-09-20 11:12:27

Is there any patch for 2.6.32-LTS kernel?

Last edited by hidefromkgb (2010-09-20 11:12:52)

stephane · 2010-09-20 12:04:00

hidefromkgb wrote:

Is there any patch for 2.6.32-LTS kernel?

Yes, the following post on [arch-dev-public] contain a link to the patch :

http://mailman.archlinux.org/pipermail/ … 17956.html

Please be aware that this patch was not extensively tested . It might destroy your life

tvale · 2010-09-20 21:34:36

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

$$$ Kernel release: 2.6.35-ARCH
!!! Could not find symbol: per_cpu__current_task

A symbol required by the published exploit for CVE-2010-3081 is not
provided by your kernel.  The exploit would not work on your system.

LeeF · 2010-09-21 09:06:00

Just to update everyone, if you get the error setting the cred shellcodes, you don't have to worry, it means that the checker tool couldn't find the symbol in your kernel at all, so your system was not vulnerable in the first place.

@tvale I'm not sure why you got a different error, but at least yours gave you confirmation that your system isn't vulnerable. I wish I had gotten that error, would have saved me a lot of worrying for no reason.

I'm marking this topic as solved, and I'm finally going to be able to relax now, knowing that my system is safe(for now). Thanks to everyone who joined in on this.

kagerato · 2010-09-21 21:26:27

LeeF wrote:

Allan wrote:
I'll just point out, even with the original exploit (which did not leave a backdoor), you are still in trouble if someone has had root access to your system...
Which is exactly why I want to check if that backdoor is there... Call me paranoid, but you never can be too careful when your system stores sensitive information.
So, any thoughts gents?

Checking for a particular backdoor isn't sufficient verification if (a) you have reason to suspect compromise, and (b) sensitive or valuable information that must not be copied is available on the system.

Ideally, what you want for assurance is a verification of all system binaries -- new size against old size, new hash against old hash. There are tools which can do this, however generally they require that you run them ahead of time to store a database of the old hashes somewhere. That's not really of much use for this case, but for the future keep it in mind. Note that you if you're dealing with rootkits, you need to run this kind of tool off a read-only or other reliable media, or from an uncompromised system. Otherwise it's technically possible for the rootkit to interfere and provide false output in those or other programs.

As far as I know, Arch does not cryptographically sign its packages, nor store hashes in the archive which could be used as a reference. In which case, there's not much you can do for proper verification.

If you want to be really safe, reinstall the entire base filesystem from scratch or known-good media. Make sure to reset permissions to non-executable and proper ownership on anything you import or copy from an old home directory.

heftig · 2010-09-21 22:47:39

The original exploit didn't work here either (per_cpu__current_task missing) - but this one did: http://sota.gen.nz/compat2/robert_you_suck.c

LeeF · 2010-09-22 02:27:28

kagerato wrote:

LeeF wrote:
Allan wrote:
I'll just point out, even with the original exploit (which did not leave a backdoor), you are still in trouble if someone has had root access to your system...
Which is exactly why I want to check if that backdoor is there... Call me paranoid, but you never can be too careful when your system stores sensitive information.
So, any thoughts gents?
Checking for a particular backdoor isn't sufficient verification if (a) you have reason to suspect compromise, and (b) sensitive or valuable information that must not be copied is available on the system.
Ideally, what you want for assurance is a verification of all system binaries -- new size against old size, new hash against old hash. There are tools which can do this, however generally they require that you run them ahead of time to store a database of the old hashes somewhere. That's not really of much use for this case, but for the future keep it in mind. Note that you if you're dealing with rootkits, you need to run this kind of tool off a read-only or other reliable media, or from an uncompromised system. Otherwise it's technically possible for the rootkit to interfere and provide false output in those or other programs.
As far as I know, Arch does not cryptographically sign its packages, nor store hashes in the archive which could be used as a reference. In which case, there's not much you can do for proper verification.
If you want to be really safe, reinstall the entire base filesystem from scratch or known-good media. Make sure to reset permissions to non-executable and proper ownership on anything you import or copy from an old home directory.

Luckily I have no reason to suspect my system was compromised, this was purely proactive security.

heftig wrote:

The original exploit didn't work here either (per_cpu__current_task missing) - but this one did: http://sota.gen.nz/compat2/robert_you_suck.c

What output would we expect to see from this program if an exploit was exploitable? I got some output from it and I'm running the updated kernel, so I'm very interested in knowing about this.

combuster · 2010-09-22 10:09:21

No output, just gives you root shell

LeeF · 2010-09-22 10:48:31

combuster wrote:

No output, just gives you root shell

Perfect, thanks for that!

combuster · 2010-09-22 11:33:58

OMG sry, i haven't read your post carefully, I thought that you asked what output exploit gives

Dunno about this program, I have the same output as ppl above: Could not find symbol: per_cpu__current_task

I've disabled 32-bit support in kernel anyway, I really don't need it.

LeeF · 2010-09-22 15:10:30

So then what would this mean?

resolved symbol commit_creds to 0xffffffff81077f70
resolved symbol prepare_kernel_cred to 0xffffffff810783b0
mapping at 3f80000000
UID 502, EUID:502 GID:100, EGID:100

LeeF · 2010-09-26 23:16:28

LeeF wrote:

So then what would this mean?

resolved symbol commit_creds to 0xffffffff81077f70
resolved symbol prepare_kernel_cred to 0xffffffff810783b0
mapping at 3f80000000
UID 502, EUID:502 GID:100, EGID:100

Bit of an update... I just updated the my kernel to the latest version of the 2.6.35 series, and the message is almost the same, except the first two values are +16(now ending in 80 and c0, respectively), while the third value remains the same.

Arch Linux

#1 2010-09-20 08:39:06

64 bit root exploit checking tool

#2 2010-09-20 09:46:56

Re: 64 bit root exploit checking tool

#3 2010-09-20 09:51:12

Re: 64 bit root exploit checking tool

#4 2010-09-20 10:03:12

Re: 64 bit root exploit checking tool

#5 2010-09-20 10:07:56

Re: 64 bit root exploit checking tool

#6 2010-09-20 10:12:53

Re: 64 bit root exploit checking tool

#7 2010-09-20 10:16:11

Re: 64 bit root exploit checking tool

#8 2010-09-20 10:17:28

Re: 64 bit root exploit checking tool

#9 2010-09-20 10:19:01

Re: 64 bit root exploit checking tool

#10 2010-09-20 10:19:58

Re: 64 bit root exploit checking tool

#11 2010-09-20 10:32:13

Re: 64 bit root exploit checking tool

#12 2010-09-20 10:36:18

Re: 64 bit root exploit checking tool

#13 2010-09-20 10:39:05

Re: 64 bit root exploit checking tool

#14 2010-09-20 11:12:27

Re: 64 bit root exploit checking tool

#15 2010-09-20 12:04:00

Re: 64 bit root exploit checking tool

#16 2010-09-20 21:34:36

Re: 64 bit root exploit checking tool

#17 2010-09-21 09:06:00

Re: 64 bit root exploit checking tool

#18 2010-09-21 21:26:27

Re: 64 bit root exploit checking tool

#19 2010-09-21 22:47:39

Re: 64 bit root exploit checking tool

#20 2010-09-22 02:27:28

Re: 64 bit root exploit checking tool

#21 2010-09-22 10:09:21

Re: 64 bit root exploit checking tool

#22 2010-09-22 10:48:31

Re: 64 bit root exploit checking tool

#23 2010-09-22 11:33:58

Re: 64 bit root exploit checking tool

#24 2010-09-22 15:10:30

Re: 64 bit root exploit checking tool

#25 2010-09-26 23:16:28

Re: 64 bit root exploit checking tool

Board footer