exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New


Posted Feb 16, 2000
Authored by Marc Schaefer

In some cases where a system must be configured so that specific users only have access to POP, FTP, or restricted shell, the addition of the SSH protocol server (sshd) may create a security hole allowing the user to make tcp connections appearing to be from root at the attacked host.

tags | exploit, shell, root, tcp, protocol
SHA-256 | b2f8217f0471c597f8b0ac1f18a5b0315b75631438e85a978bfca358a4096d15


Change Mirror Download

Marc SCHAEFER <schaefer@alphanet.ch>
Andreas Trottmann <andreas.trottmann@werft22.com>

OpenBSD security team

$Id: sshd-restricted-users-incorrect-configuration,v 1.2 2000/01/25 10:27:56 schaefer Exp $

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.

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

- 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).

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.


- 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.

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 ...).

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.

Login or Register to add favorites

File Archive:

February 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Feb 1st
    16 Files
  • 2
    Feb 2nd
    19 Files
  • 3
    Feb 3rd
    0 Files
  • 4
    Feb 4th
    0 Files
  • 5
    Feb 5th
    24 Files
  • 6
    Feb 6th
    2 Files
  • 7
    Feb 7th
    10 Files
  • 8
    Feb 8th
    25 Files
  • 9
    Feb 9th
    37 Files
  • 10
    Feb 10th
    0 Files
  • 11
    Feb 11th
    0 Files
  • 12
    Feb 12th
    17 Files
  • 13
    Feb 13th
    20 Files
  • 14
    Feb 14th
    25 Files
  • 15
    Feb 15th
    15 Files
  • 16
    Feb 16th
    6 Files
  • 17
    Feb 17th
    0 Files
  • 18
    Feb 18th
    0 Files
  • 19
    Feb 19th
    35 Files
  • 20
    Feb 20th
    25 Files
  • 21
    Feb 21st
    18 Files
  • 22
    Feb 22nd
    15 Files
  • 23
    Feb 23rd
    0 Files
  • 24
    Feb 24th
    10 Files
  • 25
    Feb 25th
    0 Files
  • 26
    Feb 26th
    37 Files
  • 27
    Feb 27th
    34 Files
  • 28
    Feb 28th
    27 Files
  • 29
    Feb 29th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By