[development] jQuery 1.2 is released

[Earnie Boyd]

Quoting Derek Wright <drupal at 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/