web commit by http://edward.myopenid.com/: spelling fix and link [[hyperestraier]]

[git.ikiwiki.info.git] / doc / security.mdwn

diff --git a/doc/security.mdwn b/doc/security.mdwn
index 9d7702dde3a09053fb09c27a9553a8829f4068e6..9259209eeb34e99714d247dfee1144e929c90533 100644 (file)
--- a/doc/security.mdwn
+++ b/doc/security.mdwn
@@ -6,6 +6,8 @@ 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.
 
 others edit pages in your wiki, then some possible security issues do need
 to be kept in mind.
 

+[[toc levels=2]]
+

 ----
 
 # Probable holes
 ----
 
 # Probable holes


@@ -16,7 +18,7 @@ _(The list of things to fix.)_
 
 Anyone with direct commit access can forge "web commit from foo" and
 make it appear on [[RecentChanges]] like foo committed. One way to avoid
 
 Anyone with direct 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.
+this would be to limit web commits to those done by a certain user.

 
 ## other stuff to look at
 
 
 ## other stuff to look at
 


@@ -39,32 +41,39 @@ 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?
 
 
 Of course nobody else seems to worry about this in other wikis, so should we?
 

-Currently only people with direct svn commit access can upload such files
-(and if you wanted to you could block that with a svn pre-commit hook).
+Currently only people with direct commit access can upload such files
+(and if you wanted to you could block that with a pre-commit hook).

 Users with only web commit access are limited to editing pages as ikiwiki
 doesn't support file uploads from browsers (yet), so they can't exploit
 this.
 
 Users with only web commit access are limited to editing pages as ikiwiki
 doesn't support file uploads from browsers (yet), so they can't exploit
 this.
 

+It is possible to embed an image in a page edited over the web, by using
+`img src="data:image/png;"`. Ikiwiki's htmlscrubber only allows `data:`
+urls to be used for `image/*` mime types. It's possible that some broken
+browser might ignore the mime type and if the data provided is not an
+image, instead run it as javascript, or something evil like that. Hopefully
+not many browsers are that broken.
+

 ## multiple accessors of wiki directory
 
 ## multiple accessors of wiki directory
 

-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 multiple people can directly 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.

 
 

-So it's best if only one person can ever write to those directories.
+So it's best if only one person can ever directly write to those directories.

 
 ## setup files
 
 
 ## 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.
+Setup files are not safe to keep in the same revision control repository
+with the rest of the wiki. 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
+## page locking can be bypassed via direct commits

 
 

-A locked 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.
+A locked page can only be edited on the web by an admin, but anyone who is
+allowed to commit directly to the repository can bypass this. This is by
+design, although a pre-commit hook could be used to prevent editing of
+locked pages, if you really need to.

 
 ## web server attacks
 
 
 ## web server attacks
 


@@ -78,7 +87,7 @@ they can try to use this to exploit your web server.
 
 _(AKA, the assumptions that will be the root of most security holes...)_
 
 
 _(AKA, the assumptions that will be the root of most security holes...)_
 

-## exploting ikiwiki with bad content
+## exploiting 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.
 
 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.


@@ -120,8 +129,8 @@ 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 "/"
 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.
+or contain ".." or "/.svn/", etc. Annoyingly ad-hoc, this kind of code is
+where security holes breed. It needs a test suite at the very least.

 
 ## CGI::Session security
 
 
 ## CGI::Session security
 


@@ -156,6 +165,20 @@ allowed, so that's not a problem.)
 
 ----
 
 
 ----
 

+# Plugins
+
+The security of [[plugins]] depends on how well they're written and what
+external tools they use. The plugins included in ikiwiki are all held to
+the same standards as the rest of ikiwiki, but with that said, here are
+some security notes for them.
+
+* The [[plugins/img]] plugin assumes that imagemagick/perlmagick are secure
+  from malformed image attacks. Imagemagick has had security holes in the
+  past. To be able to exploit such a hole, a user would need to be able to
+  upload images to the wiki.
+
+----
+

 # Fixed holes
 
 _(Unless otherwise noted, these were discovered and immediately fixed by the
 # Fixed holes
 
 _(Unless otherwise noted, these were discovered and immediately fixed by the


@@ -188,13 +211,13 @@ 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
 
 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.
+prevents one ikiwiki from running a svn up/git pull/etc 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
 
 
 ## symlink + cgi attacks
 

-Similarly, a svn commit of a symlink could be made, ikiwiki ignores it
+Similarly, a 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
 (exposing the content), and again when saving the changed page (changing
 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
 (exposing the content), and again when saving the changed page (changing


@@ -256,3 +279,89 @@ seem to affect our use, since the data is not encoded as utf-8 at that
 point. #[378412](http://bugs.debian.org/378412) could affect us, although it
 doesn't seem very exploitable. It has a simple fix, and has been fixed in
 Debian unstable.
 point. #[378412](http://bugs.debian.org/378412) could affect us, although it
 doesn't seem very exploitable. It has a simple fix, and has been fixed in
 Debian unstable.

+
+## include loops
+
+Various directives that cause one page to be included into another could
+be exploited to DOS the wiki, by causing a loop. Ikiwiki has always guarded
+against this one way or another; the current solution should detect all
+types of loops involving preprocessor directives.
+
+## Online editing of existing css and images
+
+A bug in ikiwiki allowed the web-based editor to edit any file that was in
+the wiki, not just files that are page sources. So an attacker (or a
+genuinely helpful user, which is how the hole came to light) could edit
+files like style.css. It is also theoretically possible that an attacker
+could have used this hole to edit images or other files in the wiki, with
+some difficulty, since all editing would happen in a textarea.
+
+This hole was discovered on 10 Feb 2007 and fixed the same day with the
+release of ikiwiki 1.42. A fix was also backported to Debian etch, as
+version 1.33.1. I recommend upgrading to one of these versions if your wiki
+allows web editing.
+
+## html insertion via title
+
+Missing html escaping of the title contents allowed a web-based editor to
+insert arbitrary html inside the title tag of a page. Since that part of
+the page is not processed by the htmlscrubber, evil html could be injected.
+
+This hole was discovered on 21 March 2007 and fixed the same day (er, hour) 
+with the release of ikiwiki 1.46. A fix was also backported to Debian etch,
+as version 1.33.2. I recommend upgrading to one of these versions if your
+wiki allows web editing or aggregates feeds.
+
+## javascript insertion via meta tags
+
+It was possible to use the meta plugin's meta tags to insert arbitrary
+url contents, which could be used to insert stylesheet information
+containing javascript. This was fixed by sanitising meta tags.
+
+This hole was discovered on 21 March 2007 and fixed the same day
+with the release of ikiwiki 1.47. A fix was also backported to Debian etch,
+as version 1.33.3. I recommend upgrading to one of these versions if your
+wiki can be edited by third parties.
+
+## insufficient checking for symlinks in srcdir path
+
+Ikiwiki did not check if path to the srcdir to contained a symlink. If an
+attacker had commit access to the directories in the path, they could
+change it to a symlink, causing ikiwiki to read and publish files that were
+not intended to be published. (But not write to them due to other checks.)
+
+In most configurations, this is not exploitable, because the srcdir is
+checked out of revision control, but the directories leading up to it are
+not. Or, the srcdir is a single subdirectory of a project in revision
+control (ie, `ikiwiki/doc`), and if the subdirectory were a symlink,
+ikiwiki would still typically not follow it.
+
+There are at least two configurations where this is exploitable:
+
+* If the srcdir is a deeper subdirectory of a project. For example if it is
+  `project/foo/doc`, an an attacker can replace `foo` with a symlink to a
+  directory containing a `doc` directory (not a symlink), then ikiwiki
+  would follow the symlink.
+* If the path to the srcdir in ikiwiki's configuration ended in "/", 
+  and the srcdir is a single subdirectory of a project, (ie,
+  `ikiwiki/doc/`), the srcdir could be a symlink and ikiwiki would not
+  notice.
+
+This security hole was discovered on 26 November 2007 and fixed the same
+day with the release of ikiwiki 2.14. I recommend upgrading to this version
+if your wiki can be committed to by third parties. Alternatively, don't use
+a trailing slash in the srcdir, and avoid the (unusual) configurations that
+allow the security hole to be exploited.
+
+## javascript insertion via uris
+
+The htmlscrubber did not block javascript in uris. This was fixed by adding
+a whitelist of valid uri types, which does not include javascript. Some
+urls specifyable by the meta plugin could also theoretically have been used
+to inject javascript; this was also blocked.
+
+This hole was discovered on 10 February 2008 and fixed the same day
+with the release of ikiwiki 2.31.1. (And a few subsequent versions..)
+A fix was also backported to Debian etch, as version 1.33.4. I recommend
+upgrading to one of these versions if your wiki can be edited by third
+parties.