I generally agree that we should try and come up with ways that are
safer than just opening code trees up for modifications, and that
some safer process (perhaps a handshake with a cron job that could
run as a different user and pull plugins) would be a better
approach. It's always bothered me a little that cron.php is an
exposed unauthenticated admin process.
But I also agree with the concept that jQuery plugins aren't the same
as PHP code., cause they don't execute server side.
Whether we like it or not, there is some precedent for writing "core
files" into the system files path and letting clients download it
from there.
Not that I'm advocating this approach mind you, but the Theme
Developer module writes tpl files and css files into the "files" path
and then lets people execute code server side from that path, and
even drupal core rewrites css files and image files into the systems
files path. You could perhaps argue that these aren't code, but I
just was sort of pointing out that that it does meet the definition
of core files, even though it ain't code. Food for thought: Would we
eliminate support for flash uploads because flash gets used for
client side coding as well? Hmm...
I also wanted to point that out so that we don't al get a false sense
of security regarding code that uploads files. If I can get a module
to upload code (through a bug) into the files path, then I can still
leverage that code in really nasty ways. In other words just cause
we're not uploading files to the modules directory doesn't mean we've
protected ourselves from php file upload vulnerabilities. All code
that contains the ability to update files on a server needs close
scrutiny.
Just trying to share a different perspective (I can argue both sides
of any issue :) and do more often than not).
On Sep 13, 2007, at 6:11 PM, Derek Wright wrote:
>
> 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.
>
> 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.
>
> 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.
>
> Hope that helps clarify,
> -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.
>
>
>