Re: write with cURL

Jerry Stuckle wrote:

Tim Greer wrote:
Jerry Stuckle wrote:

Tim Greer wrote:
Jerry Stuckle wrote:

Tim Greer wrote:
Jerry Stuckle wrote:

Tim Greer wrote:
Ylva Poelman wrote:

The problem is that I do not want to change an existing file,
but to create a new one, write to it and saven it.
Then the directory you create the file is needs world read,
write and
execute permissions. This is assuming that the PHP script runs
as the global web server user (and it surely does given the
problem you have). So, create a directory and set it to chmod
1777 (or 0777 if you can't add the sticky bit) and then have
files created there (or wherever you need, though it's a
terribly bad idea to set the primary web root directory itself
to world writable).
World read/write is VERY BAD. It opens the website to all kinds
of potential security risks from other users on the same server.

Rather, it should be user and group read/write, and ensure the
web server itself is part of the group.

I made this suggestion because their web host appears to run
Apache as the global web server user and thus needs world write
permissions to
work. I doubt the OP has permission to configure the web server
in this case and it doesn't appear their hosting provider has it
set up
that way. Also, if you have the web server added to the same
group that the user belongs to (for read and write permission),
you still need to give that group write privileges all the same,
which imposes many of the same risks as setting privs for world
(now it just applies that same logic to group).

That is incorrect. It does not need global write permission. I
don't have it on ANY of the servers I manage.
I didn't say it needed global write permissions, I said the group
Apache
runs as still needs write permission. Hence, any PHP scripts on
the server have the same write permissions, since they all allow
Apache's
group write. Hence, any PHP script ran on another account, has the
same write permissions to one user's file as their own PHP script
does on their account (if it has write/modify/delete permissions).

Incorrect, if the server is set up properly.

I guess you think it is, but you're mistaken.


You obviously don't understand how to set up a server properly. It is
secure.

In fact, I do, and unlike you whom just comes to usenet to run his mouth
and argue with people, I DO know what I'm doing. Put up or shut up,
for once in your life. I'll offer you an account on my server and you
offer me one on yours. Give me 1-2 minutes and I'll exploit the PHP
setup you have by accessing files owned by other users, regardless of
what restrictions you have in place to try and make up for not having
the right setup. If you can use PHP on my system to read another
user's file that the user has lower permissions on (yet PHP still
works, go figure!), and if I can't access another user's file on your
setup, then I'll give you $100 on top of it. I'm serious. Instead of
just arguing with people about how smart you think you are, put up or
shut up. You have no idea what you're talking about and you want to
insist that you're right and I'm wrong. So, let's prove it.

And no, you don't have the same exposure.
Correct, not the same as global write, just the same Apache group
write.

With world read/write,
anyone
can access the files through ftp, ssh, etc. That does not have to
be the case - and is very dangerous.
I wholly agree. The idea of using Apache's group as write only
allows Apache and the user write access then, rather than anyone
with any
service. It is indeed better, but I still think it's too much of a
risk to allow Apache's group write access, since all PHP scripts
ran by any user on the server will have the same write access to
that same
file on another account. Again, a far shot better than world, but
I doubt this user has the ability to change how their host runs the
service now anyway. Thus, if the OP made a suggestion to their
host, they should ask them to install suPHP, which is a better
solution than global or Apache group (it can still use Apache group
to offer web root protection, and then lock it down with PHP
scripts and its files being 0400, 0600 or 0700 and not needing to
be higher, ever).

Granted, that would make is so the web server will have read and
write access that only root, the user themselves and the web
server group have that access to (and not just any user would, so
it is better than world), and thus it's slightly better in that
regard, but it will still allow any user's PHP script to have the
same write, modify and delete access to the user's files, since
it'll run as the Apache group, too. Instead, I recommend having
the host implement suPHP and not run PHP in the Apache API, so
only their user and the web server have read, write
and execute permissions. But, that's still up to their web host,
and it doesn't sound like either of these suggestions are viable
options for them.

No, this can easily be handled with the PHP configuration
Yes, it is easy. That doesn't mean the user has control to change
it, or that their web host will change it if they request (maybe
they will
though?) Oh, you mean so every user can't write to another user's
file
they allow Apache's group to write to. I wouldn't say that's easy,
it's able to be gotten around to still write to files across the
file system.

No, the user can't change it - wouldn't be much security if they
could now, would there be.

And that was my point. For their web host they are on, they do not
have a choice and will need to set it to world write permissions for
their script to work.


You don't know that. For instance, right now they might not have
group permissions set up properly.

Doesn't matter. If PHP can read it or write to the file and if PHP is
running in the Apache API, another user can read or write to that file.

And it is quite easy to set up, and just as "easy to get around" as
OS privileges - IOW, you can't.

It's not "as easy to get around as OS privileges". That's a
ridiculous
statement to make. Regardless of the web service, you can't "get
around" permissions settings that deny other users that aren't
allowed
to read or write to a file. Your suggestion specifically allows all
user's PHP scripts to execute as the same user and need the same
group
to have read and write permissions on files (for all users). Your
only way around that being a global security issue is to put
restrictions on
PHP settings and how it's ran, which can be bypassed. If the
permissions are low enough with something like suPHP, then there's an
absolute method that will not be able to be bypassed unless you are a
privileged user (in which case it doesn't matter the method).


Just as it is impossible for a script to write to another user's site
if
the security is set up properly.

Then that means you're running suPHP and not running PHP in the Apache
API. However, since you don't then one user's PHP script can read or
write to another user's file. Even with suPHP without the lower
permissions that's possible (I won't get into that), but with suPHP and
lower permissions, Apache and PHP can't overcome the permissions
locking it out from other users.

You claim it can be gotten around -
yet you provide no examples of how this can be done.

I said I'd email you how, and you never took me up on the offer. Now
you insist I am wrong and you are right, and that I don't know what I'm
talking about. Fine, so let's prove it. Let's give each other access
to the other's server and I'll prove it to you in a matter of 100
seconds. Then I'd like to see you bypass my setup.

It is 100% secure,

No it's not. Just because you claim it is, doesn't make it so. So, put
up, or shut up, Jerry.

and cannot be gotten around,

Yes it can. The fact you're so confident it can't says a lot about you.
Just claiming your opinion on usenet as fact isn't anything new for
you, but here's a chance to prove it. I'm making a genuine offer.

if it is set up
properly.

If it's set up properly, then it's not going to be your setup.

I'd like to see yo ushow how it can be gotten around.

And I've offered to show you. Are you afraid of being proven wrong?
I'm not, if I'm wrong, I'm willing to learn a lesson. Are you? See, I
know my setup is secure, so I'm making the offer without reservations.
You know you're not qualified and hence you won't respond to that
challenge. Email me and let's get this going. The worst thing that
can happen, is you learn a lesson.


. Even
though all sites have the same user, scripts in one site can be
restricted to access only the files on that site.
But trying to restrict them isn't going to always work. There are
methods around that which aren't very difficult to overcome. It is
better to use another method like suPHP. Again, the method you're
suggesting is probably a good middle solution, being better than
global writes.

Proper configuration and they can't be overcome.

Yes, they can. And it is by all means not as secure as a
configuration that takes advantage of lower permissions (which you
can't make up for or emulate, you can only attempt to put in
restrictions).


Please show how it can be bypassed.

Take me up on the challenge and I'll show you. I'll give you an account
on my server first.

If the web host doesn't offer that or won't change (they likely
won't if they're not already doing it), I'd suggest to just run
PHP in CGI (if the host offers CGI with the SuEXEC CGI wrapper),
as that will provide them with the same advantages of not having
to use world (or group w/ a shared Apache group) access to
anything, though it would require a trivial amount of knowledge
with permissions and likely adding the
shebang line to the top of any PHP scripts they'd be executing.
It may come down to that or finding a web hosting provider with a
better idea of what they are doing.
CGI is not necessary. All it takes is correct configuration of
the system.
CGI is necessary to prevent the same level of access by the same
group needed to write to any users file that they need PHP to
write, modify or delete, assuming it uses SuEXEC (otherwise the
same problem exists
anyway). You can try and restrict PHP's configuration and even use
"pre" filters if you must, but that will not stop every method to
open and write to a file in another user's account, list those
files or do
damage. If you don't believe me, please email me and I'll provide
some examples for you, as I'd rather not post a "how to" here.
Not at all.

So _you_ say.


That is 100% true.

Again, just saying it doesn't make it so. I wonder, is it in your
ability to apologize or admit you're wrong?

I challenge you to show how it can be bypassed.

I offered to email you, but you claim I have no idea what I'm talking
about. So, if you want to challenge me, let's give each other an
account on the other's system and I'll be happy to show you. What are
you afraid of, your system not being secure?


All that does is move the security from PHP to the OS, at
an additional cost of performance.

It does add a performance hit when the CGI process is spawned outside
of the existing httpd process itself (not embedding it), but the
difference is trivial and the advantages are significant in many
aspects (from per process and user control of resource usages,
concurrent processes, run time, etc.) to abuse tracking, per user
controls or acl's, to securing your files and scripts from other
users on the system.


If it is to be run as a different user, it must be spawned outside of
the existing httpd process.

Yep.

On a busy server, the difference is NOT
tivial and can add up quickly.

Only if your code sucks. CGI overhead isn't detrimental. And, any site
that gets SO much traffic that they have it negatively impact the
server, shouldn't be on a shared host, since in the Apache API it will
still be too busy of a site to be on a shared server. On a dedicated
server, I'd suggest people do run PHP in the Apache API, because there
are no other users on the server and they have the script run as a non
privileged user. Even so, the difference of the overhead (which is
low), is overcome by having the benefit of being able to control that
user's processes. Just as a user's PHP script on a shared server in
the Apache API can get out of control without a good way to prevent it
from overloading the server, you can do this per user and per vhost
with CGI.

FASTCGI helps, but still does not
eliminate the problem.

It doesn't help a lot, I agree, and doesn't solve the issue in Apache
with PHP in the Apache API.

And it is unnecessary in a properly set-up server.

You _think_ you have a properly set up server, and in some sense you
might, but it's not as secure as it could be.

The same level of security can be
had when running PHP as a module.

No, it can't. That's the difference between a global user (or group)
running your script, or your own user.


You obviously do not understand how to set up PHP properly.

You're wrong, and you keep saying that (I get it). So then, accept my
challenge and let's give each other an account on the other's system
and prove it. It's that simple.

It's how I have my servers set up,

And you're not a server admin, you don't specialize in this area, and
it
shows by your stubborn claims. I know you like to argue with people
on AWWW as well as here, but enough already.


Actually, I've been administering UNIX servers for almost two decades.

Yet, you still don't know what you're doing.

The difference is, I know what I'm doing and how to set something up
properly.

You say so, so put up or shut up, Jerry. It's that simple.

and scripts from one site cannot access the directories on another
site - even though Apache is a member of both groups.

It can be exploited.


Please show how.

Give me an account on your system and I'll show you. I'm not going to
give an example here and have you just immediately reply claiming it
doesn't work on your server when I know it does. What are you afraid
of?

Of course, you need to set everything up properly - but that's true
in any case.

You can continue claiming that, but you're spreading misinformation,
and
it's all for nothing. The OP doesn't have the ability to do either
set up themselves and they therefore HAVE to use world write to be
able to modify or write to that file in their case, and that's a
fact, and why
I said they would have to. I never claimed it was a good thing to
do,
but something they'd have to do in their situation. Regardless of
what
you continue to claim, you're wrong. PHP in the Apache API,
regardless of what settings you have or try, is always less secure
from a user
perspective than CGI (using suPHP). Don't believe me? Let's give
each other an account on each other's server and see how many seconds
or minutes it takes for me to show you a way to exploit your set up,
and
let's see you spend days or weeks and get nowhere on mine. That's a
public and open challenge, because I'm really tired of your arrogance
on the newsgroups where you ramble on about how your opinions are
somehow fact and you make such an effort to argue with people when
you
actually have no idea what you're talking about. I've tried
repeatedly to explain and offered to take this to email where I could
show you, but you'd rather tell me I'm wrong.

I'm not saying anything about the OPs ability.

No, you're not, you just wanted to try and argue with me about my
suggestion to them, and there was no reason for it. And, as usual with
you, you had to escalate it into an insulting response claiming that
you are a know-it-all and to claim I don't know what I'm talking about.
I do, and you're wrong. So, since you don't believe me, let's give
each other access to the other's system as a normal shared server user
and I'll show you.


I'm calling you on
your
statements

No, you're not. You're desperate to prove you know more than anyone
else and to argue with anything they say, regardless that you are
absolutely wrong. If you don't know there are ways to exploit your
setup where users can access each other's files over PHP, fine, but
that doesn't make me wrong because _you_ don't know. I offered to
email me and I'd tell you, but you didn't and come out acting like you
are right and need to tell me I don't know what I'm doing. So then,
Jerry, simply put up, or shut up. I'll prove it to you in a matter of
minutes if you accept my challenge.

that setting world read/write authority is necessary.

My statement said that in their case, it is. There's nothing to argue
about that, but far be it from you not to argue.

That
is VERY DANGEROUS and should not be recommended to anyone, especially
in a public newsgroup.

This is pathetic. It was suggested in this news group to this user,
because that is the ONLY choice they have to write to a file on their
web server, unless their web hosting provider changes the way they run
PHP. It's ridiculous to claim that it shouldn't be recommended, when
it's their only option (that or running PHP as CGI with the shebang and
proper permissions, assuming the host offers CGI with SuEXEC). I even
said it's not a good thing to have to do, and to be careful what they
set to world read and write, but you felt the usual overwhelming urge
to argue with what I said.

Only those who don't understand the implications (or how to set up a
server) would make such a recommendation.

This is the sort of nonsense I've grown used to seeing from you. A user
is on a web host that PHP runs as the global web server user, that is
what they have to do to write to a file (give it world write
permissions, or world read/write for a directory to create a file
within it from PHP) and because I explain to them that true and
accurate information, you reply as if I fail to understand the
implications, even though I specifically said myself that it's not a
good, secure way to have a server set up. So, even though I never
disagreed with you, you continue to argue and use that as a basis to
show that I somehow don't know what I'm talking about and the simple
fact I made the recommendation is proof (even though that's how their
web host has the server set up -- something I have no control over what
the OPs web host does). Yet, none of that sinks in or gets through to
you.

So, fine, if you don't get it, I can't help you. However, I have
repeatedly offered a challenge to you. We each give the other a normal
shared account on our servers, and we see if the other can show how
their setup can be exploited to read or write to other user's files
that we want to prevent. I CAN do this, you CAN NOT do this. I CAN
prove it and thus the offer, and I'll even give you an account on my
server first, if you accept that offer. I say once again, rather than
just claiming you're right and someone else is wrong, here's a chance
to prove it. I know that's a new thing for you to have to face
(actually proving what you run your mouth on about that you are
actually wrong about), so instead of words, put those claims into
action and take me up on my offer. It's simple, Jerry, put up, or shut
up. Either way, I'm happy, because I'm honestly had enough of you
making untrue claims on usenet and pretending you know things you don't
(not that I'd normally care, except that you challenge what people say
that do actually know what they are talking about, and that's
annoying). There's the offer, either take or it refuse it (though the
fact you'd refuse it says you know your system isn't secure, else you'd
accept the offer). Instead of using your poorly chosen and lies of
words, let's make it real. The offer is there, unless you're afraid of
being proven wrong (because your words can't get you out of it -- and
apparently you are that worried about being proven wrong). Shameful.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
.

Relevant Pages

  • Re: write with cURL
    ... execute permissions. ... This is assuming that the PHP script runs ... of potential security risks from other users on the same server. ... web server itself is part of the group. ...
    (alt.php)
  • Re: write with cURL
    ... execute permissions. ... of potential security risks from other users on the same server. ... I made this suggestion because their web host appears to run Apache ... risk to allow Apache's group write access, since all PHP scripts ran ...
    (alt.php)
  • Re: write with cURL
    ... execute permissions. ... of potential security risks from other users on the same server. ... I made this suggestion because their web host appears to run Apache ... risk to allow Apache's group write access, since all PHP scripts ran ...
    (alt.php)
  • Re: Apache vs IIS
    ... Windows Server not on my Linux Server so there for I would chose IIS. ... Not that Apache is bad but ASP.NET is far easier and faster to create good web forms in. ... PHP on a IIS server is rather easy to run once you install PHP on a PC but if you only use PHP why not use Apache for Windows. ...
    (alt.php)
  • Re: write with cURL
    ... offers PHP, if they don't allow PHP to open and write ... Check the permissions on the directory the file is ... such as chmod 0666 test.txt ... their server configuration is, too, though. ...
    (alt.php)