COMMAND
War FTP Daemon
SYSTEMS AFFECTED
War FTP Daemon 1.70
PROBLEM
Jarle Aase posted following. The bug allows unrestricted access
to any file on the local machine also for users that have not
logged on. If an older ODBC driver is installed, the bug also
gives users unlimited access to all system commands, with
administrator privileges (this is a bug in ODBC that has been
fixed in recent versions).
As for War FTP Daemon 1.67b2 and previous versions the bug may
give privileged uses unrestricted access to some files. Users
must be logged in, and have at least write or create permissions.
Users can not execute commands.
Sir Dystic added following. War-ftpd v1.70b seems to have some
serious problems with the parsing of macros. The current version
doesn't even seem to document the macros available, but in the
response files (sysmsg?.txt) you are supposed to be able to put
macros in the form [$macroname]. The server also uses these
macros internally, but most of the macros Sir Dystic seen seem to
be non-functional (return ???). The available macros seem to be:
systemname programname programversion prgcopyright dirmsg
email greeting diskfree endmacro maxanons anonsonline
restrictions osname uniquefileoption idletime ulcounttrash
udrestrictions ulctype credit ulratio dlratio dlkbcount
dlfcount dlcount ulkbcount ulfcount ulcount origin user
usersonline and most interestingly the sql macro, which is the
only one that's even documented:
The macros in the server response messages supports SQL queries.
The syntax is: [$sql, #MaxRowsReturned, SQLStatement] If
#MaxRowsReturned is 0 (zero), all matching rows will be
displayed.
These macros are interpreted before text is returned to the user
and replaced with the appropriate text. The problem is, there's
nothing to prevent the remote client from passing these macros to
the server and having them repeated and interpreted and ret urned
to the user. In fact, it's not even necessary to log in since if
you send it an invalid literal command (as any of the intrepreted
macros would be) it returns: 500 'whatever': command not
understood. So as soon as you're connected to the server, even
before you log in, you can execute "literal [$osinfo]" or any of
the other macros. It seems to disconnect if you attempt to get
some of the macros before logging in.
More frightening is the interpretation of macros not beginning
with a $. These are replaced with the contents of the file
contained in the square brackets. So if you execute "literal
[warsvr.conf]" you will be returned the error:
500 '[Options]
core_RESNAME=WARSVR
core_RPCPORT=0
core_PRIORITY=2
core_TRAYICON=1
core_WM_CLOSE=1
log_LOGFILE=Log/%Y-%m-%d.log
... etc
': command not understood.
This particular file contains the fields odbc_USER and odbc_PASSWD
which may contain a plaintext login to the sql server. In fact,
you can put [x:\anydir\anyfile] if you know the path to an
existing file. If the server is running on NT, UNC and network
paths may even work (SD couldn't get them to on his machine, but
it sure paused like it was doing something network related).
Although this method works perfectly for text files, it only
displays some of the data in binary files, and not always the top
of the file. As was mentioned in an bugtraq post from a while
back, this beta stores it's passwords in plaintext, and viewing a
waruser.dat with several accounts in it may well reveal these
passwords.
There also seems to be a bug in the parser of the macros itself
relating to unmatched square brackets. Executing literal open
bracket commands often dumps random chunks of memory, or simply
closes the session (kills the thread?). With the server running
under 95 SD seen it dump session text from other active sessions,
usernames, ip addresses, passwords, and plenty of random chunks of
memory. There seems to be little consistency to what memory is
displayed or when it decides to simply disconnect.
It also fails to properly check for the existance of directories
when you change into them, so "cd nonexistingdirectory" will
change your cwd to nonexistingdirectory which will just apear to
be empty if you do a ls. However, because of this bug you can c
ause more interesting things to happen by changing to a directory
with an unmatched open bracket in its name and then repeatedly
doing pwd. All it takes is for the sysadmin password to show up
and the server can be remotely administered using the daemon
manager that comes with the software. Then access could be
granted to any local or network drives available to the machine
and account war-ftpd.exe is running as.
Oh, and if you do "literal help somethingnotrecognised" it seems
to hang that connection.
SOLUTION
The advice is to take all version 1.70 servers off-line until the
server is upgraded. A bugfix (War FTP Daemon 1.71) was released
january 8th 2000 14:40 CET. Bugfixes are released at:
ftp://ftp.no.jgaa.com