Finally managed to create a jailed SFTP server, but how secure?

Wed Dec 3 12:58:00 GMT 2008

> 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:
Problem reports:

More information about the Cygwin mailing list