SID-02145: Recurring error

Status:	Answered	TWiki version:		Perl version:	v5.20.2
Category:	CategoryTemplates	Server OS:	Debian GNU/Linux 8	Last update:	9 years ago

I installed the TurnKey Linux Twiki distribution (https://www.turnkeylinux.org/twiki), Twiki 6.0.1, and migrated my data as per the upgrade documentation from a very old version (4.x) of twiki. After doing so everything worked fine for several weeks, and then the day before yesterday I received the following error when opening any Twiki topic:

Insecure dependency in sysopen while running with -T switch at /usr/share/perl5/CGI/Session/Driver/file.pm line 107.

So, yesterday, not being much of a Perl programmer (though I did read up on the sysopen call that seems to be the source of the error), and after making sure all of the file permissions in the /var/www/twiki folder were correct and being unable to resolve the issue, I backed up the /pub and /data folders, and rebuilt the VM and re-migrated it. So far so good - everything worked again.

So, this morning when I started twiki I was distressed to see the same error. Fortunately, I've gotten very fast at these upgrades so I rebuilt the server AGAIN in under an hour.

Can you please tell me how to resolve this issue?

-- Christopher Bobbitt - 2016-01-14

Discussion and Answer

Not sure. Since you got TWiki from another supplier you could ask there for support. Or, get our latest TWiki-VM, DownloadTWikiVM

-- Peter Thoeny - 2016-01-14

I guess I can explain the issue, but I can only suggest workarounds. I am pretty sure that your Perl version is actually Debian's package 5.20.2-3+deb8u2.

The symptoms match an issue reported two days ago for CGI::Session by another twiki admin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810799. It boils down to a security patch issued three days ago for Debian, exposing a so-far-undiscovered bug: https://www.debian.org/security/2016/dsa-3441.en.html. Your OS and Perl versions match perfectly, and so does the date of the first occurrence of your problem.

I would guess that there'll be a fix by the Debian folks, or by the CGI::Session maintainer, soon-ish. Maybe the turnkeylinux guys will also provide a workaround/fix, so Peter's suggestion to contact them is certainly a good idea.

For an immediate workaround, one possible way would be to downgrade Perl to 5.20.2-3+deb8u1: The security issue can't be exploited by a malicious user in TWiki context. An alternative would be to apply the three-line patch as suggested by Chris Boot in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810799.

Good luck!

-- Harald Jörg - 2016-01-14

Unfortunately, there's more to the problem than just the above bug. I'm now trying to come up with a test case that exercises the code path that TWiki is using, but I can't replicate the problem outside TWiki.

In short: Debian have updated libcgi-session-perl to fix the bug that is tickled by the test case in https://rt.cpan.org/Public/Bug/Display.html?id=80346, but TWiki still fails with the same "Insecure dependency in sysopen" problem.

I'd really appreciate some help in reproducing this as a simple test case that tickles the bug, as that would go a long way to getting a fix and making sure it doesn't regress in future (in Debian at least).

Thanks, Chris

-- Chris Boot - 2016-01-29

Taint problems can be tricky to track down, and this seems to be no exception. Eventually I have found a Debian Jessie system with perl 5.20.2-3+deb8u2 and libcgi-session-perl 4.48-1 installed. I could reproduce the test case and insecure dependency from https://rt.cpan.org/Public/Bug/Display.html?id=80346.

Installing TWiki 6.0.1 on this system fails due to a more-or-less known problem with that version and libcgi-pm-perl 4.09-1, so I installed TWiki 6.0.2... and haven't encountered an insecure dependency. With 6.0.2, I can't reproduce the problem inside TWiki.

I then force-downgraded the 6.0.2 installation to 6.0.1, and there it is: Insecure dependency in sysopen while running with -T switch at /usr/share/perl5/CGI/Session/Driver/file.pm line 107.

Given that TWiki 6.0.1 has problems with Debian Jessie, an upgrade to 6.0.2 would be a good move, and maybe also get rid of the taint problem. Nonetheless I'll have a look whether I manage to narrow it down.

-- Harald Jörg - 2016-02-03

Hi, I am randomly experiencing described problem also on 6.0.2 and Debian Jessie.

-- Jiri Cervenka - 2016-02-04

And one more point. The problem disappears when I delete cookies for twiki in my browser.

-- Jiri Cervenka - 2016-02-04

Thanks, Jiri, for sharing your observations! Unfortunately, this confirms results from my own experiments. The issue has some sort of randomness, I could get the error to vanish and re-appear by adding and deleting a simple print statement.

• Deleting cookies avoids the interesting paths in the code because it enforces the creation of a new session: Cookies come in as "tainted".
• Deleting the session files on the server, on the other hand, is likely to trigger the error.

More debugging is required... after some sleep.

-- Harald Jörg - 2016-02-06

At this point I must say that digging deeper is beyond my knowledge. The best material I could come up with is this: I peppered =CGI/Session/Driver/file.pm with some diagnostic prints:

--- /usr/share/perl5/CGI/Session/Driver/file.pm   2016-01-15 16:42:31.000000000 +0100
+++ /mnt/devel/lib/CGI/Session/Driver/file.pm   2016-02-07 00:47:27.710588100 +0100
@@ -10,4 +10,5 @@
 use CGI::Session::Driver;
 use vars qw( $FileName $NoFlock $UMask $NO_FOLLOW );
+use Scalar::Util qw(tainted);                                             ##
 
 BEGIN {
@@ -61,4 +62,7 @@
 
     my $path = $self->_file($sid);
+    warn "-------- retrieve($sid)";                                       ##
+    warn "sid=$sid is" .   (tainted $sid  ? " " : " not ") . "tainted"; ##
+    warn "path=$path is" . (tainted $path ? " " : " not ") . "tainted"; ##
     
     return 0 unless -e $path;
@@ -91,4 +95,7 @@
     
     my $path = $self->_file($sid);
+    warn "-------- store ($sid) -----\n";                                 ##
+    warn "sid=$sid is" .   (tainted $sid  ? " " : " not ") . "tainted"; ##
+    warn "path=$path is" . (tainted $path ? " " : " not ") . "tainted"; ##
     
     # make certain our filehandle goes away when we fall out of scope

This gives the following report on STDERR:

-------- retrieve(b9a14006fb7c75feffb525642f5079fd)
sid=b9a14006fb7c75feffb525642f5079fd is tainted
path=/srv/twiki/working/tmp/cgisess_b9a14006fb7c75feffb525642f5079fd is tainted
-------- store(e5601afc133b8da12149ee260deb6650) -----
sid=e5601afc133b8da12149ee260deb6650 is not tainted
path=/srv/twiki/working/tmp/cgisess_e5601afc133b8da12149ee260deb6650 is tainted
Insecure dependency in sysopen while running with -T switch at /srv/twiki/lib/CGI/Session/Driver/file.pm line 114.
-------- store(e5601afc133b8da12149ee260deb6650) -----
sid=e5601afc133b8da12149ee260deb6650 is not tainted
path=/srv/twiki/working/tmp/cgisess_e5601afc133b8da12149ee260deb6650 is not tainted

The first call to store shows pathologic behaviour: an untainted session ID is converted to a tainted path. The conversion is done with File::Spec->catdir, apparently an XS module, outside my reach of knowkedge. The security fix causing all this was in Cwd.xs which is more a sequence of macros than actual C code. I am not familiar with these macros and have no idea what's going on in SvTAINT.

Some more details and observations:

• The procedure here is that the browser provides a (tainted) session ID b9... which TWiki rejects for whatever non-fatal reasons. TWiki then creates a fresh session with a different, untainted ID e5..., but on flushing this session to disk (first call to store) the insecure dependency occurs.
• The second call to store happens during cleanup in the DESTROY routine of CGI::Session. Surprisingly, now the same path is no longer tainted and the session is successfully written to disk.
• Whenever I try to just print the session ID from the _file routine (I've tried several locations), the error mysteriously disappears, and the path is untainted.

The inconsistent behaviour between the two calls to store, and the random behaviour when "harmless" statements are added to the code give me a hunch that the culprit is somewhere in the C code ("missing initialisation" or "use after free" come into my mind). This might also explain why I failed to reproduce the bug outside of TWiki.

-- Harald Jörg - 2016-02-07

Thank you for looking into this Harald.

This is tracked on our end at TWikibug:Item7721.

-- Peter Thoeny - 2016-02-13

Hi guys,

Just wanted to add my two pence.

I ma having exactly same problem on Debian 8, with perl 5.20.2-3+deb8u3 which I just updated to 5.20.2-3+deb8u4 but I am not really convinced it will help. But, the reason I am writing is that I have observed this error only after I have restricted "Set DENYWEBVIEW = TWikiGuest". I just installed this twiki installation recently and it was open for all till this change was made. I didn't observe this error till I made the change so maybe it will help you narrow down some scenarios.

-- TWiki Guest - 2016-06-08

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.