4797366 2000-02-14 20:55 /106 rader/ Postmaster
Mottagare: Bugtraq (import) <9763>
Ärende: sshd and pop/ftponly users incorrect configuration
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <Pine.LNX.4.10.10002111717370.27486-100000@vulcan.alphanet.ch>
Date: Fri, 11 Feb 2000 17:18:31 +0100
Reply-To: Marc SCHAEFER <schaefer@ALPHANET.CH>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Marc SCHAEFER <schaefer@ALPHANET.CH>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
NAME
sshd-restricted-users-incorrect-configuration
AUTHOR
Marc SCHAEFER <schaefer@alphanet.ch>
Andreas Trottmann <andreas.trottmann@werft22.com>
THANKS
OpenBSD security team
VERSION
$Id: sshd-restricted-users-incorrect-configuration,v 1.2 2000/01/25 10:27:56 schaefer Exp $
ABSTRACT
In some cases where a system must be configured so that specific
users only have access to POP or FTP (or a specific restricted shell,
e.g. a BBS or lynx menu), the addition of the SSH protocol server
(sshd) may create a security hole. The user, if they try to access
the server per telnet succeed, but they are immediately thrown
out (because their shell is /bin/false, e.g.), or a special restricted
shell runs (e.g. they can change their passwd, etc). In that case,
using sshd may create a subtle security hole allowing those users to,
like normal users, use the SSH protocol to issue TCP connections coming
from the attacked host.
IMPACT
Any remote user with an account on the machine, even without real shell
access, may open a TCP connection which will:
- appear to be open from root@localhost (in the IDENT identd
protocol)
- be able to connect to any services which are not firewalled on
the loopback (even if they are firewalled or tcp_wrapper tcpd
protected from the outside).
- be able to connect to any remote machine from the attacked host,
the connection appearing to come from the attacked host with
a wrong IDENT (see above).
IMMUNE CONFIGURATIONS
You are immune to this problem if one (or more) of the following
is true:
- the group(s) where those users belong to is listed in
/etc/ssh/sshd_config or equivalent configuration file as
DenyGroups group1 group2 # etc
(this is the recommended setup)
- no user which has an account hasn't a shell (he will be able
to do the above, except the root@ IDENT, anyway, if he has a shell)
- your POP or FTP users do not authentify against the system
password database (/etc/{passwd|shadow}), but against a
private database and the user is locked in the system password
database (passwd -l).
- you only allow RSA authentification, and the users cannot modify
their ~/.ssh from e.g. FTP.
- you do not run sshd. Have TcpAllowForwarding to no in the
configuration file doesn't seem to work, since
it only denies -R style forwarding.
OPERATING SYSTEMS
UNIX
FIX
- There is no fix for the root@ IDENT bug for legitimate user.
This is presumably a bug in ssh-1.2.27 and OpenSSH 1.2.1 and
earlier releases: sshd should not do the forwarding as root but
as the user. Note that it has not been investigated if this could
create other problems. This bug is a long-standing known bug,
and also is due to the fact IDENT information was never supposed
to be trusted anyway.
- Put all ftponly and poponly users in specially identified groups with
DenyGroups ftponly poponly
This will fix the open-port-from-no-shell-user
- Or lock the user in the system password database and use a special
database for FTP and POP.
EXPLOIT
Please do not request exploit from the listed authors. Requests for
exploits will be ignored. A working exploit exists and has been
tested on current Linux distributions. It is possible that an
exploit be posted some time in the future (or that someone reads
this and does it by himself ...).
NOTES
This advisory is for information only. No warranty either expressed
or implied. Full disclosure and dissemination are allowed as long as
this advisory is published in full. No responsability will be taken
from abuse or lack of use of the information in this advisory.
(4797366) ------------------------------------------
4801659 2000-02-15 20:27 /42 rader/ Postmaster
Mottagare: Bugtraq (import) <9777>
Ärende: Re: sshd and pop/ftponly users incorrect configuration
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
X-Sender: cdi@animal.blarg.net
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.3.95.1000214142352.22941A-100000@animal.blarg.net>
Date: Mon, 14 Feb 2000 14:26:51 -0800
Reply-To: CDI <cdi@THEWEBMASTERS.NET>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: CDI <cdi@THEWEBMASTERS.NET>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.4.10.10002111717370.27486-100000@vulcan.alphanet.ch>
On Fri, 11 Feb 2000, Marc SCHAEFER wrote:
> NAME
> sshd-restricted-users-incorrect-configuration
>
[snip]
> IMMUNE CONFIGURATIONS
> You are immune to this problem if one (or more) of the following
> is true:
>
> - the group(s) where those users belong to is listed in
> /etc/ssh/sshd_config or equivalent configuration file as
> DenyGroups group1 group2 # etc
> (this is the recommended setup)
Just a quick note - it's much more accurate (not to mention secure)
to use 'AllowGroups' rather than DenyGroups. If AllowGroups is set,
then only if a users primary group matches one of the specified group
names are they permitted to complete a connection attempt.
____________________________________ The Web Master's Net
http://www.thewebmasters.net/ Today's Excuse: Someone is standing on
the ethernet cable, causeing a kink in the cable
(4801659) ------------------------------------------(Ombruten)
4802132 2000-02-15 22:33 /40 rader/ Postmaster
Mottagare: Bugtraq (import) <9788>
Ärende: Re: sshd and pop/ftponly users incorrect configuration
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <Pine.LNX.4.10.10002151539030.23676-100000@vulcan.alphanet.ch>
Date: Tue, 15 Feb 2000 15:44:08 +0100
Reply-To: Marc SCHAEFER <schaefer@ALPHANET.CH>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Marc SCHAEFER <schaefer@ALPHANET.CH>
X-To: Nick Lamb <njl98r@ecs.soton.ac.uk>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20000215004333.A16931@ecs.soton.ac.uk>
On Tue, 15 Feb 2000, Nick Lamb wrote:
> 1. Is this a bug (which will be or has already been fixed in OpenSSH)
it's a bug, a feature, and a misconfiguration. The bug is SSH issuing
local redirecting connections with root. This was presumably fixed in
OpenSSH. The feature allowing to open connections coming from
localhost for valid (with a shell) users is a feature, and the
misconfiguration is forgetting DenyGroups on users supposing not to
be able to log in except e.g. for mail.
The real issue is however the common misconception that setting
/bin/false to a user shell to prevent it to login while still
allowing reading POP mail and FTP is enough to prevent the user from
issuing local-issued connections to services. The impact is clear:
bypassing firewalling, or hosts.deny. Additionnally it will create
fake IDENT (but that's a ssh feature, it seems).
> 2. Does PAM provide any immunity? If the user should be locked out
> of SSH by PAM (as in the Linux OpenSSH ports) then will this
If the user is refused by ssh authentification (be it because it's
firewalled, DenyGroupsed, invalid password or PAM), you are safe.
Noone we talk about breaking passworded accounts.
(4802132) ------------------------------------------(Ombruten)
4802516 2000-02-16 00:11 /19 rader/ Postmaster
Mottagare: Bugtraq (import) <9795>
Ärende: Re: sshd and pop/ftponly users incorrect configuration
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200002151337.GAA07952@cvs.openbsd.org>
Date: Tue, 15 Feb 2000 06:37:23 -0700
Reply-To: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
X-To: Marc SCHAEFER <schaefer@ALPHANET.CH>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of "Fri, 11 Feb 2000 17:18:31 +0100."
<Pine.LNX.4.10.10002111717370.27486-100000@vulcan.alphanet.ch>
This is not an ssh security issue.
This is because you are trusting the ident/auth protocol.
Don't do that.
(4802516) ------------------------------------------