[UNIX] Metadot Privileges Escalation

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -



Metadot Privileges Escalation
------------------------------------------------------------------------


SUMMARY

" <http://www.metadot.com/> Metadot is the leading open source portal
software (GPL) used to create websites, intranets, extranets, project and
community portals anyone can use."

Authenticated users can add themselves to any group on Metaspot regardless
of their existing permissions allowing users to gain site manager
permissions.

DETAILS

Vulnerable Systems:
* Metadot version 6.4.4 and prior

Immune Systems:
* Metadot version 6.4.5

An authenticated user can access and manage groups which they are not
owners or members of. This includes the Metadot default site manager
(SITE_MGR) group.
As a result, users can manage any group and add or remove accounts from
that group.

Hence, to gain administrative privileges on a Metadot portal, an attacker
can simply add himself into SITE_MGR group. Site managers are allowed to
perform many administrative tasks and have the ability to modify site
content. This exploit to gain administrative privileges can be carried
out as long as the attacker knows the group identification number of
SITE_MGR group as well as the correct fields
to alter in the URL.

The vulnerability is caused by stale global variables ($IS_OWNER,
$IS_MANAGER, $IS_ADMIN) which have not been reset appropriately in
Metadot's "Group.pm" Perl module. In the case that a previous operation
has set the parameters to 1, a subsequent call does not reset it. This
vulnerability is seen in the set_group_permission_variables() function
call.

Code snippet:
Group.pm:
sub set_group_permission_variables {
my $self = shift;
my $grp_id = $self->{grp_id};
my $owner_uid = $USER->{uid};

if (DBAccess->sqlSelect ("group_name", "grp", "grp_id = $grp_id and
userid = '$owner_uid'")) {
$IS_OWNER = 1;
} elsif ( $ACCESS_BROKER->is_allowed_to_do('manage_registrations') ) {
$IS_ADMIN = 1;
} elsif (DBAccess->sqlSelect ("is_manager", "grpmembers", "grp_id -
$grp_id and userid = '$owner_uid' and is_manager = 1")) {
$IS_MANAGER = 1;
}
}

It can be seen from the codes that the variables $IS_OWNER, $IS_ADMIN, and
$IS_MANAGER are only set to '1' if privileges are correct. In the event
that the privileges are incorrect, the values are not set and the global
variables retain its previous values as set from other operations. Thus,
this vulnerability can be exploited by performing operations that first
set this variable to '1', then access the
SITE_MGR group.

Disclosure Timeline:
Discovery: 29 November 2005
Vendor notified: 29 November 2005
Patch released: 18 December 2005
Public disclosure: 20 December 2005


ADDITIONAL INFORMATION

The information has been provided by <mailto:gerry.chng@xxxxxxxxx> Gerry
Chng.



========================================


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx


====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages