1If you are using ikiwiki to render pages that only you can edit, do not 2generate any wrappers, and do not use the cgi, then there are no more 3security issues with this program than with cat(1). If, however, you let 4others edit pages in your wiki, then some possible security issues do need 5to be kept in mind. 6 7If you find a new security vulnerability, please email the maintainers 8privately instead of listing it in a public bug tracker, so that we can 9arrange for coordinated disclosure when a fix is available. The maintainers 10are [[Joey Hess|joey]] (<joey@kitenet.net>), 11[[Simon McVittie|smcv]] (<smcv@debian.org>) 12and [[Amitai Schleier|schmonz]] (<schmonz-web-ikiwiki@schmonz.com>). 13 14[[!toc levels=2]] 15 16---- 17 18# Probable holes 19 20_(The list of things to fix.)_ 21 22## commit spoofing 23 24Anyone with direct commit access can forge "web commit from foo" and 25make it appear on [[RecentChanges]] like foo committed. One way to avoid 26this would be to limit web commits to those done by a certain user. 27 28## other stuff to look at 29 30I have been meaning to see if any CRLF injection type things can be 31done in the CGI code. 32 33---- 34 35# Potential gotchas 36 37_(Things not to do.)_ 38 39## image file etc attacks 40 41If it enounters a file type it does not understand, ikiwiki just copies it 42into place. So if you let users add any kind of file they like, they can 43upload images, movies, windows executables, css files, etc (though not html 44files). If these files exploit security holes in the browser of someone 45who's viewing the wiki, that can be a security problem. 46 47Of course nobody else seems to worry about this in other wikis, so should we? 48 49People with direct commit access can upload such files 50(and if you wanted to you could block that with a pre-commit hook). 51 52The attachments plugin is not enabled by default. If you choose to 53enable it, you should make use of its powerful abilities to filter allowed 54types of attachments, and only let trusted users upload. 55 56It is possible to embed an image in a page edited over the web, by using 57`img src="data:image/png;"`. Ikiwiki's htmlscrubber only allows `data:` 58urls to be used for `image/*` mime types. It's possible that some broken 59browser might ignore the mime type and if the data provided is not an 60image, instead run it as javascript, or something evil like that. Hopefully 61not many browsers are that broken. 62 63## multiple accessors of wiki directory 64 65If multiple people can directly write to the source directory ikiwiki is 66using, or to the destination directory it writes files to, then one can 67cause trouble for the other when they run ikiwiki through symlink attacks. 68 69So it's best if only one person can ever directly write to those directories. 70 71## setup files 72 73Setup files are not safe to keep in the same revision control repository 74with the rest of the wiki. Just don't do it. 75 76## page locking can be bypassed via direct commits 77 78A locked page can only be edited on the web by an admin, but anyone who is 79allowed to commit directly to the repository can bypass this. This is by 80design, although a pre-commit hook could be used to prevent editing of 81locked pages, if you really need to. 82 83## web server attacks 84 85If your web server does any parsing of special sorts of files (for example, 86server parsed html files), then if you let anyone else add files to the wiki, 87they can try to use this to exploit your web server. 88 89---- 90 91# Hopefully non-holes 92 93_(AKA, the assumptions that will be the root of most security holes...)_ 94 95## exploiting ikiwiki with bad content 96 97Someone could add bad content to the wiki and hope to exploit ikiwiki. 98Note that ikiwiki runs with perl taint checks on, so this is unlikely. 99 100One fun thing in ikiwiki is its handling of a PageSpec, which involves 101translating it into perl and running the perl. Of course, this is done 102*very* carefully to guard against injecting arbitrary perl code. 103 104## publishing cgi scripts 105 106ikiwiki does not allow cgi scripts to be published as part of the wiki. Or 107rather, the script is published, but it's not marked executable (except in 108the case of "destination directory file replacement" below), so hopefully 109your web server will not run it. 110 111## suid wrappers 112 113`ikiwiki --wrapper` is intended to generate a wrapper program that 114runs ikiwiki to update a given wiki. The wrapper can in turn be made suid, 115for example to be used in a [[post-commit]] hook by people who cannot write 116to the html pages, etc. 117 118If the wrapper program is made suid, then any bugs in this wrapper would be 119security holes. The wrapper is written as securely as I know how, is based 120on code that has a history of security use long before ikiwiki, and there's 121been no problem yet. 122 123## shell exploits 124 125ikiwiki does not expose untrusted data to the shell. In fact it doesn't use 126`system(3)` at all, and the only use of backticks is on data supplied by the 127wiki admin and untainted filenames. 128 129Ikiwiki was developed and used for a long time with perl's taint checking 130turned on as a second layer of defense against shell and other exploits. Due 131to a strange [bug](http://bugs.debian.org/411786) in perl, taint checking 132is currently disabled for production builds of ikiwiki. 133 134## cgi data security 135 136When ikiwiki runs as a cgi to edit a page, it is passed the name of the 137page to edit. It has to make sure to sanitise this page, to prevent eg, 138editing of ../../../foo, or editing of files that are not part of the wiki, 139such as subversion dotfiles. This is done by sanitising the filename 140removing unallowed characters, then making sure it doesn't start with "/" 141or contain ".." or "/.svn/", etc. Annoyingly ad-hoc, this kind of code is 142where security holes breed. It needs a test suite at the very least. 143 144## CGI::Session security 145 146I've audited this module and it is massively insecure by default. ikiwiki 147uses it in one of the few secure ways; by forcing it to write to a 148directory it controls (and not /tmp) and by setting a umask that makes the 149file not be world readable. 150 151## cgi password security 152 153Login to the wiki using [[plugins/passwordauth]] involves sending a password 154in cleartext over the net. Cracking the password only allows editing the wiki 155as that user though. If you care, you can use https, I suppose. If you do use 156https either for all of the wiki, or just the cgi access, then consider using 157the sslcookie option. Using [[plugins/openid]] is a potentially better option. 158 159## XSS holes in CGI output 160 161ikiwiki has been audited to ensure that all cgi script input/output 162is sanitised to prevent XSS attacks. For example, a user can't register 163with a username containing html code (anymore). 164 165It's difficult to know for sure if all such avenues have really been 166closed though. 167 168## HTML::Template security 169 170If the [[plugins/template]] plugin is enabled, all users can modify templates 171like any other part of the wiki. Some trusted users can modify templates 172without it too. This assumes that HTML::Template is secure 173when used with untrusted/malicious templates. (Note that includes are not 174allowed.) 175 176---- 177 178# Plugins 179 180The security of [[plugins]] depends on how well they're written and what 181external tools they use. The plugins included in ikiwiki are all held to 182the same standards as the rest of ikiwiki, but with that said, here are 183some security notes for them. 184 185* The [[plugins/img]] plugin assumes that imagemagick/perlmagick are secure 186 from malformed image attacks for at least the formats listed in 187 `img_allowed_formats`. Imagemagick has had security holes in the 188 past. To be able to exploit such a hole, a user would need to be able to 189 upload images to the wiki. 190 191---- 192 193# Fixed holes 194 195_(Unless otherwise noted, these were discovered and immediately fixed by the 196ikiwiki developers.)_ 197 198## destination directory file replacement 199 200Any file in the destination directory that is a valid page filename can be 201replaced, even if it was not originally rendered from a page. For example, 202ikiwiki.cgi could be edited in the wiki, and it would write out a 203replacement. File permission is preseved. Yipes! 204 205This was fixed by making ikiwiki check if the file it's writing to exists; 206if it does then it has to be a file that it's aware of creating before, or 207it will refuse to create it. 208 209Still, this sort of attack is something to keep in mind. 210 211## symlink attacks 212 213Could a committer trick ikiwiki into following a symlink and operating on 214some other tree that it shouldn't? svn supports symlinks, so one can get 215into the repo. ikiwiki uses File::Find to traverse the repo, and does not 216tell it to follow symlinks, but it might be possible to race replacing a 217directory with a symlink and trick it into following the link. 218 219Also, if someone checks in a symlink to /etc/passwd, ikiwiki would read and 220publish that, which could be used to expose files a committer otherwise 221wouldn't see. 222 223To avoid this, ikiwiki will skip over symlinks when scanning for pages, and 224uses locking to prevent more than one instance running at a time. The lock 225prevents one ikiwiki from running a svn up/git pull/etc at the wrong time 226to race another ikiwiki. So only attackers who can write to the working 227copy on their own can race it. 228 229## symlink + cgi attacks 230 231Similarly, a commit of a symlink could be made, ikiwiki ignores it 232because of the above, but the symlink is still there, and then you edit the 233page from the web, which follows the symlink when reading the page 234(exposing the content), and again when saving the changed page (changing 235the content). 236 237This was fixed for page saving by making ikiwiki refuse to write to files 238that are symlinks, or that are in subdirectories that are symlinks, 239combined with the above locking. 240 241For page editing, it's fixed by ikiwiki checking to make sure that it 242already has found a page by scanning the tree, before loading it for 243editing, which as described above, also is done in a way that avoids 244symlink attacks. 245 246## underlaydir override attacks 247 248ikiwiki also scans an underlaydir for pages, this is used to provide stock 249pages to all wikis w/o needing to copy them into the wiki. Since ikiwiki 250internally stores only the base filename from the underlaydir or srcdir, 251and searches for a file in either directory when reading a page source, 252there is the potential for ikiwiki's scanner to reject a file from the 253srcdir for some reason (such as it being contained in a directory that is 254symlinked in), find a valid copy of the file in the underlaydir, and then 255when loading the file, mistakenly load the bad file from the srcdir. 256 257This attack is avoided by making ikiwiki refuse to add any files from the 258underlaydir if a file also exists in the srcdir with the same name. 259 260## multiple page source issues 261 262Note that I previously worried that underlay override attacks could also be 263accomplished if ikiwiki were extended to support other page markup 264languages besides markdown. However, a closer look indicates that this is 265not a problem: ikiwiki does preserve the file extension when storing the 266source filename of a page, so a file with another extension that renders to 267the same page name can't bypass the check. Ie, ikiwiki won't skip foo.rst 268in the srcdir, find foo.mdwn in the underlay, decide to render page foo and 269then read the bad foo.mdwn. Instead it will remember the .rst extension and 270only render a file with that extension. 271 272## XSS attacks in page content 273 274ikiwiki supports protecting users from their own broken browsers via the 275[[plugins/htmlscrubber]] plugin, which is enabled by default. 276 277## svn commit logs 278 279It's was possible to force a whole series of svn commits to appear to 280have come just before yours, by forging svn log output. This was 281guarded against by using svn log --xml. 282 283ikiwiki escapes any html in svn commit logs to prevent other mischief. 284 285## XML::Parser 286 287XML::Parser is used by the aggregation plugin, and has some security holes. 288Bug #[378411](http://bugs.debian.org/378411) does not 289seem to affect our use, since the data is not encoded as utf-8 at that 290point. #[378412](http://bugs.debian.org/378412) could affect us, although it 291doesn't seem very exploitable. It has a simple fix, and has been fixed in 292Debian unstable. 293 294## include loops 295 296Various directives that cause one page to be included into another could 297be exploited to DOS the wiki, by causing a loop. Ikiwiki has always guarded 298against this one way or another; the current solution should detect all 299types of loops involving preprocessor directives. 300 301## Online editing of existing css and images 302 303A bug in ikiwiki allowed the web-based editor to edit any file that was in 304the wiki, not just files that are page sources. So an attacker (or a 305genuinely helpful user, which is how the hole came to light) could edit 306files like style.css. It is also theoretically possible that an attacker 307could have used this hole to edit images or other files in the wiki, with 308some difficulty, since all editing would happen in a textarea. 309 310This hole was discovered on 10 Feb 2007 and fixed the same day with the 311release of ikiwiki 1.42. A fix was also backported to Debian etch, as 312version 1.33.1. I recommend upgrading to one of these versions if your wiki 313allows web editing. 314 315## html insertion via title 316 317Missing html escaping of the title contents allowed a web-based editor to 318insert arbitrary html inside the title tag of a page. Since that part of 319the page is not processed by the htmlscrubber, evil html could be injected. 320 321This hole was discovered on 21 March 2007 and fixed the same day (er, hour) 322with the release of ikiwiki 1.46. A fix was also backported to Debian etch, 323as version 1.33.2. I recommend upgrading to one of these versions if your 324wiki allows web editing or aggregates feeds. 325 326## javascript insertion via meta tags 327 328It was possible to use the meta plugin's meta tags to insert arbitrary 329url contents, which could be used to insert stylesheet information 330containing javascript. This was fixed by sanitising meta tags. 331 332This hole was discovered on 21 March 2007 and fixed the same day 333with the release of ikiwiki 1.47. A fix was also backported to Debian etch, 334as version 1.33.3. I recommend upgrading to one of these versions if your 335wiki can be edited by third parties. 336 337## insufficient checking for symlinks in srcdir path 338 339Ikiwiki did not check if path to the srcdir to contained a symlink. If an 340attacker had commit access to the directories in the path, they could 341change it to a symlink, causing ikiwiki to read and publish files that were 342not intended to be published. (But not write to them due to other checks.) 343 344In most configurations, this is not exploitable, because the srcdir is 345checked out of revision control, but the directories leading up to it are 346not. Or, the srcdir is a single subdirectory of a project in revision 347control (ie, `ikiwiki/doc`), and if the subdirectory were a symlink, 348ikiwiki would still typically not follow it. 349 350There are at least two configurations where this is exploitable: 351 352* If the srcdir is a deeper subdirectory of a project. For example if it is 353 `project/foo/doc`, an an attacker can replace `foo` with a symlink to a 354 directory containing a `doc` directory (not a symlink), then ikiwiki 355 would follow the symlink. 356* If the path to the srcdir in ikiwiki's configuration ended in "/", 357 and the srcdir is a single subdirectory of a project, (ie, 358 `ikiwiki/doc/`), the srcdir could be a symlink and ikiwiki would not 359 notice. 360 361This security hole was discovered on 26 November 2007 and fixed the same 362day with the release of ikiwiki 2.14. I recommend upgrading to this version 363if your wiki can be committed to by third parties. Alternatively, don't use 364a trailing slash in the srcdir, and avoid the (unusual) configurations that 365allow the security hole to be exploited. 366 367## javascript insertion via uris 368 369The htmlscrubber did not block javascript in uris. This was fixed by adding 370a whitelist of valid uri types, which does not include javascript. 371([[!debcve CVE-2008-0809]]) Some urls specifyable by the meta plugin could also 372theoretically have been used to inject javascript; this was also blocked 373([[!debcve CVE-2008-0808]]). 374 375This hole was discovered on 10 February 2008 and fixed the same day 376with the release of ikiwiki 2.31.1. (And a few subsequent versions..) 377A fix was also backported to Debian etch, as version 1.33.4. I recommend 378upgrading to one of these versions if your wiki can be edited by third 379parties. 380 381## Cross Site Request Forging 382 383Cross Site Request Forging could be used to constuct a link that would 384change a logged-in user's password or other preferences if they clicked on 385the link. It could also be used to construct a link that would cause a wiki 386page to be modified by a logged-in user. ([[!debcve CVE-2008-0165]]) 387 388These holes were discovered on 10 April 2008 and fixed the same day with 389the release of ikiwiki 2.42. A fix was also backported to Debian etch, as 390version 1.33.5. I recommend upgrading to one of these versions. 391 392## Cleartext passwords 393 394Until version 2.48, ikiwiki stored passwords in cleartext in the `userdb`. 395That risks exposing all users' passwords if the file is somehow exposed. To 396pre-emtively guard against that, current versions of ikiwiki store password 397hashes (using Eksblowfish). 398 399If you use the [[plugins/passwordauth]] plugin, I recommend upgrading to 400ikiwiki 2.48, installing the [[!cpan Authen::Passphrase]] perl module, and running 401`ikiwiki-transition hashpassword` to replace all existing cleartext passwords 402with strong blowfish hashes. 403 404You might also consider changing to [[plugins/openid]], which does not 405require ikiwiki deal with passwords at all, and does not involve users sending 406passwords in cleartext over the net to log in, either. 407 408## Empty password security hole 409 410This hole allowed ikiwiki to accept logins using empty passwords, to openid 411accounts that didn't use a password. It was introduced in version 1.34, and 412fixed in version 2.48. The [bug](http://bugs.debian.org/483770) was 413discovered on 30 May 2008 and fixed the same day. ([[!debcve CVE-2008-0169]]) 414 415I recommend upgrading to 2.48 immediatly if your wiki allows both password 416and openid logins. 417 418## Malformed UTF-8 DOS 419 420Feeding ikiwiki page sources containing certian forms of malformed UTF-8 421can cause it to crash. This can potentially be used for a denial of service 422attack. 423 424intrigeri discovered this problem on 12 Nov 2008 and a patch put in place 425later that day, in version 2.70. The fix was backported to testing as version 4262.53.3, and to stable as version 1.33.7. 427 428## Insufficient blacklisting in teximg plugin 429 430Josh Triplett discovered on 28 Aug 2009 that the teximg plugin's 431blacklisting of insecure TeX commands was insufficient; it could be 432bypassed and used to read arbitrary files. This was fixed by 433enabling TeX configuration options that disallow unsafe TeX commands. 434The fix was released on 30 Aug 2009 in version 3.1415926, and was 435backported to stable in version 2.53.4. If you use the teximg plugin, 436I recommend upgrading. ([[!debcve CVE-2009-2944]]) 437 438## javascript insertion via svg uris 439 440Ivan Shmakov pointed out that the htmlscrubber allowed `data:image/*` urls, 441including `data:image/svg+xml`. But svg can contain javascript, so that is 442unsafe. 443 444This hole was discovered on 12 March 2010 and fixed the same day 445with the release of ikiwiki 3.20100312. 446A fix was also backported to Debian etch, as version 2.53.5. I recommend 447upgrading to one of these versions if your wiki can be edited by third 448parties. 449 450## javascript insertion via insufficient htmlscrubbing of comments 451 452Kevin Riggle noticed that it was not possible to configure 453`htmlscrubber_skip` to scrub comments while leaving unscubbed the text 454of eg, blog posts. Confusingly, setting it to "* and !comment(*)" did not 455scrub comments. 456 457Additionally, it was discovered that comments' html was never scrubbed during 458preview or moderation of comments with such a configuration. 459 460These problems were discovered on 12 November 2010 and fixed the same 461hour with the release of ikiwiki 3.20101112. ([[!debcve CVE-2010-1673]]) 462 463## javascript insertion via insufficient checking in comments 464 465Dave B noticed that attempting to comment on an illegal page name could be 466used for an XSS attack. 467 468This hole was discovered on 22 Jan 2011 and fixed the same day with 469the release of ikiwiki 3.20110122. A fix was backported to Debian squeeze, 470as version 3.20100815.5. An upgrade is recommended for sites 471with the comments plugin enabled. ([[!debcve CVE-2011-0428]]) 472 473## possible javascript insertion via insufficient htmlscrubbing of alternate stylesheets 474 475Giuseppe Bilotta noticed that 'meta stylesheet` directives allowed anyone 476who could upload a malicious stylesheet to a site to add it to a 477page as an alternate stylesheet, or replacing the default stylesheet. 478 479This hole was discovered on 28 Mar 2011 and fixed the same hour with 480the release of ikiwiki 3.20110328. A fix was backported to Debian squeeze, 481as version 3.20100815.6. An upgrade is recommended for sites that have 482untrusted committers, or have the attachments plugin enabled. 483([[!debcve CVE-2011-1401]]) 484 485## tty hijacking via ikiwiki-mass-rebuild 486 487Ludwig Nussel discovered a way for users to hijack root's tty when 488ikiwiki-mass-rebuild was run. Additionally, there was some potential 489for information disclosure via symlinks. ([[!debcve CVE-2011-1408]]) 490 491This hole was discovered on 8 June 2011 and fixed the same day with 492the release of ikiwiki 3.20110608. Note that the fix is dependant on 493a version of su that has a similar hole fixed. Version 4.1.5 of the shadow 494package contains the fixed su; [[!debbug 628843]] tracks fixing the hole in 495Debian. An upgrade is a must for any sites that have `ikiwiki-update-wikilist` 496installed suid (not the default), and whose admins run `ikiwiki-mass-rebuild`. 497 498## javascript insertion via meta tags 499 500Raúl Benencia discovered an additional XSS exposure in the meta plugin. 501([[!debcve CVE-2012-0220]]) 502 503This hole was discovered on 16 May 2012 and fixed the same day with 504the release of ikiwiki 3.20120516. A fix was backported to Debian squeeze, 505as version 3.20100815.9. An upgrade is recommended for all sites. 506 507## XSS via openid selector 508 509Raghav Bisht discovered this XSS in the openid selector. ([[!debcve CVE-2015-2793]]) 510 511The hole was reported on March 24th, a fix was developed on March 27th, 512and the fixed version 3.20150329 was released on the 29th. A fix was backported 513to Debian jessie as version 3.20141016.2 and to Debian wheezy as version 5143.20120629.2. An upgrade is recommended for sites using CGI and openid. 515 516## XSS via error messages 517 518CGI error messages did not escape HTML meta-characters, potentially 519allowing an attacker to carry out cross-site scripting by directing a 520user to a URL that would result in a crafted ikiwiki error message. This 521was discovered on 4 May by the ikiwiki developers, and the fixed version 5223.20160506 was released on 6 May. The same fixes were backported to Debian 5238 "jessie" in version 3.20141016.3. A backport to Debian 7 "wheezy" is 524in progress. 525 526An upgrade is recommended for sites using 527the CGI. ([[!debcve CVE-2016-4561]], OVE-20160505-0012) 528 529## ImageMagick CVE-2016–3714 ("ImageTragick") 530 531ikiwiki 3.20160506 and 3.20141016.3 attempt to mitigate 532[[!debcve CVE-2016-3714]], and any 533future ImageMagick vulnerabilities that resemble it, by restricting the 534image formats that the [[ikiwiki/directive/img]] directive is willing to 535resize. An upgrade is recommended for sites where an untrusted user is 536able to attach images. Upgrading ImageMagick to a version where 537CVE-2016-3714 has been fixed is also recommended, but at the time of 538writing no such version is available. 539 540## Perl CVE-2016-1238 (current working directory in search path) 541 542ikiwiki 3.20160728 attempts to mitigate [[!debcve CVE-2016-1238]] by 543removing `'.'` from the Perl library search path. An attacker with write 544access to ikiwiki's current working directory could potentially use this 545vulnerability to execute arbitrary Perl code. An upgrade is recommended 546for sites where an untrusted user is able to attach files with arbitrary 547names and/or run a setuid ikiwiki wrapper with a working directory of 548their choice. 549 550## <span id="cve-2016-9645">Editing restriction bypass for git revert</span> 551 552intrigeri discovered that a web or git user could revert a change to a 553page they are not allowed to edit, if the change being reverted was made 554before the page was moved from a location where that user had permission 555to edit it. For example, if a file is moved from `drafts/policy.mdwn` 556(editable by less-trusted users) to `policy.mdwn` (only editable 557by more-trusted users), a less-trusted user could revert a change 558that was made to `drafts/policy.mdwn` prior to that move, and it would 559result in `policy.mdwn` being altered. 560 561This affects sites with the `git` VCS and the `recentchanges` plugin, 562which are both used in most ikiwiki installations. 563 564This bug was reported on 2016-12-17. A partially fixed version 5653.20161219 was released on 2016-12-19, but the solution used in that 566version was not effective with git versions older than 2.8.0. 567A more complete fix was released on 2016-12-29 in version 3.20161229, 568with fixes backported to Debian 8 in version 3.20141016.4. 569 570([[!debcve CVE-2016-10026]] represents the original vulnerability. 571[[!debcve CVE-2016-9645]]/OVE-20161226-0002 represents the vulnerability 572in 3.20161219 caused by the incomplete fix.) 573 574## <span id="cve-2016-9646">Commit metadata forgery via CGI::FormBuilder context-dependent APIs</span> 575 576When CGI::FormBuilder->field("foo") is called in list context (and 577in particular in the arguments to a subroutine that takes named 578arguments), it can return zero or more values for foo from the CGI 579request, rather than the expected single value. This breaks the usual 580Perl parsing convention for named arguments, similar to CVE-2014-1572 581in Bugzilla (which was caused by a similar API design issue in CGI.pm). 582 583In ikiwiki, this appears to have been exploitable in two places, both 584of them relatively minor: 585 586* in the comments plugin, an attacker who was able to post a comment 587 could give it a user-specified author and author-URL even if the wiki 588 configuration did not allow for that, by crafting multiple values 589 for other fields 590* in the editpage plugin, an attacker who was able to edit a page 591 could potentially forge commit authorship (attribute their edit to 592 someone else) by crafting multiple values for the rcsinfo field 593 594This was fixed in ikiwiki 3.20161229, with fixes backported to Debian 8 595in version 3.20141016.4. 596 597([[!debcve CVE-2016-9646]]/OVE-20161226-0001) 598 599## <span id="cve-2017-0356">Authentication bypass via repeated parameters</span> 600 601The ikiwiki maintainers discovered further flaws similar to CVE-2016-9646 602in the passwordauth plugin's use of CGI::FormBuilder, with a more 603serious impact: 604 605* An attacker who can log in to a site with a password can log in 606 as a different and potentially more privileged user. 607* An attacker who can create a new account can set arbitrary fields 608 in the user database for that account. 609 610This was fixed in ikiwiki 3.20170111, with fixes backported to Debian 8 611in version 3.20141016.4. 612 613([[!debcve CVE-2017-0356]]/OVE-20170111-0001) 614 615## <span id="cve-2019-9187">Server-side request forgery via aggregate plugin</span> 616 617The ikiwiki maintainers discovered that the [[plugins/aggregate]] plugin 618did not use [[!cpan LWPx::ParanoidAgent]]. On sites where the 619aggregate plugin is enabled, authorized wiki editors could tell ikiwiki 620to fetch potentially undesired URIs even if LWPx::ParanoidAgent was 621installed: 622 623* local files via `file:` URIs 624* other URI schemes that might be misused by attackers, such as `gopher:` 625* hosts that resolve to loopback IP addresses (127.x.x.x) 626* hosts that resolve to RFC 1918 IP addresses (192.168.x.x etc.) 627 628This could be used by an attacker to publish information that should not have 629been accessible, cause denial of service by requesting "tarpit" URIs that are 630slow to respond, or cause undesired side-effects if local web servers implement 631["unsafe"](https://tools.ietf.org/html/rfc7231#section-4.2.1) GET requests. 632([[!debcve CVE-2019-9187]]) 633 634Additionally, if the LWPx::ParanoidAgent module was not installed, the 635[[plugins/blogspam]], [[plugins/openid]] and [[plugins/pinger]] plugins 636would fall back to [[!cpan LWP]], which is susceptible to similar attacks. 637This is unlikely to be a practical problem for the blogspam plugin because 638the URL it requests is under the control of the wiki administrator, but 639the openid plugin can request URLs controlled by unauthenticated remote 640users, and the pinger plugin can request URLs controlled by authorized 641wiki editors. 642 643This is addressed in ikiwiki 3.20190228 as follows, with the same fixes 644backported to Debian 9 in version 3.20170111.1: 645 646* URI schemes other than `http:` and `https:` are not accepted, preventing 647 access to `file:`, `gopher:`, etc. 648 649* If a proxy is [[configured in the ikiwiki setup file|tips/using_a_proxy]], 650 it is used for all outgoing `http:` and `https:` requests. In this case 651 the proxy is responsible for blocking any requests that are undesired, 652 including loopback or RFC 1918 addresses. 653 654* If a proxy is not configured, and LWPx::ParanoidAgent is installed, 655 it will be used. This prevents loopback and RFC 1918 IP addresses, and 656 sets a timeout to avoid denial of service via "tarpit" URIs. 657 658* Otherwise, the ordinary LWP user-agent will be used. This allows requests 659 to loopback and RFC 1918 IP addresses, and has less robust timeout 660 behaviour. We are not treating this as a vulnerability: if this 661 behaviour is not acceptable for your site, please make sure to install 662 LWPx::ParanoidAgent or disable the affected plugins. 663