Item11953: {Site}{Locale} and tainted mode can't be used together. Ship with taint checking disabled.

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:

1. 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}
2. remove tainted mode ... needs a feature proposal
3. 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

Commenting is disabled while not logged in