sshd.locked-accts.txt

`NAME  
sshd-restricted-users-incorrect-configuration  
  
AUTHOR  
Marc SCHAEFER <[email protected]>  
Andreas Trottmann <[email protected]>  
  
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.  
  
  
`