Able to Locally Login as Root with ANY password??
Found a major security hole in one of my more crucial linux servers today. (Only locally) I can use the user name "root" and any string for the password. So I can literally type "poop" as the password and the server lets me in.
I know how to set root password settings for SSH and sudo, but where are settings located for local access that would allow something like this?? Thanks, Dan |
It depends on how do you access. Usually, nowadays, this is via pam on most regular distros. So, it's probably the pam config what you should be looking at.
|
Moved: This thread is more suitable in Linux-Security and has been moved accordingly to help your thread/question get the exposure it deserves.
|
Look first into /etc/passwd. There should be an entry for root (first column). It should start from
root:x The 'x' means that there's a password in /etc/shadow. /etc/shadow should also have an entry for root, something starting from root:somestring: 'somestring' is the password (not in plain form). |
There's definitely a password for root, and it's used for everything else (SSH, Sudo, Su -, etc.).
I'm looking at PAM and I'm not sure what might be out of place... |
Code:
[root@linadmin1 pam.d]# cat login Code:
[root@linadmin1 pam.d]# cat system-auth |
Code:
auth sufficient pam_unix.so nullok_secure And you thought Debian wasn't meant to be awful? http://www.redhat.com/archives/pam-l.../msg00001.html |
Goodness gracious. Gotta love these obscure, poorly documented options.
|
I read that article earlier this morning, it left me even more confused!
I tried to test this by creating a test account, and actually the system denies access to both good and bad passwords. Ok, so it appears that is a separate issue. I just now tested this theory on another system that was having the same original problem, and changing the auth parameters to: Code:
auth required pam_env.so OK, so if I merely changed Code:
auth sufficient pam_unix.so nullok_secure Code:
auth sufficient pam_unix.so and Code:
auth required pam_unix.so So adding pam_deny.so allows for both sufficient modules but denies invalid password entries. OK OK, so this is where I'm left feeling confused: I was looking for the answer in the "password" module... why does the "auth" module have anything to do with verifying the password of an account?? |
that's an obscure issue indeed
I was recently studying this specific subject for my RHCE RH302 test. Quoting Michael Jang's book, RHCE Linux Study Guide(fifth edition), page 306:
"Authentication management(auth): Establishes the identity of the user [...] a PAM auth module command decides whether to prompt for a username and/or password." |
What distribution are we talking about? And is this the default setup?
|
CentOS 5.4 yes, I believe it's the default set up. I've never made any modifications to PAM myself. Can anyone confirm this?
What I did notice today was the only servers that had this PAM configuration were those running as virtualized guests on an ESXi server... |
Quote:
|
default setup
Hello:
That is NOT the default with CentOS 5.4. I recently redid one of servers from scratch with CentOS 5.4 Here is how my file looks like: (KEEP READING AFTER IT) -------------------------------------------------------------- [root@hostname pam.d]$ cat system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so account required pam_unix.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so ------------------------------------------------------------- Notice the "try_first_pass" ending the second line. Referring to Michael Jang's book once again, it seems that this argument to the "auth" command "allows the use of a previous successful password." But if that is the case, why my system works ok then? Weird ... now I have questions lol I hope no hard issues about this in the test :-/ |
Ok, I figured out that the system-auth file was copied on install from a central config repository on my network - explains why all the newest servers are setup this way.
@amonamarth Maybe the try_first_pass option causes +1 failed attempts and could cause issues if you set an account to lock out after so many tries? That's my educated guess. Quote:
****I'm still confused on this last point. If this is my auth module stack, then if the root password is incorrect, it should be passed to pam_krb5.so which by the "requisite" (or "required") flag should terminate the login attempt. Code:
auth required pam_env.so Quote:
Anyone have any ideas? Thanks :) |
All times are GMT -5. The time now is 09:17 PM. |