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

-- _______________________________________________________________ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.

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/ ]

-- -- -- Steve Power Principal Consultant Mobile: +44 (0) 7747 027 243 Fax: +44 (0)160 421 2871 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.

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