Item11333: Attachments automatically appear under some conditions.

It appears that attachments with certain Meta information get automatically updated during view. Results in an extra attachment and metadata being added to the topic.

-- GeorgeClark - 06 Dec 2011

Babar identified it - it's the ImagePlugin that appears to be duplicating attachments, and updating topics with view.

-- GeorgeClark - 06 Dec 2011

The above link to an image, causes the attachment to appear. It would have been really helpful if the auto-attach code also added a comment "Auto-attached by the ImagePlugin".

-- GeorgeClark - 06 Dec 2011

Issue caused by {ImagePlugin}{AutoAttachExternalImages} being enabled on Foswiki.org. This has been disabled. It has copyright and spam implications as well as generating topic updates by WikiGuest and sending us searching for a security issue that was not an issue.

-- GeorgeClark - 06 Dec 2011

What exactly is this report about? It seems more like an accurate description of the auto-attach feature.

-- MichaelDaum - 06 Dec 2011

1. Babar, Sven and I spent some hours today chasing this as a security bug in 1.1.4RC
2. There is not a hint that this was being done by a plugin.
3. The "jpg" being attached is not an image
4. Not to mention significant copyright and spam abuse potential on an open site like here.
5. Did I mention we spent hours trying to understand how and why WikiGuest was attaching files to Foswiki.org
6. We kept deleting the files and they kept reappearing.

I guess an attachment comment would have made all the difference.

Update: Can you explain how this topic http://foswiki.org/Extensions/AttachContentPlugin?raw=debug has managed to attract the fruticans attachment. In this case the topic does not have the link, and it doesn't include a topic with the link. So maybe an fcgi related issue - failing to reset a variable? We disabled the AutoAttach function at Dec 6 18:25:19 2011 ... the attachment was added at 17:00.

-- GeorgeClark - 06 Dec 2011

Please have a look at ImagePlugin's configuration. There are a bunch of related settings, some of which you'd better switch off on foswiki.org.

# **BOOLEAN**
# Turn on/off downloading and mirroring of links to external images, e.g. http://some.external.site/avatar.jpg
$Foswiki::cfg{ImagePlugin}{RenderExternalImageLinks} = 1;

# **BOOLEAN**
# Turn on/off attaching a mirrored image to the current topic. If switched on 
# an attachment-record is generated for this image in addition to
# downloading the image. Attachments will be marked as hidden. Note, that any
# auto-attached image will update the topic and with it its timestamp.
$Foswiki::cfg{ImagePlugin}{AutoAttachExternalImages} = 1;

# **STRING**
# specifies a regular expession matching those urls that shall not be mirrored. They are
# handled by the core engine the standard way instead.
$Foswiki::cfg{ImagePlugin}{Exclude} = 'http://www.google.com';

# **BOOLEAN**
# Turn on/off attaching generated thumbnails to the current topic. 
$Foswiki::cfg{ImagePlugin}{AutoAttachThumbnails} = 0;

The main switch is RenderExternalImageLinks which will hook into the process of rendering external links. If that's a link to an image and when the link is not in the Exclude list, then it will be downloaded to .../pub/.... When the AutoAttachExternalImages is enabled these downloads will be attached properly as well.

So on foswiki.org: disable RenderExternalImageLinks to disable that feature.

RTFM?

-- MichaelDaum - 07 Dec 2011

I read the configuration and already switched some of it off. I don't need instructions to rtfm.

• Please consider adding a comment to the attachment, so that someone chasing down unexpected updates on a site has a hint from the topic meta that the ImagePlugin made the attachment
• There seems to be a fcgi / mod_perl reusability issue if topics without any external links, and without any includes for topics with external links are occasionally gathering attachments.
• And why was the particular html page that happened to have a jpg in it's filename being attached when it wasn't an image.

-- GeorgeClark - 07 Dec 2011

My two cents:

• I'm using ImagePlugin 2.40
• RTFM doesn't help when there is a bug (in my case Item11734 )
  • AutoAttachExternalImages attached an internal image (may be fixed in 2.41)
  • The topic to which the image was attached did not contain a mention of the image which was attached
  • The attached image does not appear in an IMAGE macro anywhere on the site.
• The attached image should not appear to have been uploaded by the visitor (especially when the visitor does not have upload access, as in f.o's case above)
  • The attachment should clearly show that it was uploaded by the ImagePlugin
  • It appeared to me to be a CSRF attack.
• Auto-attaching non-images is a security risk, as the attached image could really be a virus
• RTFM did not happen in my case.
  • I installed the ImagePlugin as a dependency of MediaWikiToFoswikiContrib .
  • I don't configure every plugin I install.
  • The brief description of ImagePlugin shown in configure/ExtensionsInstaller does not mention auto-attach or any of the other options which are on by default.

-- JayenAshar - 08 Apr 2012

Poking through ImagePlugin , I wonder if this could be related to the global variables $baseWeb $baseTopic . In a persistent environment (FCGI/mod_perl), could ImagePlugin::initPlugin be called on one topic and the next call to Foswiki::Render::_externalLink (overridden to call ImagePlugin::renderExternalLink) be called from a different topic?

-- JayenAshar - 08 Apr 2012

I suspect that in a persistent perl env, temporarily disabling ImagePlugin using a Foswiki Set variable, or the debugenableplugins URL param will be only partially effective. Once the monkey-patch is written to Render, it's there for keeps.

If the defaults can't be changed, this probably warrants a config checker that warns if (default) insecure settings are chosen. Warning the admin that auto-attaching external images can result in copyright violations and potentially loading less than desirable content on the server.

-- GeorgeClark - 08 Apr 2012

But what about when the plugin is never disabled? Could ImagePlugin::initPlugin be called on one topic and the next call to Foswiki::Render::_externalLink be called from a different topic? In my case, neither the topic nor uploaded image was being accessed at the time of the attachment. (The topic, however, was being navigated away from.)

-- JayenAshar - 08 Apr 2012

In fastcgi I'd say no, each fcgi handler has it's own address space. I'm not familiar enough with mod_perl to know for certain, but from what I can see, each process get's it's own global space unless it is specifically initialized during the server startup in startup.pl

-- GeorgeClark - 09 Apr 2012

Could Foswiki::Render::_externalLink be called on an image which is not being rendered, and could it be called before/without calling ImagePlugin::initPlugin? Maybe not in bin/view, but in bin/search or bin/kinosearch? Do you have the web server log of what bins were being accessed at 06 Dec 2011 - 17:00 (when fruticans was attached to Extensions.AttachContentPlugin)? Was bin/search/Extensions/AttachContentPlugin being accessed, by any chance?

-- JayenAshar - 09 Apr 2012

We did quite a bit of searching of the logs and didn't find any particular correlations at the time. So I'm not sure what is wrong, but I'm concerned that this plugin is enabled on foswiki.org at all. With the monkey-patching of Render.pm, it means our "Release candidate" is not actually using the core render code.

-- GeorgeClark - 09 Apr 2012

I've disabled the {RenderExternalImageLinks} option. That should restore the core render code so that we are running the real release candidate.

-- GeorgeClark - 09 Apr 2012

If there is more than one problem, then it becomes exponentially difficult to find correlations. Could you post (or send me directly) some logs from when fruticans was attached to Extensions.AttachContentPlugin? Specifically, I'm interested in seeing the foswiki log with anything at that time (and slightly earlier) containing (WikiGuest, upload, AttachContentPlugin, File:Nypa_fruticans_Blanco2.386-cropped.jpg, dontlog) or maybe just AttachContentPlugin. And the web server log with anything at that time (and slightly earlier) containing AttachContentPlugin. Thanks.

-- JayenAshar - 09 Apr 2012

Here are the event logs from around the upload of that file.

| 2011-12-06T09:19:32Z info | guest | view | Development.AddRemoveFileFeatureToManifest | Mozilla | x.x.x.x |
| 2011-12-06T09:19:34Z info | guest | view | Sandbox/PadraigLennon.TeamCalendarAppViewTemplate | Mozilla | x.x.x.x |
| 2011-12-06T09:19:38Z info | guest | view | Sandbox/PadraigLennon.TeamCalendarAppViewTemplate | Mozilla | x.x.x.x |
| 2011-12-06T09:19:38Z info | guest | view | Development.ChangeImageLinkBehaviour | Mozilla | y.y.y.y |
| 2011-12-06T09:19:39Z info | guest | upload | Development.ChangeImageLinkBehaviour | File:Nypa_fruticans_Blanco2.386-cropped.jpg, dontlog Mozilla | y.y.y.y |
| 2011-12-06T09:19:40Z info | guest | view | Extensions.WebHome | Firefox | x.x.x.x |
| 2011-12-06T09:19:40Z info | guest | view | Development.WebHome | Firefox | x.x.x.x |
| 2011-12-06T09:19:42Z info | guest | view | Sandbox/PadraigLennon.TeamCalendarAppViewTemplate | Mozilla | x.x.x.x |
| 2011-12-06T09:19:43Z info | guest | view | Tasks.Item8317 | Mozilla | x.x.x.x |
| 2011-12-06T09:19:44Z info | guest | view | Extensions.TwistyPlugin | Mozilla | x.x.x.x |
| 2011-12-06T09:19:46Z info | guest | view | Sandbox/PadraigLennon.TeamCalendarAppViewTemplate | Mozilla | x.x.x.x |
| 2011-12-06T09:19:49Z info | guest | view | Development.CleanUpNewUserTemplate | Mozilla | x.x.x.x |

-- GeorgeClark - 10 Apr 2012

I see TeamCalendarAppViewTemplate has the attachment, too. It would be good to see the web server log corresponding to the 2011-12-06T09:19:39Z line. In my case, it was a bin/kinosearch, which doesn't show up in the foswiki event log.

-- JayenAshar - 10 Apr 2012

I'm using Foswiki 1.1.5 (plus mod_fcigd) and ImagePlugin 2.41 and have RenderExternalImageLinks, AutoAttachExternalImages & AutoAttachThumbnails all disabled and am still getting extra copies of attached files generated on every page view. This is a real problem as it's requiring lots of clean up.

-- LynnwoodBrown - 01 May 2012

Commenting is disabled while not logged in