Folks: Thanks for the link to the security test. I installed it, BUT, when I was messing with my permissions, so fix various file permissions, I did something very simple that caused an error message all through the site:

--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, ??

Regards, Bill

William A. Prothero http://earthednet.org/

On Dec 16, 2010, at 11:00 PM, prothero wrote:

I had a similar hack happen. I had about 7 comments on a blog, in Russian, from an anonymous user. I have permission set so only registered users can make comments. Hmmm... I deleted them, but wonder what I should do to stop this in the future. I did set capcha so that comments require it. Drupal 6.19. Regards, Bill

William A. Prothero http://earthednet.org/

On Dec 16, 2010, at 9:32 PM, Shai Gluskin wrote:

...

Hi gang,

The author and URL of an anonymous comment was changed about three months after the comment was originally posted. The change happened last week. The new name was in Chinese and the URL is to a Chinese web site. The content of the comment was not changed.

I've never had anything like that happen before. After I discovered this I changed user/1 pw (that is the only account on the site with admin privileges).

There is no other evidence of other damage at the site that I found in the wake of this discovery.

(Site was using 6.19 at the time of the breach).

I'm stumped. Ideas anyone?

Shai

[ Drupal support list | http://lists.drupal.org/ ]

-- [ Drupal support list | http://lists.drupal.org/ ]

On 17. 12. 2010 20:04, prothero wrote:

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, ??

On Fri, Dec 17, 2010 at 1:10 PM, prothero prothero@geol.ucsb.edu wrote:

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

you might be running in a mode that doesn't serve 777 files, try changing them to only allow the webserver to read, write execute, and anonymous to only read. hope that helps.

On Fri, Dec 17, 2010 at 7:04 PM, prothero prothero@geol.ucsb.edu wrote:

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

William A. Prothero

http://earthednet.org/

On Dec 17, 2010, at 10:56 AM, prothero wrote:

Folks: Thanks for the link to the security test. I installed it, BUT, when I was messing with my permissions, so fix various file permissions, I did something very simple that caused an error message all through the site:

--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, ??

Regards, Bill

William A. Prothero http://earthednet.org/

On Dec 16, 2010, at 11:00 PM, prothero wrote:

I had a similar hack happen. I had about 7 comments on a blog, in Russian, from an anonymous user. I have permission set so only registered users can make comments. Hmmm... I deleted them, but wonder what I should do to stop this in the future. I did set capcha so that comments require it. Drupal 6.19. Regards, Bill

William A. Prothero http://earthednet.org/

On Dec 16, 2010, at 9:32 PM, Shai Gluskin wrote:

Hi gang,

The author and URL of an anonymous comment was changed about three months after the comment was originally posted. The change happened last week. The new name was in Chinese and the URL is to a Chinese web site. The content of the comment was not changed.

I've never had anything like that happen before. After I discovered this I changed user/1 pw (that is the only account on the site with admin privileges).

There is no other evidence of other damage at the site that I found in the wake of this discovery.

(Site was using 6.19 at the time of the breach).

I'm stumped. Ideas anyone?

Shai

[ Drupal support list | http://lists.drupal.org/ ]

-- [ Drupal support list | http://lists.drupal.org/ ]

-- [ Drupal support list | http://lists.drupal.org/ ]

-- [ Drupal support list | http://lists.drupal.org/ ]

On Fri, Dec 17, 2010 at 12:20 AM, Bill Fitzgerald bill@funnymonkey.com wrote:

• 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

For those interested, you can test your input formats against security

best practices by trying out http://drupal.org/project/security_review

nice, thanks

:ryan

bayousoft.com http://www.bayousoft.com twitter.com/bayousoft http://www.twitter.com/bayousoft

On Fri, Dec 17, 2010 at 10:10 AM, Greg Knaddison < Greg@growingventuresolutions.com> wrote:

On Fri, Dec 17, 2010 at 12:20 AM, Bill Fitzgerald bill@funnymonkey.com wrote:

...

• 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 -- [ Drupal support list | http://lists.drupal.org/ ]

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.

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

On 12/17/10 8:10 AM, Greg Knaddison wrote:

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