 |
Some of you may be (quite rightly) concered about how secure TuxServe is, and what, if any, security problems
it poses. In this document I'll try to explain how TuxServe handles each problem and what you can do to make
it more secure. If you have any security concerns or questions, please contact me.
First off, you must take note of the inherant danger of DCC. While it is generally accepted to not pose
a security threat, it does mean that you have to leave certain incoming TCP ports on your system open
for the DCC sessions (DCC sessions are actually incoming connections to whomever starts them). Of
course, which ports you use is entirely up to you, and you can change them as often as you want. It
would be possible to get around this problem by using something like "dccserver" or "psend", but
they're not universal.
Also, unless you have mode +x (not all IRC servers understand this) enabled or you are using a
vhost, your IP address will be viewable by all.
Next is the actual fserve DCC chat session. Some may wonder if letting users browse your file system
is a wise idea - but TuxServe does not work in the same way as a shell session where they can browse.
TuxServe uses a "virtual" filesystem idea - it basically it keeps the dir path of where the user was last in
a string, so when a user wants to list it's contents, TuxServe will ask the system for the contents of that
dir. This, in theory, allows us control over where the user can and can't go. For example, they can't go
up a dir from the "root" directory of the fserve (which is the "trigger_dir" for whatever trigger they
entered.
"What if a user tried something like 'get /etc/passwd'?" Something like this will not work. The "get"
command will only work if the file they are trying to get is in the dir they are currently in. If the file does
not exist in the dir they are currently browsing, TuxServe will inform them that the file cannot be found.
"What would happen if the user tried to execute a system command?" This, too, will fail - only text from
the user that matches one of the preset commands ("get", "cd", "help", "exit", the tags, etc) will be
processed - all other input will be ignored and passed back to XChat. If a user tries "/sbin/reboot", or
"reboot", it will be ignored, as it's not one of the TuxServe commands.
Buffer overflows are also something that could occur in TuxServe, in theory allowing some bugs to show up,
or possibly something worse. I've not had any reports of this, nor have I experience it myself (the
worst thing that happened was that it screwed up the end of the string i was using), but I am trying to minimise the risk of this. The TuxServe code uses the "sprintf" command
a lot, and this is deemed (by some) to be unwise, as the buffer length is unspecified. While I agree, I
am trying to make sure that my usage of these is secure - although I am re-evaluating their use. They
will be replaced with the more secure "snprintf" command if they are at risk.
File permissions: For TuxServe to be able to browse your system (as specified in the paragraphs
above) and send users files, it needs to have at least read access to the files and directories. It does
not need write nor execute access. While I see no risk in letting TuxServe use files that it has write
and/or execute access to, as general rule it's a good idea not to. The only files TuxServe does need
write access to are the files in its dir (~/.xchat2/tuxserve/) - "queues", "sends", "config.cfg" and
"ban_list".
This may go without saying, but never give users access to the root of your file system (/), nor any
important directories like "/etc" and "/root", as users can still download these files (if the user you're
running TuxServe on has read permissions to these files)! TuxServe (at the moment) shows ALL files
and dirs in a directory - this includes all hidden dirs (those which start with a full stop ".") - there will
soon be an option to not show hidden files. Please remember to not let the users browse any dirs
(hidden or otherwise) which contain personal or private data.
CTCP messages, notices, and PRIVMSGs - all of these are treated in the same was as input from a
user via the fserve DCC chat session: if it's not a TuxServe command - it will ignore it and pass it
back to XChat. There is, however, one exception: fserve triggers. These are read in from the config
file, but do not pose a security threat - these are simply compared to what the user sent, and if it is
the same, it will start a DCC chat session with them.
|
|
 |
