X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
References: <664060 DOT 6380 DOT qm AT web34704 DOT mail DOT mud DOT yahoo DOT com>   <933558 DOT 98400 DOT qm AT web34705 DOT mail DOT mud DOT yahoo DOT com>   <4934527E DOT 2070200 AT cygwin DOT com>   <961872 DOT 64997 DOT qm AT web34701 DOT mail DOT mud DOT yahoo DOT com>   <493568B8 DOT 3010308 AT cygwin DOT com>   <49376 DOT 99112 DOT qm AT web34702 DOT mail DOT mud DOT yahoo DOT com>   <20081202231141 DOT GA5449 AT ednor DOT casa DOT cgf DOT cx>   <451120 DOT 45664 DOT qm AT web34703 DOT mail DOT mud DOT yahoo DOT com>   <4935DD4B DOT 7050907 AT cygwin DOT com>   <690548 DOT 2534 DOT qm AT web34702 DOT mail DOT mud DOT yahoo DOT com> <af075b00812030245m2b64cae2q4601c63424da611 AT mail DOT gmail DOT com> <49366705 DOT 5D2D6371 AT dessent DOT net>
Date: Wed, 3 Dec 2008 04:57:43 -0800 (PST)
From: TheO <idgajelas AT yahoo DOT com>
Subject: Re: Finally managed to create a jailed SFTP server, but how secure?
To: cygwin AT cygwin DOT com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <940072.24685.qm@web34702.mail.mud.yahoo.com>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

> 
> This is not valid reasoning, as Eric Blake already pointed out you can
> still access files outside of a chroot even if you're still going
> through the Cygwin DLL by using Win32 style pathnames since Cygwin
> passes those through untouched.  Whether or not you can trick the sftp
> code into letting such a filename through remains to be seen, but the
> point here is that just because the access occurs via the Cygwin API
> doesn't mean the chroot is absolute.
> 

I am just trying to be logical here.

I am exporting only SFTP access to users. Well at least that's what I want,
I don't know whether somehow user is able spawn another application via SSHD
using something which I am not aware yet. This is one of my questions which
hasn't been answered so far (what subsystems are handled internally by SSHD
apart from shell and sftp?).

So logically, with just SFTP available, what user can do is limited to basically;
cd, mkdir, rmdir, get, put, rename, rm.

Simply put, he can only manipulate files and directories.

And if I understand correctly, one of the possible way for user to bypass check
by Cygwin is to use Win32 reserved file names.

identifying what filenames are reserved by Win32, this is what I've got (please
complete it if I am missing something):

  Dos devices:      CON, COMn, LPTn, AUX, PRN, NUL (n=0, 1, ...)
  Named Pipes:      \\.\Pipe\foo
  Physical Driver:  \\.\PhysicalDriveN (N=0, 1, ...)

I tried the following commands from a jailed sftp session:

    sftp> get PRN
    Fetching /home/user/PRN to PRN
    Couldn't read from remote file "/home/user/PRN" : Failure

    sftp> put foo PRN
    Uploading foo to /home/Administrator/prn
    foo                                       100%    4     0.0KB/s   00:01
    Couldn't write to remote file "/home/Administrator/PRN": Permission denied
    Invalid command.

    sftp> get CON
    Fetching /home/user/CON to CON
    Couldn't get handle: Permission denied

    sftp> put foo CON
    Uploading foo to /home/Administrator/CON
    Couldn't get handle: Permission denied

    sftp> get NUL
    Fetching /home/user/NUL to NUL
    *** successful transfer ***

    sftp> put NUL
    Uploading NUL to /home/Administrator/NUL
    NUL                                        100%    0     0.0KB/s   00:00
    *** successful transfer ***

    sftp> get LPT1
    Fetching /home/user/LPT1 to LPT1
    Couldn't read from remote file "/home/user/LPT1" : Failure

    sftp> get //./Pipe/foo
    Couldn't stat remote file: No such file or directory
    File "//./Pipe/foo" not found.

    sftp> put foo //./Pipe/foo
    Uploading foo to //./Pipe/foo
    Couldn't get handle: No such file or directory

    sftp> get COM1
    *** stuck ***

So far, the only successful transfer is using NUL device (which is harmless)
and the one which cause problem was accessing COM1. The client was stuck
and I had to kill the SSHD daemon to restore it.

If this is the only problem, I can remove all COMn from the host Windows.


      

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/