releasing version 2.14

2 files changed, 46 insertions, 1 deletions

diff --git a/doc/bugs/Symlinked_srcdir_requires_trailing_slash.mdwn b/doc/bugs/Symlinked_srcdir_requires_trailing_slash.mdwn
index 0310c17f3..cd74c2496 100644
--- a/doc/bugs/Symlinked_srcdir_requires_trailing_slash.mdwn
+++ b/doc/bugs/Symlinked_srcdir_requires_trailing_slash.mdwn
@@ -63,4 +63,19 @@ My output:
     scanning index.mdwn
     rendering index.mdwn
 
-Note that index.mdwn was only rendered when srcdir had a trailing slash.
\ No newline at end of file
+Note that index.mdwn was only rendered when srcdir had a trailing slash.
+
+> There are potential [[security]] issues with ikiwiki following a symlink,
+> even if it's just a symlink at the top level of the srcdir.
+> Consider ikiwiki.info's own setup, where the srcdir is ikiwiki/doc,
+> checked out of revision control. A malicious committer could convert
+> ikiwiki/doc into a symlink to /etc, then ikiwiki would happily publish
+> all of /etc to the web.
+> 
+> This kind of attack is why ikiwiki does not let File::Find follow
+> symlinks when scanning the srcdir. By appending the slash, you're
+> actually bypassing that check. Ikiwiki should not let you set
+> up a potentially insecure configuration like that. More discussion of
+> this hole [[here|security#index29h2]], and I've had to release
+> a version of ikiwiki that explicitly checks for that, and fails to work.
+> Sorry, but security trumps convenience. [[done]] --[[Joey]]
diff --git a/doc/security.mdwn b/doc/security.mdwn
index b1e8d03f6..a1c2120ce 100644
--- a/doc/security.mdwn
+++ b/doc/security.mdwn
@@ -315,3 +315,33 @@ 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
+da 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.