https://bugzilla.wikimedia.org/attachment.cgi?id=12517&action=edit

shows

"The attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator.

In order to view the attachment, you first have to download it."

However the type is definitely listed as image/png ...

https://bugzilla.wikimedia.org/editparams.cgi?section=attachment shows that allow_attachment_display is set to "off".

Did someone turn it off perhaps by accident?

Ok mutante turned it back on; the links now forward as in to http://bug-attachment.wikimedia.org/attachment.cgi?id=12517 Yay!

Yea, just switched that back on. Andre__ do you know about this? I can't seem to find it in audit log either, just components and users being created etc..

I intentionally set it to Off. This is unfortunately not logged in the audit log. Reverting the revert and WONTFIXing.
See bug 51839 comment 10 for background.

As allow_attachment_display says, "This is a security restriction for installations where untrusted users may upload attachments that could be potentially damaging if viewed directly in the browser."
Which is the case for Wikimedia Bugzilla.
RedHat Bugzilla also uses Off, and to my surprise Mozilla Bugzilla uses On.

The fact that Bugzilla also blocks displaying PNG attachments etc (no filtering on MIME types possible, as far as I know) might be worth an upstream ticket. If the world agreed that PNGs are safe.

Reopening bug, as this is a serious usability issue.

So, am I correct in my understanding that this alleged security issue would be instantly resolvable by changing "bug-attachment.wikimedia.org" to "bug-attachment-wikimedia.org" or such?

As an alternative, we could patch the attachment shower script to whitelist image/png, image/jpg, and image/gif for inline viewing. This would resolve the vast majority of the inconvenience.

(In reply to comment #7)

As an alternative, we could patch the attachment shower script to whitelist
image/png, image/jpg, and image/gif for inline viewing. This would resolve
the
vast majority of the inconvenience.

Depending on what making them appear inline would entail, this could be problematic with some larger images, but whatever the case something needs to be done.

(In reply to comment #5)

See bug 51839 comment 10 for background.

This bug is restricted from viewing.

I'm not sure what's different between bug-attachment.wikimedia.org and upload.wikimedia.org in terms of serving PNGs.

Is there a workaround for this stupidity? It's making Bugzilla attachments painful to view.

(In reply to comment #10)

Is there a workaround for this stupidity? It's making Bugzilla attachments
painful to view.

+1. I am open to installing greasemonkey to use some script as workaround. Currently I just don't open any attachment because it's too tedious.

This is ridiculous.

Any news on this from BZ Adkins?

(In reply to comment #13)

Any news on this from BZ Adkins?

That's me. No news. As ther underlying issue is not a BZ-only problem, somebody should discuss the general way to go in bug 51839.
Let me try to find out what upstream BZ devs think about this.

(In reply to comment #7)

As an alternative, we could patch the attachment shower script to whitelist
image/png, image/jpg, and image/gif for inline viewing. This would resolve
the vast majority of the inconvenience.

Whoever feels like understanding code, search for "contenttype" and "allow_attachment_display" in

http://bzr.mozilla.org/bugzilla/4.2/view/head:/attachment.cgi
http://bzr.mozilla.org/bugzilla/4.2/view/head:/template/en/default/attachment/edit.html.tmpl

For example see the check for

attachment.contenttype == "text/html"

in edit.html.tmpl

Maybe after this line:

my $disposition = Bugzilla->params->{'allow_attachment_display'} ? 'inline' : 'attachment';

Add something like this?

if ($contenttype =~ /^image\/(png|gif|jpeg)$/) {
  // If a PNG, GIF, or JPEG is going to break your browser
  // you have much, much bigger problems.
  //
  // Note that some really old versions of IE could misdetect PNG images
  // as HTML, but if you're using IE 5.5 for your modern web development
  // that's kinda your problem. ;)
  $disposition = "inline";
}

(In reply to comment #5)

RedHat Bugzilla also uses Off, and to my surprise Mozilla Bugzilla uses On.

To be perfectly frank, folks in bugzilla generally know how to handle these things anyway, which might explain that.

This whole bug confuses me, though - forcing download seems like it'd be MORE of a security issue than viewing in-browser, not less, since then the file goes through at least two more layers of handling where it could encounter/trigger vulnerabilities - the OS reading it to figure out where to send it, and wherever it sends it. Which in the case of some versions of Windows would mean that any executable file could easily be automatically executed, from what I understand.

(In reply to comment #15)

I love you.

(In reply to comment #15)

I was fiddling around in the same code area, but real developers are just faster than me reading my Perl programming book in parallel. Thanks Brian!!

I applied your three lines on boogs.wmflabs.org (which has the same attachment admin settings like bugzilla.wikimedia.org) and filed a test report with some attachments in http://boogs.wmflabs.org/show_bug.cgi?id=13

And it works! Yay!

Next step is to create a patch for https://git.wikimedia.org/summary/wikimedia%2Fbugzilla%2Fmodifications.git but that's stuff for tomorrow (it's getting late here in Europe).

Awesome -- I didn't test it so glad it worked. :DDD

Change 90546 had a related patch set uploaded by Aklapper:
Work around access restriction for image attachments

https://gerrit.wikimedia.org/r/90546

More complicated due to IE's MIME sniffing, as csteipp pointed out in Gerrit (thanks!):

http://msdn.microsoft.com/en-us/library/ms775147.aspx
http://www.adambarth.com/papers/2009/barth-caballero-song.pdf

Some test cases (taken from heise.de):

File extension = PNG, content type = image/png, file signature = PNG
http://www.heise.de/security/dienste/browsercheck/demos/ie/msniff/security_logo_en.png

File extension = JPG, content type = image/png, file signature = PNG
http://www.heise.de/security/dienste/browsercheck/demos/ie/msniff/security_logo_en.jpg

File extension = BMP, content type = image/bmp (but should be image/x-ms-bmp instead), file signature = BMP
http://www.heise.de/security/dienste/browsercheck/demos/ie/msniff/security_logo_en.bmp

We should probably send the header that disables IE's mime type sniffing.

I really don't care if IE 6 or something remain vulnerable with PNGs, when there's perfectly modern versions available... :)

(In reply to comment #21)

We should probably send the header that disables IE's mime type sniffing.

Since 4.2.4 we send "X-Content-Type-Options: nosniff" with every response. See http://bzr.mozilla.org/bugzilla/4.2/revision/8136

What's needed to get this setting put back to the way it was for years?

I'm experiencing this problem on Google Chrome as well.

What's needed to get this setting put back to the way it was for years?

Either fixing bug 51839, or a patch for Bugzilla code which includes CSteipp's recommendations on https://gerrit.wikimedia.org/r/90546 (could be tested with IE against links in comment 20).

Chris: in which versions of IE is this an issue?

Only IE 7 and below are affected, if I'm not mistaken; IE 8 and later either will obey the "don't try to sniff file types" header we send, or don't do the stupid sniffing in the first place.

Note that every version of Windows that supported IE 7 now supports IE 8 (released over four years ago) or later.

(In reply to comment #28)

Only IE 7 and below are affected, if I'm not mistaken; IE 8 and later either
will obey the "don't try to sniff file types" header we send, or don't do the
stupid sniffing in the first place.

Note that every version of Windows that supported IE 7 now supports IE 8
(released over four years ago) or later.

How about we block IE7 and below, then, on security grounds, and invite the browser's manufacturer to provide a patch? ;-) Their use is tiny, and the trouble they're causing is not worth it on balance.

Is there a workaround for this issue?

No.

What's the plan for this bug?

My personal plan is to ignore this report until I've finished stuff that currently has higher priorities for me. I also want to see what upstream does with regard to the underlying issue that led to this settings change. Patches might speed up fixing this problem (see comment 26).

(In reply to comment #30)

Is there a workaround for this issue?

I can find a few extensions of Firefox to rewrite Content-Disposition headers.

(In reply to comment #34)

I can find a few extensions of Firefox to rewrite Content-Disposition
headers.

So everyone should install e.g. https://addons.mozilla.org/en-us/firefox/addon/inlinedisposition/? Is there one which can be enabled per-site? Once we find a workaround, it has to be added to [[mw:Bugzilla]].

There's also https://chrome.google.com/webstore/detail/modify-content-type/jnfofbopfpaoeojgieggflbpcblhfhka for Chrom(e|ium) but that's even too flexible. If someone tests it and finds a good rule for bugzilla, please share.

Created attachment 13980
Special version for bug-attachment.wikimedia.org

So a slightly hacked version attached.

diff --git a/components/inlinedisposition.js b/components/inlinedisposition.js
index b13a4c1..3552eb2 100644

• a/components/inlinedisposition.js

+++ b/components/inlinedisposition.js
@@ -147,7 +147,9 @@ var InlineDispositionService =

        disp = chan.getResponseHeader("Content-Disposition");
} catch (e) { }

• if (chan.loadFlags & Components.interfaces.nsIChannel.LOAD_DOCUMENT_URI && this._re.test(disp))

+ if (chan.loadFlags & Components.interfaces.nsIChannel.LOAD_DOCUMENT_URI
+ && chan.getRequestHeader("Host") == "bug-attachment.wikimedia.org"
+ && this._re.test(disp))

                chan.setResponseHeader("Content-Disposition", disp.replace(this._re, "inline"), false);
}

Attached:

(In reply to comment #37)

Created attachment 13980 [details]
Special version for bug-attachment.wikimedia.org

So a slightly hacked version attached.

Hurray! I've linked it from [[mw:Bugzilla]].

Attached:

(In reply to comment #26)

Either fixing bug 51839, or a patch for Bugzilla code which includes
CSteipp's recommendations on https://gerrit.wikimedia.org/r/90546 (could be
tested with IE against links in comment 20).

Please add me to bug 51839.

(In reply to comment #39)

Please add me to bug 51839.

I guess the reply needs to be "Please sign an NDA first". :-/

Actually, why is bug 51839 still hidden when the immediate issue, whatever it was, was apparently fixed by the workaround being discussed here?

(Also, if that bug is just about the fact that serving user-provided files with user-provided MIME types from the same domain as your normal site, then that's hardly news.)

*(Also, if that bug is just about the fact that serving user-provided files with user-provided MIME types from the same domain as your normal site is a bad idea, then that's hardly news.)

• Bug 58448 has been marked as a duplicate of this bug. ***

<tl;dr> Scroll to last paragraph.

General info on differences between testing and production:

Production Bugzilla has attachment_base set (bug-attachment.wikimedia.org) which is not the case on Labs, hence testing situation is not the same. Plus I wonder why Labs does not display any sidebar & wrong CSS style in IE. Grmpf.

Testing:

Using IE8 on XP SP3 in compatibility mode on boogs.wmflabs.org with allow_attachment_display=Off and...

1) https://gerrit.wikimedia.org/r/#/c/90546/4/ not applied and my previous naive attempt applied by adding the three lines

if ($contenttype =~ /^image\/(png|gif|jpeg)$/) {
        $disposition = "inline";
}

in attachment.cgi:395, which makes Bugzilla behave as if allow_attachment_display was set to "On" for files with mimetypes GIF/JPG/PNG,

• GIF/JPG/PNG standard images with correct mime types in http://boogs.wmflabs.org/show_bug.cgi?id=13#c1 to #c3 are directly displayed in the browser without warning (due to hack above).
• HTML/JS attachment in http://boogs.wmflabs.org/show_bug.cgi?id=13#c4 asks if it should be opened before its JS is executed.
• Broken "image" files (which contain HTML): http://boogs.wmflabs.org/show_bug.cgi?id=13#c5 and #c6 display a red 'broken' icon (same as FF26) and #c7 (BMP) asks to open an application.

2) https://gerrit.wikimedia.org/r/#/c/90546/4/ not applied && after removing the three custom lines in 1),

• GIF/JPG/PNG standard images with correct mime types in http://boogs.wmflabs.org/show_bug.cgi?id=13#c1 to #c3 ask to open an application.
• HTML/JS attachment in http://boogs.wmflabs.org/show_bug.cgi?id=13#c4 asks if it should be opened before its JS is executed.
• Broken "image" files (which contain HTML): http://boogs.wmflabs.org/show_bug.cgi?id=13#c5 to #c7 ask to open an application.

3) https://gerrit.wikimedia.org/r/#/c/90546/4/ applied:

• GIF/JPG/PNG standard images with correct mime types in http://boogs.wmflabs.org/show_bug.cgi?id=13#c1 to #c3 are directly displayed in the browser without warning (due to Gerrit patch).
• HTML/JS attachment in http://boogs.wmflabs.org/show_bug.cgi?id=13#c4 asks if it should be opened before its JS is executed.
• Broken "image" files (which contain HTML): http://boogs.wmflabs.org/show_bug.cgi?id=13#c5 to #c7 ask to open an application.

Hence patch in https://gerrit.wikimedia.org/r/#/c/90546/4/ seems to work as expected.

Change 90546 merged by Dzahn:
Work around access restriction for image attachments

https://gerrit.wikimedia.org/r/90546

deployed on kaulen , feel free to test

Created attachment 14280
bugzilla logo to test png attachments

Attached:

see the PNG i added, i see it in browser, not dowload:

http://bug-attachment.wikimedia.org/attachment.cgi?id=14280

now we just need a new version of this patch against attachment.cgi from BZ 4.4

and that we have now. https://gerrit.wikimedia.org/r/#/c/106713/ so on 4.4 we'll just merge that and all is good on this bug

A huge thanks to Daniel, Chris, Brion, and Andre for working on this. I just uploaded attachments to bug 59957 without the uncomfortable feeling that viewing them would be painful and annoying. \o/

In the last few days I'm again seeing this problem (Firefox 26 and Chromium 32). Liangent's version of the Firefox extension (comment 37) doesn't work either.

Can not reproduce.

Well, I remember seeing this at least once in the last week.

I mean this:

(In reply to comment #1)

https://bugzilla.wikimedia.org/attachment.cgi?id=12517&action=edit

shows

"The attachment is not viewable in your browser due to security restrictions
enabled by your Bugzilla administrator.

MatmaRex confirms this is the case for him still too, though opening https://bugzilla.wikimedia.org/attachment.cgi?id=12517 works. The attachment detail pages is what email notifications link. Should this part be split to another report?

https://bugzilla.wikimedia.org/show_bug.cgi?id=49440 links to https://bugzilla.wikimedia.org/attachment.cgi?id=12517 in the first item in the "Attachments" table which redirects to http://bug-attachment.wikimedia.org/attachment.cgi?id=12517 in Firefox 26, and that opens the PNG image for me in the browser.

Need steps to reproduce.

(In reply to comment #56)

https://bugzilla.wikimedia.org/show_bug.cgi?id=49440 links to
https://bugzilla.wikimedia.org/attachment.cgi?id=12517 in the first item in
the
"Attachments" table which redirects to
http://bug-attachment.wikimedia.org/attachment.cgi?id=12517 in Firefox 26,
and
that opens the PNG image for me in the browser.

Need steps to reproduce.

Click on "Details" near "screenshot of simulator with huge image", you're sent to https://bugzilla.wikimedia.org/attachment.cgi?id=12517&action=edit . There should be an iframe displaying the attachment on this page if this bugzilla is configured as expected, but it now says "The attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator." instead.