Re: write with cURL

an account on my server. Plus, in order to do it,
I'd have to set up an entire website for you, etc. I'm not
about to do it.

Now if you were a paying client, I would do so.

...

You can email me - my (munged) address is in my sig.

...

As I said - you've got my email address. Now show me how to do
it.

...

My (munged) email address is in the sig of every post. The fact
you are making excuses and didn't send me an email shows you
can't do it.

...

Become a paying client and I'll set it up for you.

...

Become a paying client and I'll give you an account on my
system.

Email sent Fri, 27 Feb 2009 14:26:43 -0500 (11:26 PST).

Dear Jerry Stuckle,

Regarding the usenet thread where you've agreed to allow me to
prove that your PHP setup is potentially not secure from user's
reading each other's files using PHP, you've stated that I would
have to pay for an account.

This is fine. Please let me know the price for your lowest
priced
shared hosting account and I will promptly remit payment. Please
also let me know the methods of payment available (such as
paypal, or a merchant interface).

By accepting this, you agree that I am allowed to test the
security of your PHP install, and not cause any damages or access
any data that would be against state or federal laws, and that
this is simply to illustrate that your PHP setup would allow one
user on one account to use PHP to access a file readable by the
web server's user/group on another, separate account.

Therefore, if you can ensure that you have some test setup with a
temporary user or your own, and not for one of your normal shared
hosting users, that would be best. I remind you that I'm not
interested in accessing any other data or doing anything
malicious on your server, but to example how your PHP setup is
not as secure as you believe it to be.

Thank you,
Tim Greer

Be assured that I will not post any of the account information or
the
information regarding the server name, login, or IP publicly.
This is just a copy of what I have emailed to you.

Also, please don't avoid this by setting some unreasonably high
price for your lowest hosting plan, acting like you have to charge
some high premium because your services are "so specialized", when
this is just a
very basic shared hosting account. I'm willing to do my part and
actually pay to show you, so don't try and avoid this because I
called
your bluff. There's no reason why you can't have me show you,
even if you've actually said you needed to charge me to host the
account, just to prove what I'm saying to you.

I pretty much called this one 100%, word for word. With no replies
at all, I searched google for his site and didn't find one, but
found Jerry's phone number and called and talked to him for a
little bit
(obviously caught him off guard. We had a civil conversation,
unlikely
on usenet). No reply to my email at any point, by the way.

Basically, he said he doesn't do hosting, and that he only does
development and would have to charge me for site development and
hosting, because that's how he makes his money. I explained he's
not selling me the service, and how much would he charge me to just
set up an account (nothing more, just need him to run adduser in
shell and then add me to log in over FTP), since he said I'd have
to pay for his time.

He explained he only does full site development, wouldn't budge on
the matter and after asking a few times specifically about his
lowest site development costs, he finally gave me am amount ($200
(two-hundred dollars)), stating that he doesn't have an automated
system to set up the accounts and that this is how he makes his
money.

Apparently the difference of setting me up with an account and to
show
him an example for 5 minutes, is going to cost at least $200. I
personally am sure he doesn't feel comfortable giving an account on
his server to someone he's argued with on usenet, and I can
understand that, but he says his system is secure, that wasn't his
concern (okay,
then). I gave a very rough example about how this can be done,
though I didn't go into detail (I explained it's difficult to
outline, which
is why I wanted to show him). He said he didn't think it would
work,
but he didn't try it either. So, we're at a stand still.

I am unwilling to spend $200 just to show him what I mean, which
will work (I know people that use the same type of setups, thinking
they can
get around the security issues. He can insist he can and I can
insist he cannot, but without a reasonable means to prove it, it
once again
falls back to an argument on usenet, which is pointless. I've made
every effort to show proof, but I guess it's easier to argue with
people on usenet when one can't be proven wrong. So be it. I
welcome anyone curious that uses a similar setup to allow me to
show them, if they want, simply because it's important for people
to know what is truly completely secure or not, and I don't think
any user with an SSI or PHP script (or other) being able to read
another user's script as being secure (and that is what it comes
down to).

I didn't deny Jerry's method is better than world write, and I
didn't suggest world write was a good idea (I only told the OP that
this is one of the only ways they can write to a file on the host
they are using, but suggested it's a bad idea and to use another
method). It's as simple as that, and I'm not able to prove it,
because in the end, Jerry wasn't willing to allow me to on his
system, even after saying so (he avoided it by demanding an
unreasonable $200 fee so I could show
him something that takes a whole 5 minutes from setup to example).
It is for the benefit of everyone to know what is going to actually
work
or not, but oh well. I think I've proven my point here, and the
likely follow ups claiming otherwise or that the Apache group
method is actually secure and continue to argue about it (and not
allow me to
prove otherwise) will unlikely convince anyone. My offer remains
(for a reasonable price).

I can appreciate the method Jerry uses is better than not, and I
only posted to defend myself from accusations accusing me of
somehow saying world write was a good idea, or that hi method is
just as secure as the
one I suggested would be best (because it's not). It comes down to
some pretty basic things about how Apache works (and needs to work)
that can be exploited (and this is completely separate of any PHP
settings one can try). While explaining just one very simple
aspect and method (there are many) to Jerry, it became clear he
didn't
understand what I meant or how this security threat existed. It's
not that I didn't realize it was a waste of time, since arguing on
usenet is as well, when someone refuses to listen, but I knew in
the end that he'd avoid facing being exposed, thereby removing all
credibility to his arrogant claims about how he knows what he's
doing and no one else does.

Instead of simply discussing this, he went on the attack, so I
replied
and invited a way to prove it on both systems. It's too bad when
people are that concerned about being wrong, that they are
unwilling to learn something, especially when that knowledge helps
better protect their own clients (and dare to suggest I was being
reckless for simply suggesting to the OP about he'll need world
write permissions on HIS current host, even after warning the OP
it's not a good thing/risky
using such permissions). Why go on the attack, if you are going to
go
to extremes to avoid facing the issue? In the future, a different
and civil attitude asking how it would work/what someone means
(even if you don't believe it), is far better than accepting or
offering your own challenge for them to prove it, and then say
"well, I'll need at least
$200 to set up an account for you, because I do development". So?
This isn't a development issue, it's about how much to get you to
take
2 minutes to set up the account. I'd have more respect for someone
that just said they're not going to allow some usenet poster they
don't like to have a physical account on their server or say they
don't feel
comfortable about it. There's worse things in the world than being
wrong, but there's no reason to be so aggressive about your arguing
methods that you force someone to put you in a situation where
you're
worried about embarrassing yourself. I don't even know what more I
can say, but I do appreciate that we could speak on the phone in a
civil manner (perhaps if we did originally, this would never have
escalated). Oh well, I tried.

Sorry, I'm not on usenet or email 24/7. I do do work, you know, and
don't always respond immediately. As a matter of fact, I was
working on a response when you called.

That's fine, I just explained why I looked for the site and ended up
calling.

Yes, I do site development. And as I explained to you, I do custom
development - including custom web server setup. It means I do
everything manually - I have no automated process (it's not worth
the time and effort to automate for the few I do).

It doesn't take over a few seconds to set up a normal account.
Asking $200 is unreasonable to just set up an account with the very
basics to show a 1 minute example to show you what I was talking
about.

Actually, it does take longer than that to set it up with security.

To justify $200 worth? Forgive me if I find that suspicious. We're not
talking about a customized service here and security should be done
across all users equally, unless you plan to either allow a specific
user to do more or to lock them down more than someone else (neither
would be appropriate in this case for this example, but neither would
matter, which is the point I was intended to prove). Of course, it's
all for nothing if I'm unable to prove it to you.

And no, my time is the only thing I have to sell, and I'm not going
to spend the time manually setting up a site without getting paid,
and it's not a $3.95 bargain basement account.

Who said it had to be only $3.95? What about $20 for 5 minutes of
your
time? That's cheaper than the bottom site development price of $200
when you equate the hours spent. The fact is, the development costs
have nothing to do with it. I repeatedly said I'd understand if you
just didn't feel comfortable. You insisted it was because you needed
to use your pricing structure for full site development and hosting
(all just to create a basic account for something that would take a
couple of minutes).

And yes, I do control who has access to my servers.

Obviously.

With my customers
I have a contract, and if they do anything to harm the servers, I
have legal redress.

That's fine, so why didn't you say that before? Why not say that
originally? I could totally understand it. You said that you'd set
up
an account only if I paid you. I said I would. Then it was $200,
and now it's to protect your clients.

Not that any of them would - I pick my customers
carefully, also, and don't let just anyone on the servers.

That's all fine.

And yes, I understand what you explained to me on the phone. But
the first step requires access the users don't have - so the rest of
it is immaterial.

If you think it requires some special access or absolutely anything a
user couldn't do in any type of hosting or shared system environment,
then you didn't understand what I had explained.

Yes, I did understand, and on my servers they can't do step 1. It
doesn't require "special access" - but it does require access they
don't have.

There are ways to do "step 1", but that was just an example of one
method to get there. There are many ways to do the same thing, that
was just one I covered quickly on the phone. Also, what happens when
they upload a binary for the command or use another method (which is
easy enough to do). You then have to try and take further measures to
prevent that. Eventually, you're left without CGI, PHP or SSI, or
otherwise have to run it in a way that no shared host could run.

That's okay, I'm not being paid by you to secure your servers, and
I'm certainly not interested in paying you $200 to help you secure
your own
servers. In fact, I've never said your servers were horribly
secured, and just said that if a user of yours was malicious or had
their account taken over by a malicious user, then the Apache group
idea would open the potential for that malicious user to exploit that
setup to read and write to other people's files.

Sorry, my servers are secure.

No need to apologize. You're welcome to believe it, and that's fine.
My offer was to prove to you what you said I was wrong about and your
accusations that I didn't know what *I* was doing.

More is quoted and replied to below.

Now, if you know and trust your users, it's unlikely that will be a
risk, provided no malicious users gain access to their account or to
the server in another way. Really, in the end, just saying you're
not comfortable doing it, don't have a server free of non paying
clients you'd feel okay about using, or want to protect yourself in a
legal aspect, then that's fine.

.....

On Fri, 2009-02-27 at 21:58 -0500, Jerry Stuckle wrote:

tim@xxxxxxxxxxxxx wrote:

Dear Jerry Stuckle,

Regarding the usenet thread where you've agreed to allow me to prove

that your PHP setup is potentially not secure from user's reading each
other's files using PHP, you've stated that I would have to pay for an
account.

This is fine. Please let me know the price for your lowest priced

shared hosting account and I will promptly remit payment. Please also
let me know the methods of payment avilable (such as paypal, or a
merchant interface).

By accepting this, you agree that I am allowed to test the security

of your PHP install, and cause any damages or access any data that
would be against state or federal laws, and that this is simply to
illustrate that your PHP setup would allow one user on one account to
use PHP to access a file readable by the web server's user/group on
another, seperate account.

Therefore, if you can ensure that you have some test setup with a

temporary user or your own, and not for one of your normal shared
hosting users, that would be best. I remind you that I'm not
interested in accessing any other data or doing anything malicious on
your server, but to example how your PHP setup is not as secure as you
believe it to be.

Thank you,
Tim Greer

Tim,

The problem is, you assume the user has the ability to create a

symlink.

No, that is just one way to get there. And, what happens when someone
uploads a binary for ln (I assume you have it disabled or removed or a
jailed environment where they can't use that system ln command and
don't have it where they can just alias it) and then run it? You plan
to deny execution by not allowing executables? What's the deal then?
Are you saying your server is secure because you modify the sites and
the clients don't have access to log in and upload their own or create
their own? If so, then it really doesn't speak in any great amount to
say it's secure because you restrict or don't allow your clients to do
normal and common things. Besides, this does illustrate the point that
if you were a normal shared host that offered clients the ability toe
create symbolic links (and why not in general?), that you would then be
open to that security risk.

Since you don't allow symbolic links to be created, you believe the
problem is nonexistent. Two problems exist with that theory. First,
there are other ways (this was just one quick example), and secondly,
more importantly, this wouldn't exist as an issue where users can set
the permissions on their files lower to deny other's from viewing them
or writing to them (symlinks or not). So, this does prove there's a
difference, and a pretty vital one. Surely, if having the ability to
use symbolic links on a server opens such a big security problem, then
you must admit that it's not as secure. If you think it's "as secure"
by removing the ability to do a bunch of things, that's one way to see
the problem, but it's more involved than just having the ability to use
and create symbolic links.

But that's not possible on my systems - I have ln and certain other
commands restricted so they can't be used.

Doesn't matter though. Obviously different systems can try different
things to achieve the same results regarding security, but at some
point, sometimes one of those methods is less secure and less
desirable. Again, your method is better than world write, but it's not
as secure as suPHP. There's nothing wrong with realizing or seeing
that. Perhaps you can manage to really take away a bunch of common
commands and features and hope no one could easily get around them (and
they can so long as you allow CGI and PHP since they don't have to use
"ln") and you have the same problem anyway. That just doesn't sound
like a good, sound balance to me.

So your idea of using a symlink to map the directory into the user's

web

space doesn't work.

But it does. You're saying it doesn't, because the users can't create a
symlink, but what if they could? They can still do it, after all.
However, let's just forget entirely about that one single example I
quickly rattled off about, since it was just one of many ways to get to
that point.

There is no need for a user to be able to create a symlink on the

system

for a website; if they absolutely need one and can justify it, I'll do
it for them. But no one has had a good reason why they need to do it.

Sure, there are plenty of reasons. Not having duplicate files that all
serve up the same data. Moving sites around without having to
duplicate the content or use rewrite or redirect rules, or a ton of
other reasons. But, I remind you, this isn't about symbolic links and
that was one example.

<snip. you have a strange way of quoting in this thread>

Actually, I DON'T trust my users - any more than anyone else. But at
least with a contract I have legal recourse against them should they
do anything harmful.

That doesn't have anything to do with the problem when someone with ill
intent gains access to your client's account, or that you can't know
all of your clients that well if you are very successful.

What is not immaterial is all of your previous claims and
accusations, going as far to say I said things I never said, meant
things I never meant, and so say I'm not a competent server admin
regarding security issues, all because you didn't agree with me (all
before we even
discussed what I was talking about). Your method is better than the
need for world write, I said that myself, and I didn't reply to
attack or embarrass you.

You are assuming everyone can do step 1. It can be restricted, quite
easily. And it is, on my systems.

I believe I replied to that misconception above, already.

In fact, my replies only come from the need to defend myself from
untrue accusations (all based on the fact you didn't agree, and you
attacked
me for it). So, coming to this final conclusion by calling your
bluff,
is hardly immaterial, and your clients could do these things.
However, this is certainly and obviously not going to go anywhere and
it won't progress, so I have left the offer open to you if you ever
want me to show you (even for a price -- but not for $200, you have
to be realistic and reasonable, else it smacks of an excuse), as well
as the
offer for others using the same type of setup as you. Beyond that, I
suppose we can drop the subject. I'm willing to, if you are (that
is, at this point, I'm just replying to the posts).

I don't agree because it's not true.

Yet you won't allow anyone to prove otherwise, which is pointless.
Don't accept or make a challenge and start running your mouth (or
keyboard) making claims and accusations, egging someone on, only to
back down when they call your bluff.

And it takes about 45 minutes to
an hour to set the account up - just because I don't do it very often.

Any good sys admin would create a script to do this for them if they it
more than once and it takes that long. I don't believe you, but I
can't prove you are just making excuses, but you can understand why I'd
think it.

And I have tests that I perform to ensure security before anyone is
allowed on the system - just to make sure *I* didn't miss anything.

Yeah, sure. Keep backpeddling.

Among other things, the test do try to do step 1 in your scenario

Something you didn't understand or try, or you did and saw it worked and
just don't want to admit it (and even claim you don't allow symlinks,
which is ridiculous -- a very poor way to tackle that security
problem). This is why I said instead of relying on PHP settings and
such things to take and make up for the lack of a good security basis,
that it is better to go with the better foundation. Otherwise, well,
you'd be in your shoes.

(yes, I'm familiar with it - just didn't want to get into an argument
on the phone), and fail if they can do it.

Yeah, sure you're familiar with it (or were already). Whatever, Jerry.
I know for a fact that because of the Apache web server design, that
any file that can be read by the web server without changing users,
will be able to be read or written to globally. There's no way around
it, because that's the way Apache is designed (and it's not just Apache
either, by the way, but since this is what the OP's host uses, as well
as both of us, it was relevant to the example). Really, get past the
symlink aspect, because that was one pretty trivial example.

Again, there's no point in you repeating what will or will not work, or
you insisting your server is secure or not from this, since you refuse
to allow me to show you on your system (and as I suspected, you would
just claim it doesn't work (though it's ironic you claim so based on
the fact that ln is disabled from your clients using it), just like I
suspected and called you on the excuse that it would be some
unreasonably large amount of money for you to set me up -- I called
that as likely to happen before I even called you.) Really, enough
already. You know I've proven my point, regardless of what you say or
believe and that is why you grasped for multiple reasons of why you
actually couldn't let me prove it to you. So, whatever, Jerry.
Nothing's going to change, and I'm just having to repeat myself (if you
don't listen or want to argue about it the first dozen times, there's
no reason why anything's going to change). So, let's just move on from
this topic and call it done.
--
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!
.