Item11953: {Site}{Locale} and tainted mode can't be used together. Ship with taint checking disabled.
Priority: Urgent
Current State: Closed
Released In: 2.0.0
Target Release: major
Applies To: Engine
Component: I18N
Branches: trunk master
When {Site}{Locale} is enabled, attempting to edit
SitePreferences results in a taint error:
Foswiki detected an internal error - please check your Foswiki logs and webserver logs for more information.
Insecure dependency in open while running with -T switch
My {Site}{Locale} is set to "en_GB.us88591", but I also tried changing GB to US, and the same thing happened.
--
PaulDann - 15 Jun 2012
Confirm the bug with "ru_RU.UTF8".
Apache log tells "Insecure dependency in open while running with -T switch at /srv/www/My Site/foswiki/lib/Foswiki/Store/VC/Handler.pm line 985".
I tried to fix it by writing this code
$name = Foswiki::Sandbox::untaintUnchecked($name);
before opening file to write at line mentioned above. It helped partially. Page opens but fails when I save it complaining on DBI data source.
--
AndreK - 11 Jul 2012
Confirm the bug with "pt_BR.iso88591" and "pt_BR.utf8".
--
JarbasJunior - 26 Jul 2012
Bug also appears with "de_DE.utf8"
--
SeeNetzer - 10 Sep 2012
Can we fix this for 1.1.6 or 1.2.0?
--
SvenDowideit - 22 Sep 2012 - 22:40
Confirm the bug with "el_GR.utf8"
--
StefanosKouzof - 01 Oct 2012
Untill there is a fix, the workaround is a) Disable {Site}{Locale} in /Configure b) Edit
SitePreferences, and c)Re-enable {Site}{Locale}
--
StefanosKouzof - 02 Oct 2012
This is because perl automatically taints all strings that go through locale-specific things, including:
-
\w
matches in regular expressions (so the corresponding capture variable(s) will still be tainted even though capture groups normally untaint things)
-
lc
and related functions
The reasoning is that in normal cases, users have the ability to change the locale and trick the program into accepting, say, quotes or semicolons as alphanumeric characters. In Foswiki, this is much less relevant since untrusted users have no way to change the locale for the underlying process.
Therefore, my proposed solution (which I'm already working on) is to forcibly untaint everything that would be untainted without locale security.
--
JanKrueger - 22 Oct 2012 - 08:51
If the untainting patch is too big for 1.1.6, let's set this to be a release 1.2 fix. When you have the patches ready, let me know and we can evaluate them for 1.1.6.
--
GeorgeClark - 24 Oct 2012
The issue is bigger than it first appeared.
perl 5.12 and later (and, to some extent, perl 5.10) has a bug in locale security. It causes tainted capture variables in many more cases than documented (and sane). For example,
/^(.*)[./](.*?)$/
(a regex from
normalizeWebTopicName
) will taint
$1
for no real reason. In general, this seems to happen whenever there is any character class in the regex (possibly only if it's in front of the capture group).
At this point I think it's getting infeasible to doctor all places that use regexes. So, the new proposal is to turn off locale everywhere and selectively turn it on in only those places where it's needed/wanted. This would be fairly wordy if we used the
require locale if (locale enabled)
thing everywhere, so it might make sense to introduce a new module containing locale-enabled helper functions that can be used instead.
--
JanKrueger - 05 Nov 2012
Duplicate
Item12065 has log details and stack trace
--
MyqLarson - 11 Dec 2012
@
JanKrueger "For example,
/^(.*)[./](.*?)$/
(a regex from
normalizeWebTopicName
) will taint
$1
for no real reason."
See the
closed Perl Bugreport #120675 reported there because of Foswiki's
Item12675 (for exactly the above regexp).
--
ChristianLudwig - 05 Dec 2013
@
ChristianLudwig indeed. Thanks for the pointer. Unfortunately, since we're supporting older versions of perl, too (most distributions don't even have 5.18.x in stable yet), we still have to consider how to get it to work in versions where this is still broken.
--
JanKrueger - 06 Dec 2013
In older Perl versions try
/^(.*)(?:\.|_)(.*?)$/
instead of
/^(.*)[./](.*?)$/
--
ChristianLudwig - 06 Dec 2013
Templates.pm has no uselocale but uses ucfirst. So does
CommentPlugin.pm Net.pm OP_uc.pm OP_lc.pm Rename.pm
Other modules use locale-sensitive ops, but on strings that are not going to contain "interesting" characters e.g. parts of requests.
We are going to try enabling locales everywhere, and see what sort of taint problems that exposes.
--
CrawfordCurrie - 14 Mar 2014
The short version: it exposes a
lot of taint problems. We will probably be deferring this one again – sorry.
By the way, currently
{UseLocale}
doesn't make any sense if your
{Site}{CharSet}
is UTF-8 because we don't have proper Unicode support yet.
--
JanKrueger - 14 Mar 2014
Disabled in 1.2.0 (expert option). Full fix deferred until 2.0.0
--
CrawfordCurrie - 14 Mar 2014
I have been fighting this issue for 4 hours - not being able to edit
SitePreferences. Do you really want to defer this to 2.0? How about finding out why it is
SitePreferences only that suffers from this problem? Or just remove those -T switches?
--
KennethLavrsen - 28 Jul 2014
It is definitely not only
SitePreferences. Lots of stuff breaks enabling
{Site}{Locale}
while still running perl in tainted mode. A lot of strings entering the system are considered tainted for some reason or the other even though they are not coming from the user. These then explode at random points in the call tree.
Removing those -T switches is sensible indeed, besides getting an approximate 10% performance improvement, they say. Some code changes are required in
FastCGIEngineContrib to
really remove tainted mode.
I've changed the title to be non-specific wrt
SitePreferences.
There are three options to proceed:
- ignore
{Site}{Locale}
.... that's what we do for 1.2.0 and that's what we tell everybody using any previous version of Foswiki -> switch off {Site}{Locale}
- remove tainted mode ... needs a feature proposal
- try to make locales work in tainted mode ... people tried that already and failed; this seems too hard to fix going down too deep into perl; from a Foswiki perspective it seems unfixable.
For 1.2.0 we probably should add a mega big warning sign in
configure
not to enable
{Site}{Locale}
unless you disable tainted mode as well.
(Btw. good to see you back)
--
MichaelDaum - 28 Jul 2014
We appear to have a big issue here that Lynnwood just found. - taint mode cannot be disabled under FCGI. It seems to spawn the perl process with -wT regardless of taint mode set in the scripts. Giving up fcgi seems to be a huge price to pay to get locales working.
--
GeorgeClark - 05 Sep 2014
Given that we are removing the -T flags for Foswiki 1.2, is this task completed for 1.2? All of the commits against this are in 1.2
--
GeorgeClark - 12 Jan 2015
Yes, as far as I can see.
--
MichaelDaum - 12 Jan 2015