Does anybody know which mailing list addresses security issues? Logwatch on my server reported this:
apache logged in from dsl-82-199-133-138.dutchdsl.nl (82.199.133.138) using password: 1 Time(s)
My apache account is active so I can su to it to administer postgresql databases accessable via php scripts. No password is set. It was my understanding that it would be impossible to log in except via su from root. Either I'm dead wrong or there's a security hole which needs fixed.
thanks Scott Becker
On Mon, Feb 14, 2005 at 09:25:43AM -0800, Scott Becker wrote:
Does anybody know which mailing list addresses security issues?
fedora-list is best for this in general. But there is a "-devel" issue here.....
Logwatch on my server reported this: apache logged in from dsl-82-199-133-138.dutchdsl.nl (82.199.133.138) using password: 1 Time(s) My apache account is active so I can su to it to administer postgresql databases accessable via php scripts. No password is set. It was my understanding that it would be impossible to log in except via su from root. Either I'm dead wrong or there's a security hole which needs fixed.
I think the problem here is that you're dead wrong. If no password is set and the account isn't locked, anyone can log in. Make sure the account is locked.
For this reason, I apply the following patch to authconfig, to make the default configuration disallow logins with null passwords. I think it'd be a good idea to make this be the default, in fact. People who really want empty passwords should have to do this to themselves.
--- ../authconfig-4.1.6.orig/authinfo.c Wed Aug 29 14:26:40 2001 +++ ./authinfo.c Wed Aug 29 14:29:46 2001 @@ -2061,9 +2061,7 @@ static const char *argv_unix_auth[] = { "likeauth", - "nullok", NULL, }; static const char *argv_unix_password[] = { - "nullok", "use_authtok", NULL,
Hi.
Scott Becker scottb@bxwa.com wrote:
My apache account is active so I can su to it to administer postgresql databases accessable via php scripts.
You do not need a password for that, or change anything about the account.
"sudo -u apache" (as normal user) or just "su -m apache" (as root) ought to do the job.
On Mon, Feb 14, 2005 at 07:28:57PM +0100, Ralf Ertzinger wrote:
Hi.
Scott Becker scottb@bxwa.com wrote:
My apache account is active so I can su to it to administer postgresql databases accessable via php scripts.
You do not need a password for that, or change anything about the account.
"sudo -u apache" (as normal user) or just "su -m apache" (as root) ought to do the job.
Or just psql -U apache.
And login with empty passwords can be disabled by removing nullok from /etc/pam.d/system-auth.
-- "Your reality, sir, is lies and balderdash and I am delighted to say that I have no grasp of it whatsoever." -- Baron Munchausen
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
On Mon, Feb 14, 2005 at 18:35:01 +0000, Luciano Miguel Ferreira Rocha strange@nsk.no-ip.org wrote:
Or just psql -U apache.
If you go that route, you can set up ident authentication for postgres so that this command will work from your normal user account, without having to switch to root first or supply an additional password.
I started with the default apache user and ran the following commands:
#bring up apache account- mkdir /home/apache cp /etc/skel/.* /home/apache chown -R apache: /home/apache usermod -d /home/apache apache usermod -s /bin/bash apache
This way I can access it with a simple 'su apache' command ran as root and there's a home directory to store the .psql_history file so the command history is saved across sessions. I fear that by setting the shell with 'usermod -s /bin/bash apache' I've opened a can of worms. I just set a password on the account to prevent any more logins but if there's a security hole it would be nice to fix it and if not I would like to know how they logged in and understand the process. I tried (just before setting the password) to login hitting enter for the password and I couldn't get in.
Luciano Miguel Ferreira Rocha wrote:
And login with empty passwords can be disabled by removing nullok from /etc/pam.d/system-auth.
I found nullok twice in the file. Perhaps I couldn't get in on my test because PuTTY doesn't pass null. I guess I shall always set a password from now on.
thanks all scottb
Ralf Ertzinger wrote:
Hi.
Scott Becker scottb@bxwa.com wrote:
My apache account is active so I can su to it to administer postgresql databases accessable via php scripts.
You do not need a password for that, or change anything about the account.
"sudo -u apache" (as normal user) or just "su -m apache" (as root) ought to do the job.
On Mon, 2005-02-14 at 10:57 -0800, Scott Becker wrote:
I started with the default apache user and ran the following commands:
#bring up apache account- mkdir /home/apache cp /etc/skel/.* /home/apache chown -R apache: /home/apache usermod -d /home/apache apache usermod -s /bin/bash apache
This way I can access it with a simple 'su apache' command ran as root and there's a home directory to store the .psql_history file so the command history is saved across sessions. I fear that by setting the shell with 'usermod -s /bin/bash apache' I've opened a can of worms. I just set a password on the account to prevent any more logins but if there's a security hole it would be nice to fix it and if not I would like to know how they logged in and understand the process. I tried (just before setting the password) to login hitting enter for the password and I couldn't get in.
....
I found nullok twice in the file. Perhaps I couldn't get in on my test because PuTTY doesn't pass null. I guess I shall always set a password from now on.
What does 'getent shadow apache' gives you if you call it from root account? If it's something like: apache:!!:xxxxx:::::: ^^ note these. If the exclamation marks are missing it means that this account is without a password and nullok allows to login to it. But if the !! (or *) is there it means something is broken on your system if it allowed login to that account. Can you find the messages from the /var/log/ surrounding the 'apache logged in from dsl-82-199-133-138.dutchdsl.nl (82.199.133.138)' message?
I've already set a proper password but on a twin testing machine the !!s are there, before and after running my setup commands to change the shell. Here's the top of message with the login and logout lines:
Feb 13 04:05:24 backup syslogd 1.4.1: restart. Feb 13 05:39:25 backup named[31607]: lame server resolving '191.236.191.211.in-addr.arpa' (in '236.191.211.in-addr.arpa'?): 203.251.201.1#53 Feb 13 05:45:51 backup named[31607]: lame server resolving '201.32.110.61.in-addr.arpa' (in '32.110.61.in-addr.arpa'?): 203.240.193.11#53 Feb 13 05:45:51 backup named[31607]: lame server resolving '201.32.110.61.in-addr.arpa' (in '32.110.61.in-addr.arpa'?): 203.251.201.1#53 Feb 13 06:36:09 backup sshd(pam_unix)[422]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=dsl-82-199-133-138.dutchdsl.nl user=apache Feb 13 06:36:17 backup sshd(pam_unix)[425]: session opened for user apache by (uid=48) Feb 13 06:53:58 backup named[31607]: lame server resolving '173.4.248.61.in-addr.arpa' (in '4.248.61.in-addr.arpa'?): 203.240.193.11#53 Feb 13 06:53:58 backup named[31607]: lame server resolving '173.4.248.61.in-addr.arpa' (in '4.248.61.in-addr.arpa'?): 203.251.201.1#53 Feb 13 07:00:44 backup sshd(pam_unix)[425]: session closed for user apache Feb 13 07:39:19 backup sshd(pam_unix)[710]: check pass; user unknown Feb 13 07:39:19 backup sshd(pam_unix)[710]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 Feb 13 07:39:23 backup sshd(pam_unix)[713]: check pass; user unknown Feb 13 07:39:23 backup sshd(pam_unix)[713]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 Feb 13 07:39:27 backup sshd(pam_unix)[715]: check pass; user unknown Feb 13 07:39:27 backup sshd(pam_unix)[715]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 Feb 13 07:39:31 backup sshd(pam_unix)[717]: check pass; user unknown Feb 13 07:39:31 backup sshd(pam_unix)[717]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 Feb 13 07:39:34 backup sshd(pam_unix)[720]: check pass; user unknown Feb 13 07:39:34 backup sshd(pam_unix)[720]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 Feb 13 07:39:38 backup sshd(pam_unix)[722]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 user=root Feb 13 07:39:42 backup sshd(pam_unix)[724]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 user=root Feb 13 07:39:46 backup sshd(pam_unix)[726]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 user=root
One failed attempt, one successful attempt and a logout 24 minutes later.
scottb
Tomas Mraz wrote:
On Mon, 2005-02-14 at 10:57 -0800, Scott Becker wrote:
What does 'getent shadow apache' gives you if you call it from root account? If it's something like: apache:!!:xxxxx:::::: ^^ note these. If the exclamation marks are missing it means that this account is without a password and nullok allows to login to it. But if the !! (or *) is there it means something is broken on your system if it allowed login to that account. Can you find the messages from the /var/log/ surrounding the 'apache logged in from dsl-82-199-133-138.dutchdsl.nl (82.199.133.138)' message?
On Tue, 2005-02-15 at 14:11 -0800, Scott Becker wrote:
I've already set a proper password but on a twin testing machine the !!s are there, before and after running my setup commands to change the shell. Here's the top of message with the login and logout lines: Feb 13 06:36:09 backup sshd(pam_unix)[422]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=dsl-82-199-133-138.dutchdsl.nl user=apache Feb 13 06:36:17 backup sshd(pam_unix)[425]: session opened for user apache by (uid=48) Feb 13 06:53:58 backup named[31607]: lame server resolving '173.4.248.61.in-addr.arpa' (in '4.248.61.in-addr.arpa'?): 203.240.193.11#53 Feb 13 06:53:58 backup named[31607]: lame server resolving '173.4.248.61.in-addr.arpa' (in '4.248.61.in-addr.arpa'?): 203.251.201.1#53 Feb 13 07:00:44 backup sshd(pam_unix)[425]: session closed for user apache
The problem is that I don't see how anyone could login using ssh to account with !! in /etc/shadow. I have to suppose that there were nothing instead of !! and then the login could succeed - the attacker would first try no password which wouldn't be allowed if PermitEmptyPassword is set to 'no' in /etc/ssh/sshd_config and then he would try any password and he would be allowed in. What versions of pam and openssh do you have?
<snip>
The problem is that I don't see how anyone could login using ssh to account with !! in /etc/shadow. I have to suppose that there were
three words, ssh pubkey authentication.
<snip>
On Wed, 2005-02-16 at 08:37 -0500, Richard June wrote:
<snip> > The problem is that I don't see how anyone could login using ssh to > account with !! in /etc/shadow. I have to suppose that there were three words, ssh pubkey authentication.
This doesn't apply as the attacker would have to have the ssh private key of a public key which would have to be installed in the ~apache/.ssh/authorized_keys what I don't suppose. However I've been mistaken with the /etc/shadow - the real thing is in the /etc/passwd line - if the second field is empty (no 'x' there) that means the password is empty and sshd would allow logging in.
On Wednesday 16 February 2005 09:04, Tomas Mraz wrote:
On Wed, 2005-02-16 at 08:37 -0500, Richard June wrote:
<snip>
The problem is that I don't see how anyone could login using ssh to account with !! in /etc/shadow. I have to suppose that there were
three words, ssh pubkey authentication.
This doesn't apply as the attacker would have to have the ssh private key of a public key which would have to be installed in the ~apache/.ssh/authorized_keys what I don't suppose. However I've been mistaken with the /etc/shadow - the real thing is in the /etc/passwd line - if the second field is empty (no 'x' there) that means the password is empty and sshd would allow logging in.
Default config is for ssh to not allow emtpy passwords to login *AND* to put either x or !! into the passwd field in /etc/passwd. Thus for sshd to allow sombody to log in like that, the user (or the attacker through some other means) would have to edit /etc/passwd, and enable empty passwords in sshd_config, and restart ssh(though if you have the first two done, the last should be simple) and in the event of users such as apache, you have to change the shell from /bin/false to /bin/bash or something.
devel@lists.stg.fedoraproject.org
-
Bruno Wolff III -
Luciano Miguel Ferreira Rocha -
Matthew Miller -
Ralf Ertzinger -
Richard June -
Scott Becker -
Tomas Mraz