X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/8440a771c10c20c4be0a65a50c8bf05754e3fd4d..f4a6a03de6b64252006d7b56314450f6d8b4fa20:/doc/security.mdwn

diff --git a/doc/security.mdwn b/doc/security.mdwn
index a3e387218..e34dc5ed4 100644
--- a/doc/security.mdwn
+++ b/doc/security.mdwn
@@ -48,9 +48,14 @@ 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.
+## 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
 
@@ -58,19 +63,11 @@ 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.
-
 ----
 
-# Probable non-holes
+# Hopefully non-holes
+
+(AKA, the assumptions that will be the root of most security holes...)
 
 ## exploting ikiwiki with bad content
 
@@ -80,15 +77,60 @@ 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, so
-hopefully your web server will not run it.
+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.
 
-## --gen-wrapper might generate insecure wrappers
+## suid wrappers
 
-ikiwiki --gen-wrapper is intended to generate a wrapper program that
+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.
+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.