Bug 484939 - text/plain no longer opens in the browser
text/plain no longer opens in the browser
Status: CLOSED NEXTRELEASE
Product: Bugzilla
Classification: Community
Component: Attachments/Requests (Show other bugs)
devel
All Linux
low Severity medium (vote)
: ---
: ---
Assigned To: David Lawrence
:
: 485329 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-10 14:20 EST by Adam Jackson
Modified: 2009-02-15 08:48 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-13 16:23:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Jackson 2009-02-10 14:20:16 EST
Description of problem:

text/plain attachments don't open in the browser.  Apparently it's a security setting?  I dunno, if we're not confident in the browser to do the right thing on text/plain I think we have larger issues.
Comment 1 Christopher Aillon 2009-02-10 16:30:22 EST
I've maintained many of our web browsers (Firefox, Netscape 4.x when we still shipped that, Mozilla, SeaMonkey, etc.) offered in Red Hat Enterprise Linux and Fedora, for nigh on 5 years for Red Hat, and several years prior to that working at Netscape.

I'm extremely curious to know what specific security issues we're concerned about, especially given the fact that the Mozilla guys (who just so happen to be the upstream for Bugzilla) have not disabled viewing attachments inline, and defects in the browser would impact customers.

If this is for an alternative (non-default) browser, might I suggest using browser detection for the specific browser, and then offering users of that browser a warning with an option to continue?

Feel free to respond directly to me via private e-mail.
Comment 2 David Lawrence 2009-02-10 16:57:30 EST
It was disabled until we can find a better way due to security problems with cross site scripting.

http://www.bugzilla.org/security/2.22.6/:

Vulnerability Details
=====================

Class:       Abuse of Functionality (Attachments)
Versions:    Every version before 2.22.7, 3.0.7, 3.2.1, or 3.3.2
Fixed In:    2.22.7, 3.0.7, 3.2.1, 3.3.2
Description: Bugzilla users can upload HTML or JavaScript attachments
             that are then viewed by other users in their web browsers.
             A malicious user could trick another Bugzilla user into
             viewing a malicious attachment that could then operate
             as that user. Since Bugzilla would view attachments
             using the same domain name as the rest of the application,
             such malicious attachments could access the cookies of
             the user and perform other activities usually restricted
             by the cross-site request protections of web browsers.

             Bugzilla now provides a two-fold solution to this problem:

             Bugzilla 2.22.7, 3.0.7, 3.2.1, and 3.3.2 now prevent
             users from viewing attachments in their browsers, by
             default. There is a new parameter named
             "allow_attachment_display" that administrators can enable
             to override this protection.

             Once this parameter is turned on, Bugzilla 3.0.7, 3.2.1,
             and 3.3.2 allow administrators to specify that attachments
             should be viewed using a different domain. This increases
             safety for the end user by enabling the browser's
             cross-domain request protections.

References:  https://bugzilla.mozilla.org/show_bug.cgi?id=38862
             https://bugzilla.mozilla.org/show_bug.cgi?id=472206

-----------
 

bugzilla.mozilla.org is able to go the alternative domain name route to continue to allow displaying of attachments where we could not do that here
due to our system configuration. We may start to allow displaying of specific attachment types such as text/plain but we need to make sure we can sanitize others first.

Dave
Comment 3 David Lawrence 2009-02-12 17:07:06 EST
*** Bug 485329 has been marked as a duplicate of this bug. ***
Comment 4 Hans de Goede 2009-02-12 17:38:42 EST
Can we please exempt text/plain starting yesterday? This is very very annoying and seriously disrupts our workflow.

For an example just look at bug 485331, which has 6! plain text attachments, this is not unusual for an anaconda bug and we have 200 open anaconda bugs!

We've regressed from:

click attachment -> see it

To:

click, save as dialog pops up, save, open texteditor, click on open
file, search file, click, see it

And that multiplied by 6 for just one bug!

Since browsers do not parse text/plain, but simply display it, their is no scripting here and thus also no cross site scripting.
Comment 5 Daniel Berrange 2009-02-13 09:40:22 EST
Please please exempt text/plain from this blocking ASAP. It makes bugzilla seriously unpleasant to use.
Comment 6 Christopher Aillon 2009-02-13 09:53:05 EST
This could be mitigated temporarily by setting 209.132.176.231 as the hostname of the attachment server.  Of course, anyone that visited bugzilla via the hostname would still be at risk, however, anyone that does is more likely to understand the risks of doing so.
Comment 16 David Lawrence 2009-02-13 16:23:54 EST
Changes committed to cvs and will be included in the next update (likely Mon Feb 16 earliest).

Note You need to log in before you can comment on or make changes to this bug.