X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/0e445d62d212d8e6c2cd5d11a38ae8cef914c1cd..6d1689363d5410af1762851ba9a63c109d65205b:/doc/security.mdwn?ds=inline diff --git a/doc/security.mdwn b/doc/security.mdwn index 9259209ee..afefd1bc3 100644 --- a/doc/security.mdwn +++ b/doc/security.mdwn @@ -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]] ---- @@ -22,8 +22,8 @@ this would be to limit web commits to those done by a certain user. ## other stuff to look at -I need to audit the git backend a bit, and have been meaning to -see if any CRLF injection type things can be done in the CGI code. +I have been meaning to see if any CRLF injection type things can be +done in the CGI code. ---- @@ -41,11 +41,12 @@ 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:` @@ -65,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 @@ -105,12 +105,12 @@ 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. -If the wrapper script is made suid, then any bugs in this wrapper would be +If the wrapper program 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. @@ -118,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 @@ -141,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). @@ -158,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.) ---- @@ -356,12 +361,139 @@ 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. +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 insertion 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 insertion 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]]) + +## possible javascript insertion via insufficient htmlscrubbing of alternate stylesheets + +Giuseppe Bilotta noticed that 'meta stylesheet` directives allowed anyone +who could upload a malicious stylesheet to a site to add it to a +page as an alternate stylesheet, or replacing the default stylesheet. + +This hole was discovered on 28 Mar 2011 and fixed the same hour with +the release of ikiwiki 3.20110328. A fix was backported to Debian squeeze, +as version 3.20100815.6. An upgrade is recommended for sites that have +untrusted committers, or have the attachments plugin enabled. +([[!cve CVE-2011-1401]]) + +## tty hijacking via ikiwiki-mass-rebuild + +Ludwig Nussel discovered a way for users to hijack root's tty when +ikiwiki-mass-rebuild was run. Additionally, there was some potential +for information disclosure via symlinks. ([[!cve CVE-2011-1408]]) + +This hole was discovered on 8 June 2011 and fixed the same day with +the release of ikiwiki 3.20110608. Note that the fix is dependant on +a version of su that has a similar hole fixed. Version 4.1.5 of the shadow +package contains the fixed su; [[!debbug 628843]] tracks fixing the hole in +Debian. An upgrade is a must for any sites that have `ikiwiki-update-wikilist` +installed suid (not the default), and whose admins run `ikiwiki-mass-rebuild`. + +## javascript insertion via meta tags + +Raúl Benencia discovered an additional XSS exposure in the meta plugin. +([[!cve CVE-2012-0220]]) + +This hole was discovered on 16 May 2012 and fixed the same day with +the release of ikiwiki 3.20120516. A fix was backported to Debian squeeze, +as version 3.20100815.9. An upgrade is recommended for all sites.