[SOLVED] lsroot local exploit *Old Bug, but still Applied*

willysr · 04-01-2011, 07:47 PM

One of Indonesian Slackware Community mailing list member posted a link in our mailing list and it contains an old bug since 2004 and he asked to be tested on -Current since he is not using -Current.

I tested on -Current and yes it still applies on my machine (32 bit). Does it still applies on 64 bit system as well?

The code is in here.

I tried to run as normal user account and i turned into root for few seconds and then my computer hang and i had to turn it off by pressing the power button

NoStressHQ · 04-01-2011, 09:50 PM

I had a look at the code, it seems it "simply" creates a shared library named "own.so" which export

Code:

int getuid() { return 0; }
int geteuid() { return 0; }
int getgid() { return 0; }
int getegid() { return 0; }

It's like if it was masking standard system API call forcing a "super user" state... I haven't checked too long...

What I don't understand is that the generated source file is appended with /bin/sh... Dunno if it's really part of the exploit, I would expect gcc to stop on the \0 prefix (as a normal c string)...

disturbed1 · 04-01-2011, 09:52 PM

Why would you post this?

That's an old trick for gullible people. It's not a bug, the program does not run as root, it's just a fork bomb.

Amazes me how some people would download, and execute untrusted, unverified code. Acts like this is why other operating systems are a haven for virus, spyware, and malware.

niels.horn · 04-01-2011, 10:01 PM

Yes, this is old... And - sorry to say - silly...
If it were really an exploit, why hide it this much?
I would never trust this the way it is.

But it is not an exploit, you won't get any root access with this...

NoStressHQ · 04-01-2011, 10:13 PM

Yeah that's what I suspected... I just watch the code (I don't run blindly this kind of shit), and was wondering where the exploit was, as I couldn't understand how this could effectively give any access to anything...

Anyway, "any" executable could be some exploit if you don't trust the source... The best protection against this kind of stuff is not to launch anything you don't know AND trust... As always, the biggest security weakness is the user in front of the machine

And as disturbed1 and Neils said, if it was intended to be an exploit it's quite a cheap stuff or an epic fail for a hacker wannabe...

niels.horn · 04-01-2011, 10:28 PM

Yeah, this is "an old trick in the book"...
By preloading the fabricated shared-object (own.so) it replaces the normal system calls to "getuid", "getgid" with a simple "0" - where "0" normally means root.
So the shell that is called asks the UID of the user and receives "0" in return. That's why it displays "root".

But any further system calls will fail, as the user is not really root after all.

Like I said: old and silly...

Willy: Sorry to say, but who sent this is either, eh, a "noob" or has bad intentions...

A real exploit would not be hidden in a silly way and would show how it was done.
And please, don't ever run scripts like this without knowing exactly what you're doing. The next one might contain code to wipe your root partition...

willysr · 04-02-2011, 03:17 AM

i think he also didn't know about this either, that's why he posted this

rg3 · 04-02-2011, 03:48 AM

While we're on topic here, a good way to protect yourself against fork bombs is to do the following:

Code:

cat >/etc/profile.d/_ulimit.sh <<EOF
#!/bin/sh
ulimit -u 512
EOF

cat >/etc/profile.d/_ulimit.csh <<EOF
#!/bin/csh
limit maxproc 512
EOF

chmod +x /etc/profile.d/_ulimit.*

Systems running PAM use other methods, and this can also be set from /etc/limits but then it doesn't always work. Provided your bourne shells support the "ulimit" command, and that your C shell supports the "limit" command, this should restrict the impact of a fork bomb no matter how you log in to the system. I haven't tried with SSH, though.