Quoting Derek Wright <drupal@dwwright.net>:
On Sep 13, 2007, at 5:34 PM, Earnie Boyd wrote:
How can this become an issue if only administrators have the privilege?
Various other people in this thread were proposing that the site could automatically download and install/activate jQuery plugins (either new plugins, or new releases of existing plugins). This would require the website having write access to its own jquery plugin folder. This is the giant security hole we've pointed out, and which you seem to understand.
Ah, I missed that. What I had proposed was the jquery_plugin module upload the files under administers control. Automated updating isn't something any sane administrator would want to do.
The confusion is between people who sanely understand that the only safe solution to this problem is for the human admin to manually upload/install new jquery plugins outside of drupal (scp, ftp, rsync, whatever -- some process with write access to the drupal sources which is *NOT* initiated via httpd and php) and the people who think that the site could somehow upgrade itself.
Drupal upload service could make use of extended PHP with ssh module[1] if available. We allow files to be uploaded now and since a jQuery plugin is client side JS and won't be executed on the server why not allow the administrator to upload it via the Drupal service? [1] http://us.php.net/manual/en/ref.ssh2.php
To be extra clear, I should state: letting httpd or php write to the drupal sources *AT ALL* is a risk. Even if the only "legitimate" way that is coded into the system requires a special privilege, and access to admin/jquery/update, so long as the operating system *ever* allows httpd or php to write to those directories, there's a potential vulnerability. Any minor bug then could become a critical exploit. So, as a precaution, the operating system itself (not Drupal's code) should enforce that Drupal can never write to the files that Drupal is trying to execute (either php source or .js that's sent to the browser). That way, even when future Drupal bugs are discovered, at least the operating system can help prevent those bugs from being exploited to cause significant damage.
I would be more concerned about image files that are binary in nature than I would about JS which is text. We allow ppl to upload images that could in fact execute code on the server side as well as the client side. All we can really do to prevent abuse is to make it as difficult as possible. But do we want to make it so difficult that it makes it nearly useless for some things? I do understand that allowing code executed from world open write directories to be executed on the server isn't something that we want to do. I don't understand why we wouldn't want to allow the administrator using the jquery_plugin module to upload the JS file via Drupal, activate it (something stored in the DB), change it to read only (only a minor precaution) and then use it to send to the client.
Hope that helps clarify,
Only somewhat. I've never been a cracker only a hacker. For me to fully understand I suppose I would need to involve myself with training in IT Security.
-Derek (dww)
p.s. If only shared hosting companies understood this. :( Sadly, most of them seem to run all of your httpd and php processes as the same user that owns all the files (presumably since that's easier and cheaper for them to manage, do accounting on, suspend your account when it uses "too many resources" etc). But, what's more profitable for the shared hosting provider is more dangerous for the customer. Ahh, the joys of capitalism.
Plus it makes it easier (requires fewer knowledgeable ppl) to deal with the ignorant public. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/