[wp-hackers] Security considerations for the WP 2.7 plugin installer

[DD32]

Hiya,
First, Let me introduce myself as DD32, or Dion, I'm the one who's been  
writing the installer as part of a Google Summer of Code project, I do not  
anticipate that it'll be finished by the end of the GSOC timeline, however  
it'll be polished for 2.7 release, The Code has been commited to get it  
out there earl in the dev cycle to get feedback, and allow a decent  
ammount of time to be given to ironing out any issues, bugs, security  
implications, or otherwise.

Posting this to the Trac ticket would've been more appropriate IMO at this  
point of development too.

Yes, At present its assumed that the data returned from Wordpress.org has  
been sanitized, And while plugins on wordpress.org get checked if they're  
mearly spam, ongoing checks do not get performed, So checking that the  
data is not malformed does need to be added in some places, I should point  
out its currently a work in progress, I have a few major changes which  
i've not yet submitted to Trac.

So Yes, That line you pointed out needs to use attribute_escape() to  
ensure it cant insert any other HTML for example
However, There is also the more prominent issue of plugins conaining rogue  
php code, which is going to be more dangerous than meta data containing  
malformed html

I do not feel that Linking to the homepage from within WordPress is a  
security implication, Rather something which the user is going to expect,  
The user may want to give the authors homepage(or the plugins homepage) a  
squiz before deciding they trust the plugin.
The WordPress.org page links to the authors homepage, and so does the  
Plugins page inside wordpress for installed plugins, Its simply too much  
to expect Someone to Veto every link and page mentioned by a plugin every  
day, People need to use common sense when browsing the internet.

An extra function on wordpress.org to report a plugin as "bad" and  
including a reason could be a step forward for future if huge issues  
arrise or if a plugin slips through the initial screening process, There's  
not a huge ammount of people who currently screen plugins (Theres a reason  
it takes 2 weeks for a plugin to be allowed through sometimes) - And i  
know a fair few pure spam plugins get knocked back. Because as i said, Its  
impossible for someone to check all the links 24/7.



On Wed, 13 Aug 2008 15:04:14 +1000, Robert Wetzlmayr  
<r.wetzlmayr at gmail.com> wrote:

> Dear all,
>
> when rendering a result from a plugin search in the new plugin
> installer, display_plugins_table() injects a link to an URL retrieved
> from the plugins meta data (@see
> http://trac.wordpress.org/browser/trunk/wp-admin/includes/plugin-install.php?rev=8630#L207).
>
> As up to this point there's no established level of trust between the
> consuming WP site and the plugin homepage URL, I wonder why this
> injection is deemed appropriate with respect to potential privacy and
> security implications.
>
>> From my understanding, the WP plugin repository is at least at present
> not thoroughly screened for potential malware or abusive content at
> plugins' homepages, so this deliberate linking might impose all kinds
> of threats. Please understand that I am particularly concerned with
> the presentation of search results. Any other plugin listing employs
> "trusted" plugins which are at least installed on the target site.
>
> Payloaded WordPress plugins already are a common SEO tactic (@see
> http://www.anty.info/2008/08/06/pingcrawl-injects-links/), and I
> wonder how long it would take before one would social-engineer
> unsuspecting WP 2.7 users as an easy prey for a plugin with
> "behind-the-scenes" functionality.
>
>
> Cheers,
>
> Robert 'wet' Wetzlmayr
>