1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
|
If you are using ikiwiki to render pages that only you can edit, do not
generate any wrappers, and do not use the cgi, then there are no more
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.
If you find a new security vulnerability, please email the maintainers
privately instead of listing it in a public bug tracker, so that we can
arrange for coordinated disclosure when a fix is available. The maintainers
are [[Joey Hess|joey]] (<joey@kitenet.net>),
[[Simon McVittie|smcv]] (<smcv@debian.org>)
and [[Amitai Schleier|schmonz]] (<schmonz-web-ikiwiki@schmonz.com>).
[[!toc levels=2]]
----
# Probable holes
_(The list of things to fix.)_
## commit spoofing
Anyone with direct commit access can forge "web commit from foo" and
make it appear on [[RecentChanges]] like foo committed. One way to avoid
this would be to limit web commits to those done by a certain user.
## other stuff to look at
I have been meaning to see if any CRLF injection type things can be
done in the CGI code.
----
# Potential gotchas
_(Things not to do.)_
## image file etc attacks
If it enounters a file type it does not understand, ikiwiki just copies it
into place. So if you let users add any kind of file they like, they can
upload images, movies, windows executables, css files, etc (though not html
files). If these files exploit security holes in the browser of someone
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?
People with direct commit access can upload such files
(and if you wanted to you could block that with a pre-commit hook).
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
If multiple people can directly write to the source directory ikiwiki is
using, or to the destination directory it writes files to, then one can
cause trouble for the other when they run ikiwiki through symlink attacks.
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.
## page locking can be bypassed via direct commits
A locked page can only be edited on the web by an admin, but anyone who is
allowed to commit directly to the repository can bypass this. This is by
design, although a pre-commit hook could be used to prevent editing of
locked pages, if you really need to.
## web server attacks
If your web server does any parsing of special sorts of files (for example,
server parsed html files), then if you let anyone else add files to the wiki,
they can try to use this to exploit your web server.
----
# Hopefully non-holes
_(AKA, the assumptions that will be the root of most security holes...)_
## exploiting ikiwiki with bad content
Someone could add bad content to the wiki and hope to exploit ikiwiki.
Note that ikiwiki runs with perl taint checks on, so this is unlikely.
One fun thing in ikiwiki is its handling of a PageSpec, which involves
translating it into perl and running the perl. Of course, this is done
*very* carefully to guard against injecting arbitrary perl code.
## publishing cgi scripts
ikiwiki does not allow cgi scripts to be published as part of the wiki. Or
rather, the script is published, but it's not marked executable (except in
the case of "destination directory file replacement" below), so hopefully
your web server will not run it.
## suid wrappers
`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 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.
## shell exploits
ikiwiki does not expose untrusted data to the shell. In fact it doesn't use
`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
When ikiwiki runs as a cgi to edit a page, it is passed the name of the
page to edit. It has to make sure to sanitise this page, to prevent eg,
editing of ../../../foo, or editing of files that are not part of the wiki,
such as subversion dotfiles. This is done by sanitising the filename
removing unallowed characters, then making sure it doesn't start with "/"
or contain ".." or "/.svn/", etc. Annoyingly ad-hoc, this kind of code is
where security holes breed. It needs a test suite at the very least.
## CGI::Session security
I've audited this module and it is massively insecure by default. ikiwiki
uses it in one of the few secure ways; by forcing it to write to a
directory it controls (and not /tmp) and by setting a umask that makes the
file not be world readable.
## cgi password security
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 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).
It's difficult to know for sure if all such avenues have really been
closed though.
## HTML::Template security
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.)
----
# Plugins
The security of [[plugins]] depends on how well they're written and what
external tools they use. The plugins included in ikiwiki are all held to
the same standards as the rest of ikiwiki, but with that said, here are
some security notes for them.
* The [[plugins/img]] plugin assumes that imagemagick/perlmagick are secure
from malformed image attacks for at least the formats listed in
`img_allowed_formats`. Imagemagick has had security holes in the
past. To be able to exploit such a hole, a user would need to be able to
upload images to the wiki.
----
# Fixed holes
_(Unless otherwise noted, these were discovered and immediately fixed by the
ikiwiki developers.)_
## destination directory file replacement
Any file in the destination directory that is a valid page filename can be
replaced, even if it was not originally rendered from a page. For example,
ikiwiki.cgi could be edited in the wiki, and it would write out a
replacement. File permission is preseved. Yipes!
This was fixed by making ikiwiki check if the file it's writing to exists;
if it does then it has to be a file that it's aware of creating before, or
it will refuse to create it.
Still, this sort of attack is something to keep in mind.
## symlink attacks
Could a committer trick ikiwiki into following a symlink and operating on
some other tree that it shouldn't? svn supports symlinks, so one can get
into the repo. ikiwiki uses File::Find to traverse the repo, and does not
tell it to follow symlinks, but it might be possible to race replacing a
directory with a symlink and trick it into following the link.
Also, if someone checks in a symlink to /etc/passwd, ikiwiki would read and
publish that, which could be used to expose files a committer otherwise
wouldn't see.
To avoid this, ikiwiki will skip over symlinks when scanning for pages, and
uses locking to prevent more than one instance running at a time. The lock
prevents one ikiwiki from running a svn up/git pull/etc at the wrong time
to race another ikiwiki. So only attackers who can write to the working
copy on their own can race it.
## symlink + cgi attacks
Similarly, a commit of a symlink could be made, ikiwiki ignores it
because of the above, but the symlink is still there, and then you edit the
page from the web, which follows the symlink when reading the page
(exposing the content), and again when saving the changed page (changing
the content).
This was fixed for page saving by making ikiwiki refuse to write to files
that are symlinks, or that are in subdirectories that are symlinks,
combined with the above locking.
For page editing, it's fixed by ikiwiki checking to make sure that it
already has found a page by scanning the tree, before loading it for
editing, which as described above, also is done in a way that avoids
symlink attacks.
## underlaydir override attacks
ikiwiki also scans an underlaydir for pages, this is used to provide stock
pages to all wikis w/o needing to copy them into the wiki. Since ikiwiki
internally stores only the base filename from the underlaydir or srcdir,
and searches for a file in either directory when reading a page source,
there is the potential for ikiwiki's scanner to reject a file from the
srcdir for some reason (such as it being contained in a directory that is
symlinked in), find a valid copy of the file in the underlaydir, and then
when loading the file, mistakenly load the bad file from the srcdir.
This attack is avoided by making ikiwiki refuse to add any files from the
underlaydir if a file also exists in the srcdir with the same name.
## multiple page source issues
Note that I previously worried that underlay override attacks could also be
accomplished if ikiwiki were extended to support other page markup
languages besides markdown. However, a closer look indicates that this is
not a problem: ikiwiki does preserve the file extension when storing the
source filename of a page, so a file with another extension that renders to
the same page name can't bypass the check. Ie, ikiwiki won't skip foo.rst
in the srcdir, find foo.mdwn in the underlay, decide to render page foo and
then read the bad foo.mdwn. Instead it will remember the .rst extension and
only render a file with that extension.
## XSS attacks in page content
ikiwiki supports protecting users from their own broken browsers via the
[[plugins/htmlscrubber]] plugin, which is enabled by default.
## svn commit logs
It's was possible to force a whole series of svn commits to appear to
have come just before yours, by forging svn log output. This was
guarded against by using svn log --xml.
ikiwiki escapes any html in svn commit logs to prevent other mischief.
## XML::Parser
XML::Parser is used by the aggregation plugin, and has some security holes.
Bug #[378411](http://bugs.debian.org/378411) does not
seem to affect our use, since the data is not encoded as utf-8 at that
point. #[378412](http://bugs.debian.org/378412) could affect us, although it
doesn't seem very exploitable. It has a simple fix, and has been fixed in
Debian unstable.
## include loops
Various directives that cause one page to be included into another could
be exploited to DOS the wiki, by causing a loop. Ikiwiki has always guarded
against this one way or another; the current solution should detect all
types of loops involving preprocessor directives.
## Online editing of existing css and images
A bug in ikiwiki allowed the web-based editor to edit any file that was in
the wiki, not just files that are page sources. So an attacker (or a
genuinely helpful user, which is how the hole came to light) could edit
files like style.css. It is also theoretically possible that an attacker
could have used this hole to edit images or other files in the wiki, with
some difficulty, since all editing would happen in a textarea.
This hole was discovered on 10 Feb 2007 and fixed the same day with the
release of ikiwiki 1.42. A fix was also backported to Debian etch, as
version 1.33.1. I recommend upgrading to one of these versions if your wiki
allows web editing.
## html insertion via title
Missing html escaping of the title contents allowed a web-based editor to
insert arbitrary html inside the title tag of a page. Since that part of
the page is not processed by the htmlscrubber, evil html could be injected.
This hole was discovered on 21 March 2007 and fixed the same day (er, hour)
with the release of ikiwiki 1.46. A fix was also backported to Debian etch,
as version 1.33.2. I recommend upgrading to one of these versions if your
wiki allows web editing or aggregates feeds.
## javascript insertion via meta tags
It was possible to use the meta plugin's meta tags to insert arbitrary
url contents, which could be used to insert stylesheet information
containing javascript. This was fixed by sanitising meta tags.
This hole was discovered on 21 March 2007 and fixed the same day
with the release of ikiwiki 1.47. A fix was also backported to Debian etch,
as version 1.33.3. I recommend upgrading to one of these versions if your
wiki can be edited by third parties.
## insufficient checking for symlinks in srcdir path
Ikiwiki did not check if path to the srcdir to contained a symlink. If an
attacker had commit access to the directories in the path, they could
change it to a symlink, causing ikiwiki to read and publish files that were
not intended to be published. (But not write to them due to other checks.)
In most configurations, this is not exploitable, because the srcdir is
checked out of revision control, but the directories leading up to it are
not. Or, the srcdir is a single subdirectory of a project in revision
control (ie, `ikiwiki/doc`), and if the subdirectory were a symlink,
ikiwiki would still typically not follow it.
There are at least two configurations where this is exploitable:
* If the srcdir is a deeper subdirectory of a project. For example if it is
`project/foo/doc`, an an attacker can replace `foo` with a symlink to a
directory containing a `doc` directory (not a symlink), then ikiwiki
would follow the symlink.
* If the path to the srcdir in ikiwiki's configuration ended in "/",
and the srcdir is a single subdirectory of a project, (ie,
`ikiwiki/doc/`), the srcdir could be a symlink and ikiwiki would not
notice.
This security hole was discovered on 26 November 2007 and fixed the same
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 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.
## XSS via openid selector
Raghav Bisht discovered this XSS in the openid selector. ([[!cve CVE-2015-2793]])
The hole was reported on March 24th, a fix was developed on March 27th,
and the fixed version 3.20150329 was released on the 29th. A fix was backported
to Debian jessie as version 3.20141016.2 and to Debian wheezy as version
3.20120629.2. An upgrade is recommended for sites using CGI and openid.
## XSS via error messages
CGI error messages did not escape HTML meta-characters, potentially
allowing an attacker to carry out cross-site scripting by directing a
user to a URL that would result in a crafted ikiwiki error message. This
was discovered on 4 May by the ikiwiki developers, and the fixed version
3.20160506 was released on 6 May. The same fixes were backported to Debian
8 "jessie" in version 3.20141016.3. A backport to Debian 7 "wheezy" is
in progress.
An upgrade is recommended for sites using
the CGI. ([[!cve CVE-2016-4561]], OVE-20160505-0012)
## ImageMagick CVE-2016–3714 ("ImageTragick")
ikiwiki 3.20160506 and 3.20141016.3 attempt to mitigate
[[!cve CVE-2016-3714]], and any
future ImageMagick vulnerabilities that resemble it, by restricting the
image formats that the [[ikiwiki/directive/img]] directive is willing to
resize. An upgrade is recommended for sites where an untrusted user is
able to attach images. Upgrading ImageMagick to a version where
CVE-2016-3714 has been fixed is also recommended, but at the time of
writing no such version is available.
## Perl CVE-2016-1238 (current working directory in search path)
ikiwiki 3.20160728 attempts to mitigate [[!cve CVE-2016-1238]] by
removing `'.'` from the Perl library search path. An attacker with write
access to ikiwiki's current working directory could potentially use this
vulnerability to execute arbitrary Perl code. An upgrade is recommended
for sites where an untrusted user is able to attach files with arbitrary
names and/or run a setuid ikiwiki wrapper with a working directory of
their choice.
## <span id="cve-2016-9645">Editing restriction bypass for git revert</span>
intrigeri discovered that a web or git user could revert a change to a
page they are not allowed to edit, if the change being reverted was made
before the page was moved from a location where that user had permission
to edit it. For example, if a file is moved from `drafts/policy.mdwn`
(editable by less-trusted users) to `policy.mdwn` (only editable
by more-trusted users), a less-trusted user could revert a change
that was made to `drafts/policy.mdwn` prior to that move, and it would
result in `policy.mdwn` being altered.
This affects sites with the `git` VCS and the `recentchanges` plugin,
which are both used in most ikiwiki installations.
This bug was reported on 2016-12-17. A partially fixed version
3.20161219 was released on 2016-12-19, but the solution used in that
version was not effective with git versions older than 2.8.0.
A more complete fix was released on 2016-12-29 in version 3.20161229.
A backport to Debian 8 'jessie' is in progress.
([[!cve CVE-2016-10026]] represents the original vulnerability.
[[!cve CVE-2016-9645]]/OVE-20161226-0002 represents the vulnerability
in 3.20161219 caused by the incomplete fix.)
## <span id="cve-2016-9646">Commit metadata forgery via CGI::FormBuilder context-dependent APIs</span>
When CGI::FormBuilder->field("foo") is called in list context (and
in particular in the arguments to a subroutine that takes named
arguments), it can return zero or more values for foo from the CGI
request, rather than the expected single value. This breaks the usual
Perl parsing convention for named arguments, similar to CVE-2014-1572
in Bugzilla (which was caused by a similar API design issue in CGI.pm).
In ikiwiki, this appears to have been exploitable in two places, both
of them relatively minor:
* in the comments plugin, an attacker who was able to post a comment
could give it a user-specified author and author-URL even if the wiki
configuration did not allow for that, by crafting multiple values
for other fields
* in the editpage plugin, an attacker who was able to edit a page
could potentially forge commit authorship (attribute their edit to
someone else) by crafting multiple values for the rcsinfo field
This was fixed in ikiwiki 3.20161229. A backport to Debian 8
'jessie' is in progress.
([[!cve CVE-2016-9646]]/OVE-20161226-0001)
|