Debian Bug report logs - #586480
openssh-server: chroot directive is not working when using FISH (File transfer of shell with midnight commander)

version graph

Package: openssh-server; Maintainer for openssh-server is Debian OpenSSH Maintainers <debian-ssh@lists.debian.org>; Source for openssh-server is src:openssh.

Reported by: Andre Rodier <andre.rodier@gmail.com>

Date: Sat, 19 Jun 2010 21:42:02 UTC

Severity: critical

Tags: moreinfo, security

Found in version openssh/1:5.1p1-5

Done: Stefan Fritsch <sf@sfritsch.de>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, andre.rodier@red2.co.uk, team@security.debian.org, secure-testing-team@lists.alioth.debian.org, Debian OpenSSH Maintainers <debian-ssh@lists.debian.org>:
Bug#586480; Package openssh-server. (Sat, 19 Jun 2010 21:42:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andre Rodier <andre.rodier@gmail.com>:
New Bug report received and forwarded. Copy sent to andre.rodier@red2.co.uk, team@security.debian.org, secure-testing-team@lists.alioth.debian.org, Debian OpenSSH Maintainers <debian-ssh@lists.debian.org>. (Sat, 19 Jun 2010 21:42:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Andre Rodier <andre.rodier@gmail.com>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: openssh-server: chroot directive is not working when using FISH (File transfer of shell with midnight commander)
Date: Sat, 19 Jun 2010 22:30:44 +0100
Package: openssh-server
Version: 1:5.1p1-5
Severity: critical
Tags: security
Justification: root security hole

Hello,

I have successfully configured my ssh server to chroot users, by followinf the directives described here:
http://www.debian-administration.org/articles/590 ie. OpenSSH SFTP chroot() with ChrootDirectory

The chroot option seems to work well when I use the sftp command, ie I cannot see any directory at all.

However, if I use the fish protocol [1] included in midnight commander, I can see the full filesystem hierarchy,
and even transfer files from the etc folder, etc...

I don't know if it's a configuration problem on my side, but if there is an option do disallow fish
when using chroot, that need to be explicitly specified. Otherwise, debian users may relay
on a chrooted server that can be bypassed by a simple manipulation...


[1] http://en.wikipedia.org/wiki/Files_transferred_over_shell_protocol

Kind regards,
André Rodier.

Here my ssh config: See the end for chroot config

-----8<------------------------------------------------------------
# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel DEBUG

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile	%h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

UsePAM no
UseDNS no

#ChrootDirectory 
# Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp
Match group sftponly
        ChrootDirectory /home/%u
        X11Forwarding no
        AllowTcpForwarding no
	AllowAgentForwarding no
        ForceCommand internal-sftp
-----8<------------------------------------------------------------

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages openssh-server depends on:
ii  adduser         3.110                    add and remove users and groups
ii  debconf [debcon 1.5.24                   Debian configuration management sy
ii  dpkg            1.14.29                  Debian package management system
ii  libc6           2.7-18lenny4             GNU C Library: Shared libraries
ii  libcomerr2      1.41.3-1                 common error description library
ii  libkrb53        1.6.dfsg.4~beta1-5lenny4 MIT Kerberos runtime libraries
ii  libpam-modules  1.0.1-5+lenny1           Pluggable Authentication Modules f
ii  libpam-runtime  1.0.1-5+lenny1           Runtime support for the PAM librar
ii  libpam0g        1.0.1-5+lenny1           Pluggable Authentication Modules l
ii  libselinux1     2.0.65-5                 SELinux shared libraries
ii  libssl0.9.8     0.9.8g-15+lenny6         SSL shared libraries
ii  libwrap0        7.6.q-16                 Wietse Venema's TCP wrappers libra
ii  lsb-base        3.2-20                   Linux Standard Base 3.2 init scrip
ii  openssh-blackli 0.4.1                    list of default blacklisted OpenSS
ii  openssh-client  1:5.1p1-5                secure shell client, an rlogin/rsh
ii  procps          1:3.2.7-11               /proc file system utilities
ii  zlib1g          1:1.2.3.3.dfsg-12        compression library - runtime

Versions of packages openssh-server recommends:
pn  openssh-blacklist-extra       <none>     (no description available)
pn  xauth                         <none>     (no description available)

Versions of packages openssh-server suggests:
pn  molly-guard                   <none>     (no description available)
pn  rssh                          <none>     (no description available)
pn  ssh-askpass                   <none>     (no description available)

-- debconf information:
  ssh/vulnerable_host_keys:
  ssh/new_config: true
* ssh/use_old_init_script: true
  ssh/encrypted_host_key_but_no_keygen:
  ssh/disable_cr_auth: false




Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenSSH Maintainers <debian-ssh@lists.debian.org>:
Bug#586480; Package openssh-server. (Sun, 20 Jun 2010 07:39:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefan Fritsch <sf@sfritsch.de>:
Extra info received and forwarded to list. Copy sent to Debian OpenSSH Maintainers <debian-ssh@lists.debian.org>. (Sun, 20 Jun 2010 07:39:06 GMT) Full text and rfc822 format available.

Message #10 received at 586480@bugs.debian.org (full text, mbox):

From: Stefan Fritsch <sf@sfritsch.de>
To: Andre Rodier <andre.rodier@gmail.com>
Cc: 586480@bugs.debian.org
Subject: Re: Bug#586480: openssh-server: chroot directive is not working when using FISH (File transfer of shell with midnight commander)
Date: Sun, 20 Jun 2010 09:32:07 +0200
On Saturday 19 June 2010, you wrote:
> However, if I use the fish protocol [1] included in midnight
> commander, I can see the full filesystem hierarchy, and even
> transfer files from the etc folder, etc...


> Subsystem sftp internal-sftp
> Match group sftponly
>         ChrootDirectory /home/%u
>         X11Forwarding no
>         AllowTcpForwarding no
> 	AllowAgentForwarding no
>         ForceCommand internal-sftp


fish does not work at all with ForceCommand and it won't work with 
ChrootDirectory unless you copy lots of things into the chroot (/lib 
/bin ...).

Have you used the same user for your fish and sftp tests? Please 
verify in /var/log/auth.log that you really did.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenSSH Maintainers <debian-ssh@lists.debian.org>:
Bug#586480; Package openssh-server. (Sun, 20 Jun 2010 08:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andre Rodier <andre.rodier@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian OpenSSH Maintainers <debian-ssh@lists.debian.org>. (Sun, 20 Jun 2010 08:21:05 GMT) Full text and rfc822 format available.

Message #15 received at 586480@bugs.debian.org (full text, mbox):

From: Andre Rodier <andre.rodier@gmail.com>
To: Stefan Fritsch <sf@sfritsch.de>
Cc: 586480@bugs.debian.org
Subject: Re: Bug#586480: openssh-server: chroot directive is not working when using FISH (File transfer of shell with midnight commander)
Date: Sun, 20 Jun 2010 09:17:12 +0100
[Message part 1 (text/plain, inline)]
Hi Stephan,

This morning, I am sorry, I cannot reproduce the bug anymore, but I am 
pretty sure to have used the same account yesterday.

Since I have modified my ssh server config during the time, I'll try to 
reproduce it later, in the same conditions.

Kind regards,
André Rodier.

Login process:
> andre@arcadia:~$ sftp -o PubkeyAuthentication=no user1@transfer.myred2.com
> user1@transfer.myred2.com's password:
> Connected to transfer.myred2.com.
> sftp> ls
> sftp> pwd
> Remote working directory: /
> Jun 20 08:53:08 transfer sshd[4968]: debug1: Forked child 4975.
> Jun 20 08:53:08 transfer sshd[4975]: debug1: rexec start in 5 out 5 
> newsock 5 pipe 7 sock 8
> Jun 20 08:53:08 transfer sshd[4975]: debug1: inetd sockets after 
> dupping: 3, 3
> Jun 20 08:53:08 transfer sshd[4975]: Connection from 213.107.190.212 
> port 41913
> Jun 20 08:53:08 transfer sshd[4975]: debug1: Client protocol version 
> 2.0; client software version OpenSSH_5.5p1 Debian-4
> Jun 20 08:53:08 transfer sshd[4975]: debug1: match: OpenSSH_5.5p1 
> Debian-4 pat OpenSSH*
> Jun 20 08:53:08 transfer sshd[4975]: debug1: Enabling compatibility 
> mode for protocol 2.0
> Jun 20 08:53:08 transfer sshd[4975]: debug1: Local version string 
> SSH-2.0-OpenSSH_5.1p1 Debian-5
> Jun 20 08:53:08 transfer sshd[4975]: debug1: user user1 matched group 
> list sftponly at line 81
> Jun 20 08:53:08 transfer sshd[4975]: Failed none for user1 from 
> 213.107.190.212 port 41913 ssh2
> Jun 20 08:53:13 transfer sshd[4975]: Accepted password for user1 from 
> 213.107.190.212 port 41913 ssh2
> Jun 20 08:53:13 transfer sshd[4975]: debug1: monitor_child_preauth: 
> user1 has been authenticated by privileged process
> Jun 20 08:53:13 transfer sshd[4977]: debug1: SELinux support disabled
> Jun 20 08:53:13 transfer sshd[4975]: User child is on pid 4977
> Jun 20 08:54:10 transfer sshd[4975]: debug1: do_cleanup



On 20/06/10 08:32, Stefan Fritsch wrote:
> On Saturday 19 June 2010, you wrote:
>    
>> However, if I use the fish protocol [1] included in midnight
>> commander, I can see the full filesystem hierarchy, and even
>> transfer files from the etc folder, etc...
>>      
>    
>> Subsystem sftp internal-sftp
>> Match group sftponly
>>          ChrootDirectory /home/%u
>>          X11Forwarding no
>>          AllowTcpForwarding no
>> 	AllowAgentForwarding no
>>          ForceCommand internal-sftp
>>      
> fish does not work at all with ForceCommand and it won't work with
> ChrootDirectory unless you copy lots of things into the chroot (/lib
> /bin ...).
>
> Have you used the same user for your fish and sftp tests? Please
> verify in /var/log/auth.log that you really did.
>    
[Message part 2 (text/html, inline)]

Added tag(s) moreinfo. Request was from Stefan Fritsch <sf@debian.org> to control@bugs.debian.org. (Fri, 16 Jul 2010 19:57:06 GMT) Full text and rfc822 format available.

Reply sent to Stefan Fritsch <sf@sfritsch.de>:
You have taken responsibility. (Sat, 17 Jul 2010 18:09:12 GMT) Full text and rfc822 format available.

Notification sent to Andre Rodier <andre.rodier@gmail.com>:
Bug acknowledged by developer. (Sat, 17 Jul 2010 18:09:12 GMT) Full text and rfc822 format available.

Message #22 received at 586480-done@bugs.debian.org (full text, mbox):

From: Stefan Fritsch <sf@sfritsch.de>
To: Andre Rodier <andre.rodier@gmail.com>
Cc: 586480-done@bugs.debian.org
Subject: Re: Bug#586480: openssh-server: chroot directive is not working when using FISH (File transfer of shell with midnight commander)
Date: Sat, 17 Jul 2010 20:04:46 +0200 (CEST)
On Sun, 20 Jun 2010, Andre Rodier wrote:
> This morning, I am sorry, I cannot reproduce the bug anymore, but I am pretty 
> sure to have used the same account yesterday.

I am closing this bug. Feel free to re-open it if you can reproduce the 
problem.

Cheers,
Stefan





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 15 Aug 2010 07:36:11 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 19:36:46 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.