[drupal-devel] [bug] Remove drupal module from core
drupal-devel at drupal.org
Tue Sep 20 10:30:50 UTC 2005
Issue status update for
Post a follow up:
Category: bug reports
Assigned to: Anonymous
Reported by: robertDouglass
Updated by: robertDouglass
Status: patch (code needs review)
The more I think about it, the more I conclude that Drupal.org should
also drop dist. auth. support, or find better security solutions.
Here's an example scenerio to provoke discussion. Gerhard always logs
on to drupal.org as killes at www.drop.org. AFAIK, these sites are now on
two separate servers, and therefore probably have different security
profiles. Now, just as conjecture, let us suppose that the server on
which drop.org is run gets compromised and someone is able to steal
Gerhard's password. They now have a big cat in the bag: drupal.org.
They'd be able to become site/cvs admins for drupal.org, something
which we probably don't want. In the end, if we have no way to say
which sites can be trusted to do authentication, it is a bad idea
allowing anyone to use this in conjunction with drupal.org.
What if Jeremy's server were compromised (or perhaps Jeremy is just
really evil and nobody knows ;-))? In either case, someone would be
able to log into drupal.org with the UnConeD username - not a really
PLEASE TELL ME I'M WRONG! Or remove the module.
Tue, 20 Sep 2005 07:14:52 +0000 : robertDouglass
Attachment: http://drupal.org/files/issues/drupalmod.patch (11.15 KB)
The drupal module does two things; it implements distributed
authentication and it lets you run a "directory server". These sound
great in the features list, but the implementation of both features is
weak and poses the real risk of exposing Drupal users to identity
Here is an excerpt from my writings on the module:
Drupal distributed authentication is a way to save site users the extra
steps of creating redundant accounts on multiple sites.
(snip... we know how it works :-)
There are some limitations and concerns about the current
implementation of distributed authentication. It would be relatively
easy for someone to alter the code of their site to save a record of
the passwords of users who log in. This is true of any website you
visit, Drupal or otherwise. As long as the username and password only
buys access to that very site, there is little incentive to do this.
If, however, it would allow the malicious person to log into other
sites as well, in this case any Drupal site that has the drupal module
enabled, the incentive is greater and the potential loss or damage
greater. The attacker would be able to masquerade on those sites using
your user identity and execute actions on your behalf.
CAUTION Drupal's distributed authentication is inherently insecure. If
you do not know that you can trust the owner(s) of a particular site,
never use your distributed authentication (Drupal id) to log into it.
Running a directory server
The drupal module offers a simple service by which other Drupal sites
can announce their existence, or "ping" a central server on a regular
basis. While there are many possible applications of such a service,
the most prominent use is the now defunct Drupal sites page on
Drupal.org which was simply a long list of sites that run Drupal.
In practice, any site that has the drupal module enabled can function
as a directory server. When another site pings the site, the remote
site's name, slogan and mission are added to the list of sites. A
useful application of a directory server might be on a college or
university where individual labs or departments are setting up many
different Drupal sites. Each one could ping a central server at the
university to compile a list of all the various sites as they spring
In its current state, the service lacks some basic features. There is
no way for the administrator to block a certain site from pinging and
being added to the list. Nor is there a way to limit the incoming pings
to a certain set of domains or IP addresses. The potential to make a
truly useful directory server service exists, though, and anyone is
encouraged to participate in discussions and development at Drupal.org.
I've come to the conclusion that a module that is this weak should be
offered as a contributed module, not as core. If it weren't in core, I
wouldn't bother writing about it because it is too weak, and poses a
real security threat. My recommendation is that it be placed in the
contributions repository as an example of how distributed auth. for
those enterprising individuals who might want to improve upon it.
Tue, 20 Sep 2005 10:19:32 +0000 : robertDouglass
tasks don't send mail? Setting to bug report.
More information about the drupal-devel