Current Perl versions put '.' at the end of the library search path
@INC, although this will be fixed in a future Perl release. This means
that when software loads an optionally-present module, it will be
looked for in the current working directory before giving up. An
attacker could use this to execute arbitrary Perl code from ikiwiki's
current working directory.
Removing '.' from the library search path in Perl is the correct
fix for this vulnerability, but is not trivial to do due to
backwards-compatibility concerns. Mitigate this (even if ikiwiki is run
with a vulnerable Perl version) by explicitly removing '.' from the
search path, and instead looking for ikiwiki's own modules relative
to the absolute path of the executable when run from the source
directory.
In tests that specifically want to use the current working directory,
use "-I".getcwd instead of "-I." so we use its absolute path, which
is immune to the removal of ".".
I didn't try to parameterize when a test should fail when we can't
remove ikiwiki.cgi because there already isn't one. (Hooray, natural
language.) Instead, we stop worrying about it and always tolerate
ENOENT.
Simon McVittie
Amitai Schlair