Flaw in most Linux kernel allows attack

To reset all users to use a false shell (vs sh, bash, csh, etc) on most Linux platforms:

type who and see which users are currently running a shell

another way would be to type ps aux | grep sh and then see which shells were active.

look in /etc/passwd for the default shells for your users

copy whatever shells you have on your machine into /root (cp /bin/*sh* /root)

edit your /etc/passwd file to point to /root/(your shell here) for the root user

log out and login as root using the new shell located in the root directory

remove all the shell files in /bin (rm /bin/*sh*)

change directory to /bin (cd /bin

symbolicly (sp?) link the file false to also be bash, sh, ash, bash2, etc.
Whatever files you copied out of the /bin directory that your users could use as a shell.
ln -s /bin/false /bin/bash
ln -s /bin/false /bin/sh
ln -s ... etc.


then do a killall bash && killall sh && killall csh && killall tcsh, etc. and you are now clean.
(i didn't do a killall *sh* because I didn't want to kill a sshd session if you are doing this remotely)


no-one can have a shell but root.

Then you can do a kernel upgrade/patch (I am using 2.6.0-test11 and it is EXTREMELY stable and a much faster kernel) knowing that you are the only user with access.

It is also a good idea to be sure that any unprivileged accounts (ftp, nobody, etc) are already using /bin/false as their shell. Some people install a SQL server and create an account without realizing that they should lock that account down, in case they ever set the password on that account in error.

Anyway, I made this howto a bit simplistic, but I hope it explains the process well enough.
PLEASE do not delete any shells before you login as root into the correct shell located in /root

Have fun.


{edit}

Whups. once everything is all set, delete all the shell links in /bin (rm /bin/*sh*)
then copy the real shells in /root to /bin (cp /root/*sh* /bin)

then everyone will have access again.

enjoy.

Thanks for the info turning machine.


Also Slarty I have attached a proof of concept that i found somewhere.



..Also the exploit require that you have some specific version nasm (9.something?)

I think this just goes to show that linux/open source developers are not the all mighty security gods that people preaching the open source mantra would have you believe.

Sniffing passwords with a keylogger is a pretty old trick. Kind of hard to believe that one of these oh so security conscious open source developers fell pray to such a simple attack.

Interesting take on what you have read. In fact, as someone who does look though the kernel source and tries to make things better when he can, I can honestly say that I did not understand the issue at first.

As I have looked at the source, and looked at the proof-of-concept exploit, I can say that, in retrospect, it was a bug that should have been fixed. In fact, it was. In September. But as it requires that a CURRENT and VALIDATED user with a SHELL on the system run the system call in question to START the process, it was deemed too small a security risk to pursue.

Now that should have been addressed at the time. I agree. But the way that risks are assessed are highest to the remote and unauthenticated, then local and unauthenticated, then authenticated without shell (ftp, etc), then shell accounts last, as OBVIOUSLY, no admin will be giving shells out without knowledge of the user, etc.

Now, if such a user DID decide to try to use this, they would FIRST be required to have the correct libraries installed on the machine. Its pretty common, but access to those system libraries is an option that a cautious admin would limit.

THEN they would be required to be able to compile the file. Again, not a common permission given out by admins, especially to anyone not an active developer on the box.

THEN they would have to run the program and THEN hope that the admin didn't notice the newly compiled file and check it, etc.

P.S. I assume by your comment you have a basic understanding of this expolit and how it accesses the kernel, etc. If not, I apologise for the tone of this message. I find it more annoying when someone understands the issue and exaggerates it than when someone reads an article and feels they are qualified to comment on the entire process while being more or less ignorant to the workings of what they comment on.

{edit}
here is the code if you want to look though it. It is not the most difficult code. In fact, it is a very straight-forward function.

have fun

turing- My comment was not about the exploit at all. I was commenting on the article which stated that access to the developer account on the debian machine was gained when the attacker broke into the developers machine and put a keylogger on the machine. The attacker then gained the account/password to the debian development machine which is when the actual "new" exploit was used to elevate privileges on the debian development machine.

The article did not at all discuss how the developers machine was broken into, but the fact that that break-in was not discovered until after sensitive passwords had been gained does not speak well for the security skills of that particular debian developer.

Which is all that I was calling into question. One of the key arguments that open source propenents like to use is that open source developers understand security issues better, and are more committed to developing secure software as they have more at stake. This instance shows that that is not always the case.

Quote:

---

Originally posted here by gore
Korp you know I gotta bust your balls a lil bit since you havn't been on in forever ;)

http://www.antioffline.com/freebsd.html

;)

On the other hand:

http://wwws.sun.com/software/solaris/trustedsolaris/

I want that^

---

Cute Gore. I got a really big laugh out of that. Gotta spread my points around before I give them to again. :thumbsup:

Gotta love everything from antioffline. If nothing else, they hold nothing sacred. I have to give them credit for that. pfftt.

BTW- I wouldn't load an OS that cant recognize ANY of my hardware devices. Like solaris.

If all I did was develop for SUn then yeah I'd load it but since I have something important to do with my life, NAW, I don't think so!!!

Quote:

---

Originally posted here by gore
Korp you know I gotta bust your balls a lil bit since you havn't been on in forever ;)

http://www.antioffline.com/freebsd.html

;)

On the other hand:

http://wwws.sun.com/software/solaris/trustedsolaris/

I want that^

---

Trusted Solaris is really nice. Depending on whether you want SE or CE, be prepaired to spend some serious
green on licensing.

Quote:

---

Originally posted by KorpDeath
BTW- I wouldn't load an OS that cant recognize ANY of my hardware devices. Like solaris.

---

I've never actually had this problem on Sun hardware. The x86 version is pure crap, and I would not be
surprised to hear of these kinds of problems with it.

-- spurious