PHP security from user server users

Anyone know to what extent DH servers are protected against the below?

Thanks.

Attacks from you neighbours are really where PHP is weakest. A neighbour
is a user who also has an account on the same machine as you - and they
also have the ability to run PHP scripts. On linux/apache .htaccess will
not protect files from neighbours, worse you have to set the files to be
readable by 'nobody'(ie the whole world) because otherwise apache can't
open them. So if your neighbours want to they can look at all you scripts
and any files read/written by your scripts.

Is there any solution for this? I'm worried about storing passwords in .php files, and I'm not sure how to guarantee they are secure.

This is not a relevant issue when running the default PHP as CGI on Dreamhost, as DH's use of suexec causes your scripts to be run as your user, not apaches's.

Thus, it's a simple permissions issue, which is easily managed. You only have to set your scripts to be readable by *you*, and you "neighbors" are *not* able to "browse" your directories - they can "see" them, but not read the content files. wink

--rlparker

> This is not a relevant issue when running the default PHP
> as CGI on Dreamhost, as DH's use of suexec causes your
> scripts to be run as your user

> You only have to set your scripts to be readable by *you*

Are you saying that scripts /are/ vulnerable to neighbours unless/until you change the permissions?

In reply to:
Are you saying that scripts /are/ vulnerable to neighbours unless/until you change the permissions?

No, that wasn't what I meant (though I see now how it could have sounded like that!) I meant that yhou only needed to set the permission to be readable by you for the scripts to run correctly. wink

While the report that you quoted might have been a problem in the past, DH is currently set up so that one user ("neighbor") *cannot* list, or view, code in *another* user's directory. In short, you are "safe" from that kind of prying.

You can check it out yourself! Move "up the tree" in the shell to /home, and you *will* see other's directories (you could actually even "cd" into them), but if you try to list the contents of those directories, you will be denied. smile

Does that make it more clear?

--rlparker

> DH is currently set up so that one user ("neighbor") *cannot*
> list, or view, code in *another* user's directory. In short,
> you are "safe" from that kind of prying.

Forgive me for being sceptical, but last time I read that claim (by DH itself, as it happens) it turned out be be false. See the thread: http://tinyurl.com/34rffk .

> You can check it out yourself! ... you *will* see other's directories
> (you could actually even "cd" into them), but if you try to list the
> contents of those directories, you will be denied.

That's little consolation. This security issue is about viewing scripts, not directories.

In reply to:
Forgive me for being sceptical, but last time I read that claim (by DH itself, as it happens) it turned out be be false. See the thread: http://tinyurl.com/34rffk

Chris,
Hey, I'm all for skeptical! I also remember that thread from about 18 months ago - and what I am trying to tell you is that they have changed the way that operated. I'm not asking you to trust me, try it yourself smile .

I *used* to be able to access others' logs, and from that find my way around into their directories and "cat" files that I found there...logs are no longer accessible to other users, so that avenue is closed.

Are you able to view another's script? If so, you are rightly concerned and should report it, and the methodology, via support. - I can't do it anymore myself (I *could* before).

Only you can say what security measures provide you with the required degree of comfort, and you *should* address security issues you can document - other than that, it's just so much FUD.

Seriously, if you can *still* read another's script - DH needs to be told (and I'd like to know how you did it! - preferably via PM, as if you have determined a security exposure still exists I don't think you should publicize it until you have notified DH and given them a reasonable amount of time to address it.)

Finally, if you believe the exposure exists, even if you can't demonstrate it, just tighten your permissions appropriately. Your scripts do not *have* to be accessible to anyone other than you - you can tighten them all you want. wink

--rlparker

> Only you can say what security measures provide
> you with the required degree of comfort

Those measures are whatever it takes to put an end to the dire service we are getting from DH variously blamed by them on hogged/hacked/compromised shared servers. I'd like to see DH's statement on the /default/ security level that surely is the root issue here. And this time I'll take a screen shot of it, just in case, like before, it magically changes when/if people expose it as false.

In reply to:
Those measures are whatever it takes to put an end to the dire service we are getting from DH variously blamed by them on hogged/hacked/compromised shared servers.

Blah blah blah...so this is more of a general purpose gripe/whine/bitch/kvetch than it is a sincere *security* concern. I see.

In reply to:
I'd like to see DH's statement on the /default/ security level that surely is the root issue here.

Then you probably should ask support to provide you further explanation. smile

The biggest part of that is *your own* responsibility - take responsibility for your own permissions; DH has given you the tools to tighten them so that only you (and scripts running as you) can read them, if you can't be bothered to do that, why should DH?

In reply to:
And this time I'll take a screen shot of it, just in case, like before, it magically changes when/if people expose it as false.

That's always a good idea when dealing with someone you believe is being less than candid with you. wink However, for the record, if you have followed this issue at all in these forums or the web in general (it has been discussed also on other venues), you would realize that "magically changing" is not the way this issue was addressed; DH has, without much fanfare but also without keeping it a secret, changed the default access shared machines afforded to their users.

Believe what you want, but realize how disingenuous you sound when you initiate a thread about a perceived "security issue", that ultimately turns out to be more about your personal dissatisfaction.

I'm all for investigating security issues, and will actively participate in researching them, but if at the end of the day, you just want to whine and/or make unfounded allegations of duplicity - I have better things to do than to exchange posts with you. wink

--rlparker

Oops nm, couldn't see full thread before for some reason.

> The biggest part of that is *your own* responsibility

Wrong. We are unable to fix the vulnerabilities of other accounts of the same server caused by DH insecure defaults. Responsibilty for that lies with DH and DH alone.

> DH has, without much fanfare but also without keeping
> it a secret, changed the default access shared machines

And where's the DH announcement of that?

> you initiate a thread about a perceived "security issue",
> that ultimately turns out to be more about your personal dissatisfaction.

If I wasn't personally dissasisfied with DH security, I would hardly have started the thread, would I?

In reply to:
We are unable to fix the vulnerabilities of other accounts of the same server caused by DH insecure defaults. Responsibilty for that lies with DH and DH alone.

True enough, as far as it goes in *any* shared environment, though as shared hosts go, I don't believe DH's defaults are "insecure" - particularly when compared with other shared hosts. We are also "unable to fix the vulnerabilities" caused by idiot/ignorant/resource-hogging users that may get placed on the same box - such is the nature of shared hosting.

If you want total control of what is run on a box, and how it is run, then you are probably a poor candidate for shared hosting and should seriously consider getting your *own* box, where you have to make no compromises, can set things up any way you want, and don't have to worry about the actions of other users at all. If I felt I needed to, I certainly would.

In reply to:
And where's the DH announcement of that?

I didn't see one (which is what I meant by "without much fanfare" wink ), but ran across postings in my surfing where DH reported they had done so (you've been around long enough to google such stuff yourself, if you are interested).

Fair enough, you are dissatisfied with DH security--as you were 18 months ago, and yet you are still here; It appears the dissatisfaction has been fairly manageable and that your security fears are reasonably marginal. wink

--rlparker

>> And where's the DH announcement of that?

> I didn't see one (which is what I meant by "without much fanfare" ),

That's what's meant by "without any fanfare".

In reply to:
That's what's meant by "without any fanfare"

Very true! That's an accurate assessment. Ha ha smile .

I suspect they were not particularly anxious to publicize the existing situation. wink

--rlparker

> I suspect they were not particularly anxious to publicize the existing situation.

I've no doubt you are right. DH cannot be trusted to be honest and open about security issues.

In reply to:
DH cannot be trusted to be honest and open about security issues.

Actually, I *do* trust them; I also have noted that they do not generally discuss potential security problems in public - part of the "security by obscurity" philosophy (which, to my way of thinking, is not a very effective tool).

For instance, they do not publish their mod_security rules, considering them to be a potential source of attack vectors and preferring to keep them private...and they change them at will. While that is somewhat useful as a security mechanism, it makes it very hard, at times, to determine if mod_security is causing a problem with your site. wink

IIRC, it was actually one of the Honchos who I read admitting that they needed to improve the other log file/default perms situation, and that they had taken some corrective measure - so in that case they at least recognized the issue needed attention.

--rlparker

> I *do* trust them

What's changed your mind since DH was last caught lying?

Actually, they have never lied to *me* - they have been mistaken, but I haven't attributed that to deceit - just error, or ignorance, or confusion. While no one is perfect, and no company is without fault (including Dreamhost), it's the *pattern" of action that I'm concerned with, and I have always been impressed with the candor with DH has dealt with me. smile

"Dreamhost" is a company, and *people* "lie" - companies have no "moral" component to their behavior. Is it possible that a DH employee has ever lied? Of course!

Is the company, therefore, dishonest? Only if they condone, or encourage it - and I have not seen DH do that in the 8 years I've hosted here. Some people look at an issue, or an action, and see the worst possible explanation; others look at the same set of facts and see other possible explanations. Many times this is the case when someone perceives someone else is "lying".

All this actually is "off topic" for this thread. I think if you want to discuss whether or not Dreamhost is honest, deceitful, etc. you should start a thread with an appropriate subject heading - you'll draw a very different crowd to that thread than you will to a thread on security issues (from which this has now devolved) wink

You seem to really, really distrust DH, - and it seems you you have felt that way for quite some time now. I'm wondering why in the world you would continue to host here if you really feel that way about it? There are far too many hosts around to trust your data and your sites to people whom you deeply distrust, and life is far too short to spend time being frustrated with such a situation. Just my thoughts, and obviously YMMV.

--rlparker

> it's the *pattern" of action that I'm concerned with

That I can appreciate. For example the pattern of complete indifference to the long known system vulnerability that lets /any/ user A intercept mail sent by user B to domain C just by A putting a bogus domain record for C in his control panel.

I am amazed that you consider a company that allow this, and does not even warn its users, to be trustworthy.

> "Dreamhost" is a company, ... companies have no "moral" component to their behavior.

LOL!

In reply to:
"Dreamhost" is a company, ... companies have no "moral" component to their behavior...LOL!

smile I *thought* you might get a kick out of that one! You are welcome! smile

--rlparker

Thanks for lightening my day ;)

In reply to:
For example the pattern of complete indifference to the long known system vulnerability that lets /any/ user A intercept mail sent by user B to domain C just by A putting a bogus domain record for C in his control panel.

that will happen in almost any server configuration on shared host.
The way that DH shares there domains configuration, just allows it to be done on different servers.

PHP security from user server users