Thanks for the props Jarle.


The current release (beta) of 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 I've 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 returned 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.  I haven't found a war-ftp server running on a machine with the sql interface
enabled to test on, but I suspect any sql query could be fed in this manner, although the help does say:
'The execute statement is forced to read-only to prevent data updates from this macro. 
SQL statements like UPDATE, DROP, or CREATE will give an error.'

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 (I couldn't get them to on my 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 I've 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 cause
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.

I suspect this is just the tip of the iceburg, and it is beta software, but it also seems to be in extremly wide use and those users are putting themselves at serious risk.  I'm 
also fairly certain that all this info is 'in the wild' already.

        Sir Dystic
   Cult of the Dead Cow
    sd@sinister.com