up

[ikiwiki.git] / doc / security.mdwn

diff --git a/doc/security.mdwn b/doc/security.mdwn
index e7936b5a09475dd3f6fba83368394d98b3c4ecd4..b726211112e8b710b5914936d145f9eb44d768d8 100644 (file)
--- a/doc/security.mdwn
+++ b/doc/security.mdwn
@@ -1,9 +1,10 @@
 Let's do an ikiwiki security analysis..
 
-If you are using ikiwiki to render pages that only you can edit, 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 security issues
-do need to be kept in mind.
+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.
 
 ## html attacks
 
@@ -42,11 +43,49 @@ they can try to use this to exploit your web server.
 
 ## --gen-wrapper might generate insecure wrappers
 
-ikiwiki --gen-wrapper is instended to generate a wrapper program that
+ikiwiki --gen-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 and
-there's been no problems yet.
+there's been no problem yet.
+
+## 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.
+
+Even with locking, if an attacker has local write access to the checkout,
+they could still fool ikiwiki using similar races. So it's best if only one
+person can ever write to the checkout that ikiwiki compiles the moo 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.
+
+## cgi 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.