X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/4ad7c9d6257ca106b2949d22f6300823190991a0..40f318f3e999ce5f7890deafcb56deb1c125bf7a:/doc/security.mdwn?ds=inline

diff --git a/doc/security.mdwn b/doc/security.mdwn
index 9d7702dde..01a893d20 100644
--- 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.
 
+[[toc levels=2]]
+
 ----
 
 # 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
-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
 
@@ -78,7 +80,7 @@ they can try to use this to exploit your web server.
 
 _(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.
@@ -156,6 +158,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
@@ -256,3 +272,24 @@ 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.
+
+## 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.