X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/0e445d62d212d8e6c2cd5d11a38ae8cef914c1cd..0b46412c96aa78093da1cc6a830fd9a67c5aa188:/doc/security.mdwn diff --git a/doc/security.mdwn b/doc/security.mdwn index 9259209ee..57cac719f 100644 --- a/doc/security.mdwn +++ b/doc/security.mdwn @@ -105,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. @@ -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). @@ -356,12 +360,50 @@ 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.