Security alert: User could gain view access rights of another user
This is a security flaw of TWiki sites with session based tracking of users. A malicious user can gain view access rights of another user, thus being able to look at view access restricted content. Edit access is not compromized. The bug happens if a user failed to authenticate properly.
Affected TWiki Sites
This alert applies only to TWiki sites:
- where the
edit
script is authenticated (but not the view
script)
- and where TWikiAccessControl is used for view access restrictions (does not apply to edit access),
- and where session based tracking of users is done with
Background on Session Tracking
Sites that use a Plugin like
SessionPlugin or
SmartSessionPlugin identify users with a login and keep track of the user with cookies.
Sites where the
$doRememberRemoteUser
flag is set in TWiki.cfg remember the remote user by IP address. The user's IP address gets associated with the login name when editing a topic. This is used to identify users in the non-authenticated view script, e.g. even if the REMOTE_USER environment variable is not set.
Fix for Sites Using SessionPlugin or SmartSessionPlugin
Fix for TWiki production releases: Add the red lines to the
initialize
function in
twiki/lib/TWiki/Plugins.pm
# =========================
sub initialize
{
my( $theTopicName, $theWebName, $theUserName ) = @_;
# initialize variables, needed when TWiki::initialize called more then once
%registeredHandlers = ();
@activePluginTopics = ();
@activePluginWebs = ();
if( $ENV{'REDIRECT_STATUS'} && $ENV{'REDIRECT_STATUS'} eq '401' ) {
# bail out if authentication failed
return;
}
# Get INSTALLEDPLUGINS and DISABLEDPLUGINS variables
my $plugin = &TWiki::Prefs::getPreferencesValue( "INSTALLEDPLUGINS" ) || "";
$plugin =~ s/[\n\t\s\r]+/ /go;
my @instPlugins = grep { /^.+Plugin$/ } split( /,?\s+/ , $plugin );
$plugin = &TWiki::Prefs::getPreferencesValue( "DISABLEDPLUGINS" ) || "";
$plugin =~ s/[\n\t\s\r]+/ /go;
my @disabledPlugins = map{ s/^.*\.(.*)$/$1/o; $_ }
grep { /^.+Plugin$/ } split( /,?\s+/ , $plugin );
Fix for recent
TWikiAlphaReleases: Add the red lines (excluding leading plus signs) to the
initialize1
function in
twiki/lib/TWiki/Plugins.pm
Index: Plugins.pm
===================================================================
RCS file: /cvsroot/twiki/twiki/lib/TWiki/Plugins.pm,v
retrieving revision 1.26
diff -c -r1.26 Plugins.pm
*** Plugins.pm 23 Sep 2003 19:49:19 -0000 1.26
--- Plugins.pm 14 Dec 2003 09:16:12 -0000
***************
*** 210,215 ****
--- 210,220 ----
@activePluginWebs = ();
@instPlugins = ();
+ if( $ENV{'REDIRECT_STATUS'} && $ENV{'REDIRECT_STATUS'} eq '401' ) {
+ # bail out if authentication failed
+ return "";
+ }
+
# Get INSTALLEDPLUGINS and DISABLEDPLUGINS variables
my $plugin = &TWiki::Prefs::getPreferencesValue( "INSTALLEDPLUGINS" ) || "";
$plugin =~ s/[\n\t\s\r]+/ /go;
Note: This fix has been tested with Apache on Linux. The fix does not work if a web server does not set the
REDIRECT_STATUS
environments variable.
Fix for Sites Using the $doRememberRemoteUser= Flag
Fix for any TWiki release: Add the red lines (excluding leading plus signs) to the
initializeRemoteUser
function in
twiki/lib/TWiki.pm
Index: TWiki.pm
===================================================================
RCS file: /cvsroot/twiki/twiki/lib/TWiki.pm,v
retrieving revision 1.252
diff -c -r1.252 TWiki.pm
*** TWiki.pm 14 Dec 2003 07:25:57 -0000 1.252
--- TWiki.pm 14 Dec 2003 08:54:39 -0000
***************
*** 813,818 ****
--- 813,823 ----
$remoteUser = $1; # untaint variable
my $remoteAddr = $ENV{'REMOTE_ADDR'} || "";
+
+ if( $ENV{'REDIRECT_STATUS'} && $ENV{'REDIRECT_STATUS'} eq '401' ) {
+ # bail out if authentication failed
+ $remoteAddr = "";
+ }
if( ( ! $doRememberRemoteUser ) || ( ! $remoteAddr ) ) {
# do not remember IP address
Note: This fix has been tested with Apache on Linux. The fix does not work if a web server does not set the
REDIRECT_STATUS
environments variable.
This issue has been reported by
MS via e-mail, including the suggestion to use of the REDIRECT_STATUS variable. Thanks for reporting the security issue by e-mail as suggested!
The fix is in
TWikiAlphaRelease,
TWikiBetaRelease and at TWiki.org.
--
PeterThoeny - 18 Dec 2003
Couple of comments, I may have reported it, the kudos for the fix should go to:
KimCovil - the fix Kim provided was for the
smart session plugin (I just noticed that it affected more situations). Updated
AssignedTo since this seems to be the approach taken on TWiki.org at present for where feature code comes from!
Also I mentioned a secondary note - that if controlled, this behavious provides for
registration free preferences in a similar to many other wikis. (
UseMod,
MoinMoin,
MeatBall)
-- MS - 19 Dec 2003