149 lines
6.1 KiB
Markdown
149 lines
6.1 KiB
Markdown
Let's do an ikiwiki security analysis..
|
|
|
|
If you are using ikiwiki to render pages that only you can edit, do not
|
|
generate any wrappers, and do not use the cgi, then there are no more
|
|
security issues with this program than with cat(1). If, however, you let
|
|
others edit pages in your wiki, then some possible security issues do need
|
|
to be kept in mind.
|
|
|
|
# Probable holes
|
|
|
|
## html attacks
|
|
|
|
ikiwiki does not attempt to do any santization of the html on the wiki.
|
|
[[MarkDown]] allows embedding of arbitrary html into a markdown document. If
|
|
you let anyone else edit files on the wiki, then anyone can have fun exploiting
|
|
the web browser bug of the day. This type of attack is typically referred
|
|
to as an XSS attack ([google](http://www.google.com/search?q=xss+attack)).
|
|
|
|
## image files etc attacks
|
|
|
|
If it enounters a file type it does not understand, ikiwiki just copies it
|
|
into place. So if you let users add any kind of file they like, they can
|
|
upload images, movies, windows executables, css files, etc. If these files exploit security holes in the browser of someone who's viewing the wiki, that can be a security problem.
|
|
|
|
Of course nobody else seems to worry about this in other wikis, so should we?
|
|
|
|
## web server attacks
|
|
|
|
If your web server does any parsing of special sorts of files (for example,
|
|
server parsed html files), then if you let anyone else add files to the wiki,
|
|
they can try to use this to exploit your web server.
|
|
|
|
## symlink attacks
|
|
|
|
Could a committer trick ikiwiki into following a symlink and operating on
|
|
some other tree that it shouldn't? svn supports symlinks, so one can get
|
|
into the repo. ikiwiki uses File::Find to traverse the repo, and does not
|
|
tell it to follow symlinks, but it might be possible to race replacing a
|
|
directory with a symlink and trick it into following.
|
|
|
|
It would certianly be possible to start out with a directory, let ikiwiki
|
|
run and find a file in there, then replace it with a symlink, and ikiwiki
|
|
would then go ahead and follow the symlink when it went to open that file
|
|
to read it. If it was some private file and was running suid, that could be
|
|
bad.
|
|
|
|
TODO: seems that locking to prevent more than one ikiwiki run at a time
|
|
would both fix this and is a good idea in general. With locking, an
|
|
attacker couldn't get ikiwiki to svn up while another instance was running.
|
|
|
|
## multiple accessors of wiki source directory
|
|
|
|
If multiple people can write to the source directory ikiwiki is using, then
|
|
one can cause trouble for the other when they run ikiwiki through symlink
|
|
attacks.
|
|
|
|
So it's best if only one person can ever write to the checkout that ikiwiki
|
|
compiles the wiki from.
|
|
|
|
## webserver symlink attacks
|
|
|
|
If someone checks in a symlink to /etc/passwd, ikiwiki would publish that.
|
|
To aoid this, ikiwiki will need to avoid reading files that are symlinks.
|
|
TODO and note discussion of races above.
|
|
|
|
## setup files
|
|
|
|
Setup files are not safe to keep in subversion with the rest of the wiki.
|
|
Just don't do it. [[ikiwiki.setup]] is *not* used as the setup file for
|
|
this wiki, BTW.
|
|
|
|
## svn commit logs
|
|
|
|
Currently html is not escape in svn commit logs, this should probably be fixed.
|
|
|
|
Anyone with svn commit access can forge "web commit from foo" and make it appeat on [[RecentChanges]] like foo committed. One way to avoid this would be to limit web commits to those done by a certian user.
|
|
|
|
----
|
|
|
|
# Hopefully non-holes
|
|
|
|
(AKA, the assumptions that will be the root of most security holes...)
|
|
|
|
## exploting ikiwiki with bad content
|
|
|
|
Someone could add bad content to the wiki and hope to exploit ikiwiki.
|
|
Note that ikiwiki runs with perl taint checks on, so this is unlikely.
|
|
|
|
## publishing cgi scripts
|
|
|
|
ikiwiki does not allow cgi scripts to be published as part of the wiki. Or
|
|
rather, the script is published, but it's not marked executable (except in
|
|
the case of "destination directory file replacement" below), so hopefully
|
|
your web server will not run it.
|
|
|
|
## suid wrappers
|
|
|
|
ikiwiki --wrapper is intended to generate a wrapper program that
|
|
runs ikiwiki to update a given wiki. The wrapper can in turn be made suid,
|
|
for example to be used in a [[post-commit]] hook by people who cannot write
|
|
to the html pages, etc.
|
|
|
|
If the wrapper script is made suid, then any bugs in this wrapper would be
|
|
security holes. The wrapper is written as securely as I know how, is based
|
|
on code that has a history of security use long before ikiwiki, and there's
|
|
been no problem yet.
|
|
|
|
## shell exploits
|
|
|
|
ikiwiki does not expose untrusted data to the shell. In fact it doesn't use
|
|
system() at all, and the only use of backticks is on data supplied by the
|
|
wiki admin. And it runs with taint checks on of course..
|
|
|
|
## destination directory file replacement
|
|
|
|
Any file in the destination directory that is a valid page filename can be
|
|
replaced, even if it was not originally rendered from a page. For example,
|
|
ikiwiki.cgi could be edited in the wiki, and it would write out a
|
|
replacement. File permission is preseved. Yipes!
|
|
|
|
This was fixed by making ikiwiki check if the file it's writing to exists;
|
|
if it does then it has to be a file that it's aware of creating before, or
|
|
it will refuse to create it.
|
|
|
|
Still, this sort of attack is something to keep in mind.
|
|
|
|
## cgi data security
|
|
|
|
When ikiwiki runs as a cgi to edit a page, it is passed the name of the
|
|
page to edit. It has to make sure to sanitise this page, to prevent eg,
|
|
editing of ../../../foo, or editing of files that are not part of the wiki,
|
|
such as subversion dotfiles. This is done by sanitising the filename
|
|
removing unallowed characters, then making sure it doesn't start with "/"
|
|
or contain ".." or "/.svn/". Annoyingly ad-hoc, this kind of code is where
|
|
security holes breed. It needs a test suite at the very least.
|
|
|
|
## cgi password security
|
|
|
|
Login to the wiki involves sending a password in cleartext over the net.
|
|
Cracking the password only allows editing the moo as that user though.
|
|
If you care, you can use https, I suppose.
|
|
|
|
## CGI::Session security
|
|
|
|
I've audited this module and it is massively insecure by default. ikiwiki
|
|
uses it in one of the few secure ways; by forcing it to write to a
|
|
directory it controls (and not /tmp) and by setting a umask that makes the
|
|
file not be world readable.
|