X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/c1289de1eff4c0b4b2cd47e61b2273970e327009..4e97a8d915415e9577a65076e7aa9c2e0d0ae61a:/doc/security.mdwn diff --git a/doc/security.mdwn b/doc/security.mdwn index 57cac719f..b067a8a16 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]] ---- @@ -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 @@ -361,9 +361,9 @@ allow the security hole to be exploited. 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 +([[!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]]). +([[!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..) @@ -376,7 +376,7 @@ parties. 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]]) +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 @@ -390,7 +390,7 @@ 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 2.48, installing the [[!cpan Authen::Passphrase]] perl module, and running `ikiwiki-transition hashpassword` to replace all existing cleartext passwords with strong blowfish hashes. @@ -403,7 +403,17 @@ passwords in cleartext over the net to log in, either. 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]]) +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.2, and to stable as version 1.33.7.