Massive SECURITY VIOLATION for installation of vShare 2.7 - !!!

Hi everyone. I'm having a major problem getting vShare 2.7 installed on our server due to seriously unreasonable requests that are made by members from HostOnNet.com who should really know better. First some quick background: In most European countries many servers are being hacked 24 x 7 each and every day, commonly with automated hacking software that pounds the server over and over and over... hundreds of times per hour. Here in Europe, security is vital and we never had a problem instaling and running vShare 2.6 with server security in place (see link).

MeineClipshow - Das Videoclip Portal von EinfachClicken - Einfach Prima!

Recently I paid to have vShare 2.7 installed from scratch on another domain so that I can do the translations, customization, etc. there, before moving everything over to the old location, replacing the current version 2.6 at that time. HostOnNet repeatedly tells me that in order to install version 2.7 we need to:

Quote:

---

open_basedir = (no value)
It is not possible to install vShare2.7 without this.

---

Our server admin, with decades of experience says this:

Quote:

---

Ich bin doch sehr verwundert über die scheinbare Unfähigkeit dieser Leute mit den kleinsten PHP Sicherheitsvorkehrungen diese Anwendung zu installieren. Die PHP Open_Basedir aufzuheben gehört mit zu den schlimmsten Sachen für einen Server, da die PHP Anwendungen dann auf den kompletten Server Zugriff haben und im schlimmsten Fall wirklich _ALLE_ Daten das Servers löschen können. Es gibt auch keinen richtigen Grund diesen Zugriff zu erlauben, alle benötigten Tools für VShare befinden sich in dem für PHP zugänglichem Ordner: /usr/php/bin:
ffmpeg flvtool2 mencoder mplayer

Auf mehr sollte diese PHP Software wie jeder andere keinen Zugriff haben ...

---

Translation, meaning:

"I can't believe that these people are so inept that they're not even capable of dealing with the most rudimentary safety concerns of a basic root server. To set open_basedir = (no value) is the worst possible thing that anyone can do on a server since it generates such a massive security vulnerability that any decent hacker could not only break into the server, but even go as far as to completely wipe out all data that's located on that server. There's no valid reason for that requirement in the first place since all required files such as ffmpeg, flvtool2, mencoder, mplayer are located at the proper location, /usr/php/bin"

HELP ....

So who's wrong and incompetent?
THREE TIMES the question was posted to HostOnNet ... can those settings be reversed again after the installation in order to make the server secure since vShare 2.6 runs without a problem, and THREE TIMES there's been no answer to this question! I'm not a server admin but I need to know who's full of baloney here? Creating such a massive security hole can't possibly be good and if that's what vShare 2.7 needs, then perhaps it's time to rethink that upgrade ... ???

.

To be fair, almost all of the video tube scripts out there have the requirement that open_basedir be set to blank so it's not specific to vShare.

With regards to your question on which is baloney, technically both are baloney.

From the vShare perspective, yes, vShare can be installed with open_basedir being set. The issue, however, is that it must be set properly. By default, open_basedir does not allow execution or inclusion outside of the executor's home directory or includes directory. The problem, however, is that most installations of PHP do not run suPHP. This means that most, if not all, of your executed tasks run as the server user (usually the "apache" user). This means that while your local user account can access and run programs such as ffmpeg, mencoder, etc, the apache user, which is not a local logon account, usually can't as there is no apache home or includes directory. The simple solution is to turn it off (which is what most scripts out there recommend). The more complicated solution is to run suPHP and properly set the open_basedir to include the proper locations such that PHP can effectively utilize your scripts. I can tell you that on many hosts out there, the latter is never the case. It is usually the former.

From your hosting guys perspective, setting or not setting open_basedir in itself does not create a massive security problem. It does not allow for someone to remotely gain access to your server or anything like that. The security issue that comes with not setting open_basedir happens if someone, who already has access to the server, uploads code that is bad or badly written. The key here is that you have to already have access to the server to exploit the possible hole. If a hacker already has access to your server, then there is no need to exploit PHP at that point.

Now, to your hosting guys credit, by not setting open_basedir, a badly written script could be exploited to execute rogue code onto the server from remote. But the kicker here is that if you properly set open_basedir, that hole would still exist. The reason is because open_basedir does not limit what PHP can actually execute. Rather, it limits the locations to what can be included or called. This means that if you were allowing your /usr/bin directory so that you can execute ffmpeg or any other tool needed for vShare, for example, the same code could also execute curl (local curl), wget, sh, or any other executable located within that directory. This would pose the same security threat as not having open_basedir set at all.

To date, PHP security (or the lack thereof) really does not tie into having open_basedir set. In vShare 2.6, one of the requirements was to turn off safe_mode and register globals, which is just as insecure as not having open_basedir set. Real PHP security comes from server hardening... in which you run process checks within PHP (Suhosin comes to mind), having PHP's setting's properly set, hardening Apache (to prevent people from overriding PHP settings, which can be done today), and, ultimately, hardening your scripts (vShare is in no way hardened).

Thank you. I'll be sure to share this answer with our server admin. I appreciate the many details, that was exactly what I was looking for.

Greetings from Germany

.