[support] Very Strange Security Breach
Shai Gluskin
prothero
--
[ Drupal support list | http://lists.drupal.org/ ]
Bill Fitzgerald
* What roles have "administer comments" rights?
* Are there any VBO-based comments administration views on the site?
* How secure is the site's database? Is root access still available? If so, is the password secure?
* Is phpMyAdmin installed on the site? That can be a weak spot.
* Do the Apache logs from the time of the breach show anything odd/curious ?
Also, at the risk of stating the obvious, I'd strongly recommend creating a superuser role and retiring your UID1 account for everything but upgrades/updates.
Cheers,
Bill
Greg Knaddison
> * What roles have "administer comments" rights?
> * Are there any VBO-based comments administration views on the site?
> * How secure is the site's database? Is root access still available? If so,
> is the password secure?
> * Is phpMyAdmin installed on the site? That can be a weak spot.
> * Do the Apache logs from the time of the breach show anything odd/curious ?
All sage advice and good questions.
> Also, at the risk of stating the obvious, I'd strongly recommend creating a
> superuser role and retiring your UID1 account for everything but
> upgrades/updates.
I think it's not so obvious and not really useful. If the "superuser
role" has the permission to "administer users" or "administer
permissions" then any user in that role has the exact same permissions
as UID1. The only difference is, as you state running update.php (in
D7 that distinction is gone - anyone with the right permission can run
update.php).
The idea that "uid1 = unsafe" is a security myth that needs to die.
There are other more likely avenues of attack such as incorrectly
configured input formats.
For those interested, you can test your input formats against security
best practices by trying out http://drupal.org/project/security_review
Cheers,
Greg
Rolf Kutz
>For those interested, you can test your input formats against security
>best practices by trying out http://drupal.org/project/security_review
Very nice module!
regards
Rolf
--
Imagine a world devoid of hypothetical situations...
Ryan LeTulle
For those interested, you can test your input formats against security
best practices by trying out http://drupal.org/project/security_review
bayousoft.com
twitter.com/bayousoft
Steve Power
--
--
Steve Power
Principal Consultant
Mobile: +44 (0) 7747 027 243
Skype: steev_initsix
www.initsix.co.uk :: Initsix Heavy Engineering Limited
--
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Initsix Heavy Engineering Limited.
If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone.
Please contact the sender if you believe you have received this email in error.
Initsix Heavy Engineering Limited
Registered in the UK: 5036938
Registered Address: 243 Kettering Road, Northampton, NN2 7DU, England.
Marc Poris
> There are other more likely avenues of attack such as incorrectly
> configured input formats.
There are plenty of contrib modules that check for uid == 1 and dole out additional privileges, so while Drupal core may only check for uid == 1 in user_access() and user_register_submit(), your site is only as secure as your weakest contrib module.
Here are three examples of (uid == 1) checks from a site I'm looking at now (and I'm sure you can find a module or two that I've contributed where I've done the same thing):
>From workflow.module:
function workflow_field_choices($node) {
...
if ($user->uid == 1) {
// Superuser is special.
$roles = 'ALL';
}
...
}
>From flag module's flag.inc:
function user_access($account = NULL) {
if (!isset($account)) {
$account = $GLOBALS['user'];
}
$matched_roles = array_intersect($this->roles, array_keys($account->roles));
return !empty($matched_roles) || empty($this->roles) || $account->uid == 1;
}
>From drupad.module:
function drupad_authorize() {
global $user;
if (!strstr($_SERVER['HTTP_USER_AGENT'], 'Drupad')) {
return FALSE;
}
if ($user->uid == 0) {
return FALSE;
}
if (user_access('use Drupad application')) {
return TRUE;
}
if ($user->uid == 1) {
return TRUE;
}
if (arg(0) == 'drupad') {
drupad_unauthorized();
}
return FALSE;
}
- Marc
Bill Fitzgerald
> I think it's not so obvious and not really useful. If the "superuser
> role" has the permission to "administer users" or "administer
> permissions" then any user in that role has the exact same permissions
> as UID1. The only difference is, as you state running update.php (in
> D7 that distinction is gone - anyone with the right permission can run
> update.php).
We always try to create targeted admin roles for specific tasks, so you
can split rights like administer nodes (for high-level editors) from
administer views/blocks/content types (for site admins) from administer
users. This way, different types of admin users can be assembled from
these various roles, and matched to professional responsibilities and
individual skill sets.
> The idea that "uid1 = unsafe" is a security myth that needs to die.
uid1 will be as safe or as unsafe as the person using it - and by
"person" I generally mean the actual human hitting the keyboard, the
computer that keyboard is attached to, and the network they are on. I'd
much rather incrementally decrease risk through targeted roles -
although, as you say, if a user gets "administer users" rights then all
bets are off.
Another use we have found for discouraging the use of uid1 is less
technical and more training-related - it's a way to start the discussion
with less technical users about security concerns.
> There are other more likely avenues of attack such as incorrectly
> configured input formats.
Absolutely.
> For those interested, you can test your input formats against security
> best practices by trying outhttp://drupal.org/project/security_review
That is a sweet module that I didn't know existed. Thanks for sharing that.
Cheers,
Bill
Greg Knaddison
>> The idea that "uid1 = unsafe" is a security myth that needs to die.
>> There are other more likely avenues of attack such as incorrectly
>> configured input formats.
>
> There are plenty of contrib modules that check for uid == 1 and dole out additional privileges, so while Drupal core may only check for uid == 1 in user_access() and user_register_submit(), your site is only as secure as your weakest contrib module.
>
Sure, and I've even used that fact to set the 'access arguments' on a
menu item to be <? array("something that doesn't exist"), ?> so that
only UID 1 can access that callback, however:
1. In a quick review it seems all the examples you showed could also
be accessed with the right roles/permissions and my argument was that
someone with "administer users" and "administer permissions" can
already grant whatever things they need to get access to that feature.
2. Someone with those permissions can easily escalate themselves to
become uid1 by enabling some module that executes PHP and then
creating a snippet like <?php global $user; $user = user_load(1); ?>
Aside from Bill's followup about splitting administration roles
(totally agree there, great point) but my claim is:
>From a security perspective, there is no difference between UID 1 and
someone who has a role "administer users" and/or "administer
permissions."
Cheers,
Greg
prothero
prothero
Jarry
> Folks:
> Not only do I get this error code, but several modules on my site have
> stopped working. The only thing I did was install the security module
> and mess with permissions on the /tmp folder. Sheesh! Very frustrating.
> Bill
I do not think you could mess your site just with changing /tmp
permissions and reverting it back. I just tried it in one of my
vservers (did backup before, of course), and site is working.
You must have changed something else too...
btw, my /tmp is "drwxrwxrwt 4 root root". Check yours!
Jarry
>> --message:
>> user warning: Can't create/write to file '/tmp/#sql_3cb2_0.MYI'
>> (Errcode: 13) query: SELECT DISTINCT b.* FROM blocks b LEFT JOIN
>> blocks_roles r ON b.module = r.module AND b.delta = r.delta WHERE
>> b.theme = 'solarsentinel' AND b.status = 1 AND (r.rid IN (2) OR r.rid
>> IS NULL) ORDER BY b.region, b.weight, b.module in
>> /home/wap/public_html/modules/block/block.module on line 433
>> --end message.
>>
>> I understand that the error is in permissions for the /tmp directory.
>> I got this error when I changed permissions, but now when I do chmod
>> -R 0777 (as a test), I still get the error. This should set the
>> permissions to "Everybody can do anything". What's up? I'm not a unix
>> expert, but not a novice either and this confuses me. Does the "#"
>> char at the start of the file name mean the file is invisible, ??
--
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.
Steve Power
prothero
Greg Knaddison
> change it. The security module may have done something.
The security module only reports information, it doesn't change or try
to fix anything.
Cheers,
Greg
--
Greg Knaddison | 720-310-5623 | http://growingventuresolutions.com
Mastering Drupal | http://www.masteringdrupal.com