Virtual Path Security Bug: Build 157 & 160

[Poky]

There's a security issue with the virtual paths feature in build 157.
This issue only seems to show up when clients are using
a command-line sftp client.

Problem: commandline driven folder navigation through virtual path exposes non-mapped directories.

user cd's down into a virtual path.
user issues "cd ../"
Coreftp Server navigates back up the physical path, not the virtual path.
User can navigate all the way to root of disk.

Example:
%HOME% = d:\ftpbase
disk1 (virtual) points to d:\media\movies

User: cd disk1 -> end up in movies
User: cd ../ -> end up in media
User: cd ../ -> end up in d:\

In this case client was sftp running on red hat linux.

--edited title to include build 160

[Poky]

Permissions should still kick in and not allow it.

Right. Permissions did kick in, and user was not able to access the data, but were able to see what files and directories are physically on the disk.
It's not clear to me if this is just because I had set Read, List, Inherit as the permissions for the virtual path. I'm not sure what would hapeen if the permissions were Read, Write, List, Inherit. Perhaps they would be able to modify files outside the virtual path?

[Poky]

Great! I'll give it a try tonight and let you know how it goes.

[Poky]

Nope! That didn't work quite right.

Sorry it's taken a few days to get back to you.
So, let's recap...
%HOME% = d:\ftpbase
disk1 (virtual) points to d:\media\movies

User: cd disk1 -> end up in movies
User: cd ../ Now you get an error message
Message states- couldn't get handle: permission denied

User: pwd returns /disk1/../

BTW, you should be able to test this with coreftp client.
navigate down into a virtual directory, then right-click and select directory commands.
type cd ../ and hit return. You should see some message in the log saying permission denied, and the directory will not have changed.

[Poky]

Just curious if you've made any headway with this issue?
Can you duplicating it using the coreFTP client?