COMMAND
WFTPD
SYSTEMS AFFECTED
WFTPD v3.00 R5
PROBLEM
'ByteRage' found following. Let's quote the manual on how the
*.lnk feature is supposed to work:
"File Security
Note that since version 2.40, [...] WFTPD handles shortcuts
[...] if a user lists a directory that contains .LNK files
(shortcuts), they will see those file names (without the
".LNK" extension) followed by an arrow "->" and the path to
the file that the shortcut references (if that path is
available to the user). If a link points to a directory, the
user must have some rights to access that directory in order
to follow the link. If a link points to a file, the user will
have the same access to the file as they would to any other
file in the directory containing the link. This is an
important point - by placing a link to a "secured" file into
an "unsecured" directory, the file is essentially no longer
secured. Deleting or renaming a link through the FTP server
deletes or renames only the shortcut, not the item pointed to.
[...], there is a danger that someone may (if allowed to)
upload a LNK file that contains a shortcut to a protected area
of your disk, and thereby download private information. To
prevent this, we have disallowed any method we know of through
the FTP interface to be able to create LNK files. You will no
longer be able to upload files with an extension ".LNK", and
you will not be able to rename files through WFTPD to have a
.LNK extension (unless those files already have a .LNK
extension). We are aware that this places some limits on
legitimate .LNK files (such as link input files for
developers), but we believe that the ability to access
shortcuts is important enough to take this protective action."
Well such a scenario is possible, by sending the following command
PUT \local.lnk remote.lnk
So basically we just need to append a dot to the lnk filename to
fool WFTPD into accepting a *.lnk file, and we can traverse the
homedirectory. Users with write permissions can traverse
directories.
SOLUTION
Nothing yet.