SID-02175: Insecure dependency in sysopen while running with -T switch
|| TWiki version:
|| Perl version:
|| Server OS:
|| Ubuntu Linux 14.04.2 LTS
|| Last update:
|| 1 hour ago
A user reported this when they clicked an ordinary link to a TWiki page.
It happened only one time. They tried it again and it worked the second time.
Any clue what I might look for? Or just wait and see if it happens again?
-- Larry Bristol - 2016-03-16
Discussion and Answer
That's interesting... and bad news. The same symptom has been observed recently with "current" Perl versions, see SID-02145, and the corresponding bug item Bugs:Item7721
. In that case, the error is caused by an update in Debian's Perl 5.20 package; but as far as I recall this patch shouldn't be backported to older versions of Perl.
The error is sort of harmless, there's no security vulnability. It happens "sometimes" when TWiki tries to write user session data into the cookie file. Nevertheless, the error is annoying and should be tracked down, but so far we failed to reproduce it in a simple test case
You can help us to find out whether you have observed the same issue, or an unrelated problem leading to the same error message, by providing some information:
- Was clicking on an ordinary link to a TWiki page the first interaction of the user with TWiki in this session, or came it out of the blue after viewing other TWiki pages? I'd guess it is the latter, because so far the error hasn't been observed when the cookie file is created, but only on updates.
- What's your exact version of Perl? Say
dpkg-query --show perl to your computer to find out.
- What is your version of
dpkg-query --show libcgi-session-perl to your computer to find out.
- What is the exact location where the error occurred (should be available in Apache's error log)?
CGI/Session/Driver/file.pm is the usual suspect, but it contains several calls to
-- Harald Jörg - 2016-03-16
It happened again...
- Asked user to answer your first question; will report when they reply.
- perl 5.18.2-2ubuntu1.1
- dpkg-query: no packages found matching libcgi-session-perl
- Last 3 log records before error reported to me:
- [Fri Apr 01 13:42:41.699769 2016] [cgi:error] [pid 6269] [client 172.28.182.54:55323] AH01215: [Fri Apr 1 13:42:41 2016] view: Insecure dependency in sysopen while running with -T switch at /usr/local/share/perl/5.18.2/CGI/Session/Driver/file.pm line 107.
- [Fri Apr 01 13:42:50.488769 2016] [cgi:error] [pid 5212] [client 172.28.182.54:55322] AH01215: [Fri Apr 1 13:42:50 2016] view: Insecure dependency in sysopen while running with -T switch at /usr/local/share/perl/5.18.2/CGI/Session/Driver/file.pm line 107.
- [Fri Apr 01 13:43:15.408318 2016] [cgi:error] [pid 22181] [client 172.28.182.54:55324] AH01215: [Fri Apr 1 13:43:15 2016] view: Insecure dependency in sysopen while running with -T switch at /usr/local/share/perl/5.18.2/CGI/Session/Driver/file.pm line 107.
-- Larry Bristol - 2016-04-01
I doubt this will help, but this is what she replied: It appears to happen after browser was used after a VPN reconnect.
(The TWiki site is inside a firewall, and can only be accessed remotely when connected using a VPN. She seems to be saying that the VPN connection was disrupted temporarily, and the error occurred after it reconnected and she tried to continue her activity. The problem with this information from my point of view is the log seems to imply the error occurred three times within a 34 second interval. Hey, but what do I know?!?)
-- Larry Bristol - 2016-04-01
Thanks for reporting back! We need this sort of data to narrow down the problem, which is still a mystery and perhaps has its root cause down to the innards of Perl core modules.
- Your perl version is bad news, because I thought only Debian's perl 5.20.2-3+deb8u2 was affected. It is also good news, because I have the very same perl version on my development machine, where I can experiment freely.
- You didn't find
dpkg-query. That can have two reasons: 1) You are using the fallback version shipped with TWiki (in
lib/CPAN/lib/CGI) or 2) you installed it using
cpan instead if using Ubuntu's software distribution. The log records tell us that it is case 2), since
cpan installs to
/usr/local/share/perl. May I ask you to tell us which version that is?
perl -MCGI::Session -e 'print "$CGI::Session::VERSION\n"' should do the trick.
- The story about the VPN reconnection perfectly answers my first question, because it fits the model I currently have for the problem: The error occurs after TWiki rejects a session cookie (in SID-02145 I wrote "for whatever reason") and creates a new one. A new VPN connection may cause TWiki to reject the session cookie because e,g. the client IP address has changed.
So far I never succeeded in reproducing the problem on my system, but this kinda obvious (I don't need VPN to talk to localhost). With your report, it seems worthwile to trick TWiki into rejecting cookies for the tests. Will take a few days, though, because right now I've limited time to hack on TWiki.
-- Harald Jörg - 2016-04-05
Hello, I just changed from chrome to firefox and resolved my problem!
-- Fernando Kondo - 2016-04-14
Sorry, Harald. I missed your earlier request...
~$ perl -MCGI::Session -e 'print "$CGI::Session::VERSION\n"'
I do not know what browser my user is running. It is probably Internet Exploder
. I will ask and post the answer.
-- Larry Bristol - 2016-04-14
Possibly related case: SID-02192
-- Peter Thoeny - 2016-04-23
I seem to have neglected to post the answer. The answer is YES, she uses Exploder...
-- Larry Bristol - 2016-04-25
I have a cookie-based, corporate SSO integrated with our TWiki installation. The SSO cookies expire daily. I get this error after the cookie has expired until I clear the cookies from the browser. Then TWiki behaves normally again until the new cookie expires.
TWiki: 6.0.2 (build 29687)
Session Version: I got an error "Can't locate CGI/Session.pm" with your command, but if I added "-I/var/www/twiki/lib -I/var/www/twiki/lib/CPAN/lib" to the command I get version 4.48.
-- Joshua Tharp - 2016-04-26
I'm also experiencing this error and am wondering if there are any details that I can provide that could help troubleshoot.
In general, it occurs when I'm using TWiki and do not close my browser. After a longer duration (overnight), trying to resume using TWiki in the same browser results in the error. Closing the browser solves the problem. My typical browser is Chrome but I use Firefox as well. If there's anything I can do to help please let me know.
Next time I see the error I will try to provide Perl Version,
and exact location where the error occurred.
-- Jani Hamalainen - 2016-04-26
Likely related question: SID-02201
-- Peter Thoeny - 2016-05-18
My user encountered the problem again. I asked her to close the browser window and restart it. That did clear the problem for her.
-- Larry Bristol - 2016-06-24
I am experiencing this same weird problem - TWiki 6.0.2 - Perl v.5.10.1 - Centos 6.8.
In general, when I clean the cache and cookies the problem disappears temporarily.
Has anyone solved this problem?
-- Carlos Adean - 2016-08-03
Unfortunately no fix yet. Tracked at TWikibug:Item7721
-- Peter Thoeny - 2016-08-04
-- John Huber - 2017-01-06
I have some details which I hope are helpful. I have been working for sometime on migrating an older TWiki installation and thought I had it knocked - then on my final version ran into this bug. The most recent installation is the one that messed up, but both use 6.0.2 TWiki. They are both CentOS
-derived, v6.8 with updated kernels (which change a few times per month). The real difference between them is in CPAN module versions and the NEWER system is the buggy one. I checked the required modules on both and here are the differences:
Module Working Non-working
Algorithm::Diff 1.1902 1.1903
Cwd 3.3 3.62
Data::Dumper 2.124 2.161
Encode 2.35 2.88
Error 0.17015 0.17024
File::Spec 3.3 3.62
File::Temp 0.22 0.2304
HTML::Parser 3.64 3.72
HTML::Entities 3.64 3.69
Net::SMTP 2.31 3.10
Text::Diff 1.37 1.44
Time::Local 1.1901 1.25
It is possible the older (working) version just hasn't been tested enough, but we'll try now. I'm on the spot here, this has to be done by March.
-- John Huber - 2017-01-06
Sorry, I left out the important (I think) module. I now have three test wikis up. They have different CentOS
-derived linuxes which are functionally identical, but in one of them I did the Perl module install using the built-in software installer, while using the "cpan" command on the other two. Also, it's clear the blowup happens in CGI::Session module (looking at the SSL error logger.) The system which ended up with v4.35 of CGI::Session has not (as yet, we're in testing) exhibited the error. The others (v4.48) both have, although one seems more prone to it.
Here's my (two-part) question: Is there anyone who gets the error while running v4.35 or anyone who doesn't while using 4.48?
-- John Huber - 2017-01-09
Thanks for the data point! Unfortunately it doesn't completely resolve the mystery - I get the error with CGI::Session 4.10. I failed to install v4.35 - CPAN has a gap between v4.10 and 4.41.
So far, I found one recipe to reliably trigger the error in my systems:
- As unauthenticated user, go to your Sandbox web, and create a new topic.
- TWiki will ask for username and password, which you provide.
- Do not save the topic right now. Instead, do the following:
- Open a root shell and delete
twiki_root/working/tmp/cgisess* (if you have productive users at the same time, you may want to try to figure ot which of the sessions belongs to your recent login)
- Now go back to the browser window and save
- Ka-Boom with insecure dependency (line 99 with CGI::Session 4.10, line 107 with CGI::Session 4.48).
Of course, in productive environments, nobody goes around and deletes Session files. But there are situations where it can happen, and many of the observations are from such situations where TWiki itself drops the session file: Change in IP address (e,g, when your DHCP lease from your provider runs out), session timeout, and more. In all cases, things are back to normal when the client
(browser) drops the session cookie.
My best guess for a workaround
right now is to downgrade Cwd.
With v3.60 of Cwd, available from CPAN in the PathTools
distribution, I could not reproduce the error. The change in Cwd was a security fix and made it into the Perl core (Cwd is a core module) and pretty well marks the point in time when the error started to show up. However, without any test case to reproduce the error outside of TWiki, it is close to impossible to track it down.
-- Harald Jörg - 2017-01-09
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.