With Debian Jessie, and therefore probably with more distributions in the future, TWiki occasionally fails with =
Insecure dependency in sysopen while running with -T switch at /usr/share/perl5/CGI/Session/Driver/file.pm line 107.
The issue came up in TWiki:Support.SID-02145
: A security fix in Debian, pushed their
package from 5.20.2-3+deb8u1 to 5.20.2-3+deb8u2: https://www.debian.org/security/2016/dsa-3441.en.html
. As a consequence, some use cases for CPAN:CGI::Session
broke with an insecure dependency. As of today, there's a new version of CGI::Session in Debian, but the error still occurs in TWiki. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810799
for the history.
This needs work by twikizens for narrowing down the error: maybe it's in TWiki, maybe in CGI::Session, or even elsewhere.
Unfortunately, for whatever reason, this now pops up with various Perl versions since 5.10.
Observations and tracing seem to indicate that the root cause is not in TWiki's source code itself, but in some library / C code on which TWiki depends.
- The bug is not easily reproducible, and I have not managed to reproduce it outside of TWiki.
- We had several reports that deleting the TWiki session cookie is a workaround to get over the problem.
- This supports my assumption about the code path where the error is triggered: It happens whenever TWiki rejects a session cookie and creates a new one. This happens in some situations, e.g. when the client IP address changes, and is normally harmless, but now these sessions are somehow "tainted". Deleting the cookie enforces a fresh session and gets rid of the bogus session data. "Somehow" the rejected session lingers around.
When narrowing down the error, I added
statements in various places for debugging. Strange enough,
in some places make the error go away, even if I just print a constant string. This might be a clue that the bug is in the C innards of Perl or some of its modules itself, but is too far from a proof. I hesitate to commit such a
statement as a "fix" for the problem.
My not-yet-automated procedure to reproduce the bug is as follows:
- Create a TWiki session by just viewing a topic with a browser.
- Manually delete the session file on the server (I doubt that this happens in any real world situation, but it makes TWiki follow the same code paths).
- View another topic, or just "reload"
- Boom. But not always.
Another not-too-convincing workaround is to get rid of the
switch in the TWiki
files. If there are no taint checks, then there is no insecure dependency. I don't like that because it gives away a security assertion for nothing, though we know that the cause of this problem is not
I've been not very active with this lately, but here's my current best guess for a workaround: Downgrade
, available from CPAN in the
distribution, from 3.62 to 3.60.
Good news - or bad news, depending on how to you look at it: With today's "stable" Debian system (Debian 9 AKA Stretch) I fail to reproduce the error - no taint failures however hard I try. The exactly same TWiki code and procedure (as described in my comment dated 2016-08-04) gives a taint failure on Debian 8, but works fine as it should on Debian 9. Confirmed with the system versions of
as well as with those which come with TWiki.
As far as I am concerned, I'm likely to give up on this error. It is unlikely that TWiki code can do something about it (short of abandoning
), and the taint failure did never indicate an actual security vulnerability.
I'm closing this now: All clues indicate that this problem only occurs with TWiki and Perl 5.20, which unfortunately came with Debian Jessie and other popular Linux distributions. But as of now, the distributions ship with newer versions of Perl, and I failed to reproduce the bug with Perl 5.22, Perl 5.24, and Perl 5.26.
in all the situations where the bug appears is to close all browser windows (or, more technically, to delete all cookies from the TWiki server).