]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/security.mdwn
(no commit message)
[git.ikiwiki.info.git] / doc / security.mdwn
index 6e1d56a52e76c92a50a6a48d66293f5b3a3022d4..52d9d3dc0c4ee820a3a40ae79e7a5f16ad925999 100644 (file)
@@ -6,7 +6,7 @@ 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]]
+[[!toc levels=2]]
 
 ----
 
@@ -41,11 +41,19 @@ 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?
 
-Currently only people with direct commit access can upload such files
+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.
+
+The attachments plugin is not enabled by default. If you choose to
+enable it, you should make use of its powerful abilities to filter allowed
+types of attachments, and only let trusted users upload.
+
+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
 
@@ -58,8 +66,7 @@ So it's best if only one person can ever directly write to those directories.
 ## setup files
 
 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.
+with the rest of the wiki. Just don't do it.
 
 ## page locking can be bypassed via direct commits
 
@@ -98,7 +105,7 @@ your web server will not run it.
 
 ## suid wrappers
 
-ikiwiki --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.
@@ -111,9 +118,13 @@ 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 untainted filenames. And it runs with taint checks on of
-course..
+`system(3)` at all, and the only use of backticks is on data supplied by the
+wiki admin and untainted filenames. 
+
+Ikiwiki was developed and used for a long time with perl's taint checking
+turned on as a second layer of defense against shell and other exploits. Due
+to a strange [bug](http://bugs.debian.org/411786) in perl, taint checking
+is currently disabled for production builds of ikiwiki.
 
 ## cgi data security
 
@@ -134,15 +145,15 @@ file not be world readable.
 
 ## cgi password security
 
-Login to the wiki involves sending a password in cleartext over the net.
-Cracking the password only allows editing the wiki as that user though.
-If you care, you can use https, I suppose. If you do use https either for
-all of the wiki, or just the cgi access, then consider using the sslcookie
-option.
+Login to the wiki using [[plugins/passwordauth]] involves sending a password
+in cleartext over the net. Cracking the password only allows editing the wiki
+as that user though. If you care, you can use https, I suppose. If you do use
+https either for all of the wiki, or just the cgi access, then consider using
+the sslcookie option. Using [[plugins/openid]] is a potentially better option.
 
 ## XSS holes in CGI output
 
-ikiwiki has not yet been audited to ensure that all cgi script input/output
+ikiwiki has been audited to ensure that all cgi script input/output
 is sanitised to prevent XSS attacks. For example, a user can't register
 with a username containing html code (anymore).
 
@@ -151,10 +162,11 @@ closed though.
 
 ## HTML::Template security
 
-If the [[plugins/template]] plugin is enabled, users can modify templates
-like any other part of the wiki. This assumes that HTML::Template is secure
+If the [[plugins/template]] plugin is enabled, all users can modify templates
+like any other part of the wiki. Some trusted users can modify templates
+without it too. This assumes that HTML::Template is secure
 when used with untrusted/malicious templates. (Note that includes are not
-allowed, so that's not a problem.)
+allowed.)
 
 ----
 
@@ -341,7 +353,113 @@ There are at least two configurations where this is exploitable:
   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
+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. 
+([[!cve CVE-2008-0809]]) Some urls specifyable by the meta plugin could also
+theoretically have been used to inject javascript; this was also blocked
+([[!cve CVE-2008-0808]]).
+
+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.
+
+## Cross Site Request Forging
+
+Cross Site Request Forging could be used to constuct a link that would
+change a logged-in user's password or other preferences if they clicked on
+the link. It could also be used to construct a link that would cause a wiki
+page to be modified by a logged-in user. ([[!cve CVE-2008-0165]])
+
+These holes were discovered on 10 April 2008 and fixed the same day with
+the release of ikiwiki 2.42. A fix was also backported to Debian etch, as
+version 1.33.5. I recommend upgrading to one of these versions.
+
+## Cleartext passwords
+
+Until version 2.48, ikiwiki stored passwords in cleartext in the `userdb`.
+That risks exposing all users' passwords if the file is somehow exposed. To
+pre-emtively guard against that, current versions of ikiwiki store password
+hashes (using Eksblowfish).
+
+If you use the [[plugins/passwordauth]] plugin, I recommend upgrading to
+ikiwiki 2.48, installing the [[!cpan Authen::Passphrase]] perl module, and running
+`ikiwiki-transition hashpassword` to replace all existing cleartext passwords
+with strong blowfish hashes. 
+
+You might also consider changing to [[plugins/openid]], which does not 
+require ikiwiki deal with passwords at all, and does not involve users sending
+passwords in cleartext over the net to log in, either.
+
+## Empty password security hole
+
+This hole allowed ikiwiki to accept logins using empty passwords, to openid
+accounts that didn't use a password. It was introduced in version 1.34, and
+fixed in version 2.48. The [bug](http://bugs.debian.org/483770) was
+discovered on 30 May 2008 and fixed the same day. ([[!cve CVE-2008-0169]])
+
+I recommend upgrading to 2.48 immediatly if your wiki allows both password
+and openid logins.
+
+## Malformed UTF-8 DOS
+
+Feeding ikiwiki page sources containing certian forms of malformed UTF-8
+can cause it to crash. This can potentially be used for a denial of service
+attack.
+
+intrigeri discovered this problem on 12 Nov 2008 and a patch put in place
+later that day, in version 2.70. The fix was backported to testing as version
+2.53.3, and to stable as version 1.33.7.
+
+## Insufficient blacklisting in teximg plugin
+
+Josh Triplett discovered on 28 Aug 2009 that the teximg plugin's
+blacklisting of insecure TeX commands was insufficient; it could be
+bypassed and used to read arbitrary files. This was fixed by
+enabling TeX configuration options that disallow unsafe TeX commands.
+The fix was released on 30 Aug 2009 in version 3.1415926, and was
+backported to stable in version 2.53.4. If you use the teximg plugin,
+I recommend upgrading. ([[!cve CVE-2009-2944]])
+
+## javascript insertion via svg uris
+
+Ivan Shmakov pointed out that the htmlscrubber allowed `data:image/*` urls,
+including `data:image/svg+xml`. But svg can contain javascript, so that is
+unsafe.
+
+This hole was discovered on 12 March 2010 and fixed the same day
+with the release of ikiwiki 3.20100312.
+A fix was also backported to Debian etch, as version 2.53.5. I recommend
+upgrading to one of these versions if your wiki can be edited by third
+parties.
+
+## javascript insertation via insufficient htmlscrubbing of comments
+
+Kevin Riggle noticed that it was not possible to configure
+`htmlscrubber_skip` to scrub comments while leaving unscubbed the text
+of eg, blog posts. Confusingly, setting it to "* and !comment(*)" did not
+scrub comments.
+
+Additionally, it was discovered that comments' html was never scrubbed during
+preview or moderation of comments with such a configuration.
+
+These problems were discovered on 12 November 2010 and fixed the same
+hour with the release of ikiwiki 3.20101112. ([[!cve CVE-2010-1673]])
+
+## javascript insertation via insufficient checking in comments
+
+Dave B noticed that attempting to comment on an illegal page name could be
+used for an XSS attack.
+
+This hole was discovered on 22 Jan 2011 and fixed the same day with
+the release of ikiwiki 3.20110122. A fix was backported to Debian squeeze,
+as version 3.20100815.5. An upgrade is recommended for sites
+with the comments plugin enabled. ([[!cve CVE-2011-0428]])