# Probable holes
-## html attacks
+## XSS holes in CGI output
-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)).
+ikiwiki has not yet been audited to ensure that all cgi script input/output is
+sanitised to prevent XSS attacks.
-## image files etc attacks
+## image file 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.
+upload images, movies, windows executables, css files, etc (though not html
+files). 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.
+## svn commit logs
-## symlink attacks
+Anyone with svn commit access can forge "web commit from foo" and make it
+appear on [[RecentChanges]] like foo committed. One way to avoid this would
+be to limit web commits to those done by a certian user.
-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's actually possible to force a whole series of svn commits to appear to
+have come just before yours, by forging svn log output. This could be
+guarded against by using svn log --xml.
-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.
+ikiwiki escapes any html in svn commit logs to prevent other mischief.
-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
+# Potential gotchas
-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.
+Things not to do.
-So it's best if only one person can ever write to the checkout that ikiwiki
-compiles the wiki from.
+## multiple accessors of wiki directory
-## webserver symlink attacks
+If multiple people can write to the source directory ikiwiki is using, or
+to the destination directory it writes files to, then one can cause trouble
+for the other when they run ikiwiki through 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.
+So it's best if only one person can ever write to those directories.
## setup files
Just don't do it. [[ikiwiki.setup]] is *not* used as the setup file for
this wiki, BTW.
+## page locking can be bypassed via direct svn commits
+
+A [[lock]]ed page can only be edited on the web by an admin, but
+anyone who is allowed to commit direct to svn can bypass this. This is by
+design, although a subversion pre-commit hook could be used to prevent
+editing of locked pages when using subversion, if you really need to.
+
+## 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.
+
----
# Hopefully non-holes
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.
+wiki admin and untainted filenames. And it runs with taint checks on of
+course..
## cgi data security
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.
+
+## cgi password security
+
+Login to the wiki involves sending a password in cleartext over the net.
+Cracking the password only allows editing the wiki as that user though.
+If you care, you can use https, I suppose.
+
+# Fixed holes
+
+_(Unless otherwise noted, these were discovered and immediatey fixed by the
+ikiwiki developers.)_
+
+## 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.
+
+## 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 the link.
+
+Also, if someone checks in a symlink to /etc/passwd, ikiwiki would read and
+publish that, which could be used to expose files a committer otherwise
+wouldn't see.
+
+To avoid this, ikiwiki will skip over symlinks when scanning for pages, and
+uses locking to prevent more than one instance running at a time. The lock
+prevents one ikiwiki from running a svn up at the wrong time to race
+another ikiwiki. So only attackers who can write to the working copy on
+their own can race it.
+
+## symlink + cgi attacks
+
+Similarly, a svn commit of a symlink could be made, ikiwiki ignores it
+because of the above, but the symlink is still there, and then you edit the
+page from the web, which follows the symlink when reading the page, and
+again when saving the changed page.
+
+This was fixed by making ikiwiki refuse to read or write to files that are
+symlinks, or that are in subdirectories that are symlinks, combined with
+the above locking.
+
+## underlaydir override attacks
+
+ikiwiki also scans an underlaydir for pages, this is used to provide stock
+pages to all wikis w/o needing to copy them into the wiki. Since ikiwiki
+internally stores only the base filename from the underlaydir or srcdir,
+and searches for a file in either directory when reading a page source,
+there is the potential for ikiwiki's scanner to reject a file from the
+srcdir for some reason (such as it being a symlink), find a valid copy of
+the file in the underlaydir, and then when loading the file, mistekenly
+load the bad file from the srcdir.
+
+This attack is avoided by making ikiwiki scan the srcdir first, and refuse
+to add any files from the underlaydir if a file also exists in the srcdir
+with the same name. **But**, note that this assumes that any given page can
+be produced from a file with only one name (`page.mdwn` => `page.html`).
+
+If it's possible for files with different names to produce a given page, it
+would still be possible to use this attack to confuse ikiwiki into
+rendering the wrong thing. This is not currently possible, but must be kept
+in mind in the future when for example adding support for generating html
+pages from source with some other extension.
+
+## XSS attacks in page content
+
+ikiwiki supports [[HtmlSanitistion]], though it can be turned off.
sipb-www / ikiwiki.git / blobdiff