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.ph
p.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/
|
