[wp-hackers] Advertising on plugin pages

Heiko Rabe heiko.rabe at code-styling.de
Mon Mar 2 01:34:19 GMT 2009


I know that. But it's the same problem autoupdate of WordPress have had 
this times:
 - the images written by the script running user which is not the FTP 
user but wwwrun (server) gets the wrong ownership and rights.
Afterwards you can't access the image nor delete it using FTP clients.
It may solve the scriptcode issue but won't work, if you dont write the 
image using appropriated FTP user (FTP classes) to the domains space.
Many providers running scripts not at context of FTP user, so you have 
to deal with this too.

The most important thing is security of blogs. All what have been 
written to this ads subject is highly security critical.
I want to have a secure environment and i don't see, how this can be 
permitted easy if plugins massively starting to load secondary content 
from elsewhere.
The advertising itself is not the main problem, security and reliability 
are the things to be keeped always.
So if you state at you plugins download agreement, that any spam and/or 
intrusion damage forcing a profit loss to me, verifiably logged to your 
plugin as source, will be incured by your service company, i would 
install it.
I think, without any "trust center" and verified ads provider this is 
not a good idea.

regards

Heiko Rabe
(http://www.code-styling.de)

> Yeah, but there's an easy fix for this given the proposed implementation for this use-case:
>
>    $image = imagecreatefromjpeg('suspect_file.jpg');
>    @imagejpeg($image,'safe_file.jpg',100);
>    unlink('suspect_file.jpg');
>
> If it is a "bad" file, you'll just get a black image.
>
> -Mike Schinkel
> http://mikeschinkel.com/
>
> ----- Original Message -----
> From: "Heiko Rabe" <heiko.rabe at code-styling.de>
> To: wp-hackers at lists.automattic.com
> Sent: Sunday, March 1, 2009 7:23:51 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [wp-hackers] Advertising on plugin pages
>
> So let me reference a german IT magazin. They have also a security 
> related section and this is a link to an acticle out of: 
> http://www.heise.de/security/Risiko-durch-MIME-Sniffing-im-Internet-Explorer--/artikel/122187
> english translated Subject: MIME Sniffing at IE Image Content and 
> execution of embedded javascripts!
> At the end of article you will find 3 links with prepared demo images 
> that execute javascript code embedded into images if viewed by Internet 
> Explorer.
> If such a script out of the image will be executed in backend of 
> WordPress, it can use the already loaded jQuery and infrastructure to 
> modify a lot of page content inside the database using ajax interface or 
> xmlrpc by javascript driven ajax posts. So an image is enough to 
> compromize the blog, serving frontend pages with hacked content and 
> viagra links amd much more.
>
> This is an easy attack vector if you remember, that Microsoft browser is 
> the most used browser and doesn't get fixed at all. Companies sometimes 
> are foced to use IE6 because their applications won't run any longer at 
> higher versions.
> With this short and easy scenario shown it is not so easy to state "hey, 
> what can an image do for damage ?".
>
> regards
>
> Heiko Rabe
> (http://www.code-styling.de)
>   
>> So would you see a hard-coded .JPG ad including with a plugin as a problem? Joost could do that and I don't see any way it would be a security problem.
>>
>> Also, is contacting 3rd party servers a problem?  Does that mean that plugins that contact Twitter or Flickr are a problem (probably not, those are well known services.) But what about a less-well known service? Where does it become "no longer okay?"  To me, it's when the 3rd party server have bad intentions, not the fact it is a 3rd party server.
>>
>>   
>>     
>>> Normally no plugin needs 3rd party server calls 
>>>     
>>>       
>> Maybe in the past, but as the web evolves there will be more and more demand for this as the value of interacting with 3rd party web services grow. 
>>
>>   
>>     
>>> And if the 3rd party server has been hacked, all plugin using domains 
>>>     
>>>       
>> will be virulent infected too. 
>>
>> Not necessarily.  It all depends on what that plugin does when it contacts the 3rd party server. If all it ever does is download a JPG, please tell me how that can be a problem (besides presenting a porn ad, LOL!) 
>>
>> Not all circumstances are created equal.
>>
>>   
>>     
>>> Also a DNS spoofing attack can route the advertising calls to an evil server and serves now real "bullshit".
>>>     
>>>       
>> And a DNS spooking attack and also serve someone else's website. You are presenting unlikely hypotheticals that require many other things to be wrong too.
>>
>>   
>>     
>>> This is not longer under control of blog admins and what you think will 
>>>     
>>>       
>> happen, if your plugin is the source of lost revenues of high traffic 
>> installations by attacks ? What you think, their lawyer will do ?
>>
>> You are making a lot of assumptions that the plugin author will do lot of things very wrong. Just as with SQL injection attacks, there are best practices to follow to avoid the problems.
>>
>> All I'm saying is let's not throw the baby out with the bathwater.
>>
>> -Mike Schinkel
>> http://mikeschinkel.com/
>>
>> ----- Original Message -----
>> From: 
>> To: wp-hackers at lists.automattic.com
>> Sent: Sunday, March 1, 2009 6:33:30 PM GMT -05:00 US/Canada Eastern
>> Subject: Re: [wp-hackers] Advertising on plugin pages
>>
>> The main difference is, that normal plugins won't load code, images or 
>> something else from 3rd party servers.
>> And yes, i review each plugin and theme i plan to use.
>>
>> Sure, every plugin can do "bad" things, but if i have a plugin in test, 
>> that prominent shows me loaded 3rd party things, i will first of all 
>> deactivate it and inspect it more carefully as i would do with others.
>> Also i have a service plugin running which scanns each other plugins php 
>> pages for unknown fopen, fetch_rss and many more remote call funtions 
>> reported at dashboard, if unknown.
>>
>> Normally no plugin needs 3rd party server calls (except those intended 
>> to work so like akismet, content importer or known defined things).
>> I don't expect remote calls in plugins like smiley replacer but you want 
>> introduce 3rd party calls for this too.
>>
>> And if the 3rd party server has been hacked, all plugin using domains 
>> will be virulent infected too. Also a DNS spoofing attack can route the 
>> advertising calls to an evil server and serves now real "bullshit".
>> This is not longer under control of blog admins and what you think will 
>> happen, if your plugin is the source of lost revenues of high traffic 
>> installations by attacks ? What you think, their lawyer will do ?
>>
>> regards
>>
>> Heiko Rabe
>> (http://www.code-styling.de)
>>
>>   
>>     
>>> "Heiko Rabe" <heiko.rabe at code-styling.de> wrote:
>>>   
>>>     
>>>       
>>>> You will run into the fact that developers will disassemble 
>>>> the entire plugin code to be sure, nothing unwanted will be 
>>>> transmitted. Such time wasting effort would force me to drop 
>>>> such a plugin and search for an ad free solution or to rewrite 
>>>> it without ads.
>>>>     
>>>>       
>>>>         
>>> ANY plugin could do something unsavory. All the things you mention could be done by a plugin that is not advertising-related, and also a plugin that is advertising-related could avoid all those things so as to be a good citizen. Do you code review every plugin you use (which is probably a good idea, but tangential to the discussion?)  How does this make plugins that serve advertising different?
>>>
>>> -Mike Schinkel
>>> http://mikeschinkel.com/
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>
>>>   
>>>     
>>>       
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>>   
>>     
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>   



More information about the wp-hackers mailing list