Firefox should honor Content-Type instead of Content-Encoding or extension

NEW
Unassigned

Status

()

Firefox
File Handling
--
major
12 years ago
11 months ago

People

(Reporter: Vincent Lefevre, Unassigned)

Tracking

(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

According to wget, the headers for the above URL are:

  Content-Type: application/postscript
  Content-Encoding: x-gzip

But when I try to open it with Firefox, it says that it is a Gnu ZIP Archive instead of taking into account the Content-Type header.

Reproducible: Always

Steps to Reproduce:
1. Open the above URL.
Actual Results:  
Firefox says:

You have chosen to open
TI-97-7.ps.gz
which is a: Gnu ZIP Archive
from: http://www.informatik.tu-darmstadt.de

Expected Results:  
It should have said that it was a Postscript file.

I wonder is this can lead to a security problem if a wrong helper application can be used.

Comment 1

12 years ago
The type displayed by Firefox is indeed from the extension, but the *behaviour* of Firefox comes (initially at least) from the Content-Type.
ohh, content-encoding issues in file handling
Assignee: darin → file-handling
Component: Networking: HTTP → File Handling
QA Contact: networking.http → ian
(Reporter)

Comment 3

12 years ago
(In reply to comment #1)
> but the *behaviour* of Firefox comes (initially at least) from the Content-Type.

Not completely. Firefox proposes to open the file with Stuffit Expander, which is a dearchiver, not a viewer.

Comment 4

12 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060110 Firefox/1.5

Is this bug Mac OS X only? At least here on Linux (1.8 branch build) I see the correct file type in the download dialog (postscript file) and it offers to open the file in my selected PS viewer application.
(Reporter)

Comment 5

12 years ago
I confirm that it is correct under Linux:

You have chosen to open
  TI-97-7.ps.gz
which is a: PS file
from: ...
So is this an issue with Seamonkey too?  Or just Firefox?  And a problem with just the UI?  Or the core code?

More precisely, what does a NSPR_LOG_MODULES=HelperAppService:5 show in this case?
(Reporter)

Comment 7

12 years ago
(In reply to comment #6)
> More precisely, what does a NSPR_LOG_MODULES=HelperAppService:5 show in this
> case?

-1610551960[1b06ce0]: Found extension 'gz' (filename is 'TI-97-7.ps.gz', handling attachment: 0)
-1610551960[1b06ce0]: HelperAppService::DoContent: mime 'application/postscript', extension 'gz'
-1610551960[1b06ce0]: Getting mimeinfo from type 'application/postscript' ext 'gz'
-1610551960[1b06ce0]: Mac: HelperAppService lookup for type 'application/postscript' ext 'gz' (IC: 0x1e24960)
-1610551960[1b06ce0]: OS gave us: By Type: 0x0 By Ext: 0x6d10060 type has default: false
-1610551960[1b06ce0]: OS gave back 0x6d10060 - found: 1
-1610551960[1b06ce0]: Data source: Via type: retval 0x80040111
-1610551960[1b06ce0]: Data source: Via ext: retval 0x00000000
-1610551960[1b06ce0]: Extension 'gz' matches mime info: 1
-1610551960[1b06ce0]: MIME Info Summary: Type 'application/postscript', Primary Ext 'gz'
-1610551960[1b06ce0]: Type/Ext lookup found 0x6d10060
-1610551960[1b06ce0]: Getting mimeinfo from type 'application/postscript' ext '.gz'
-1610551960[1b06ce0]: Mac: HelperAppService lookup for type 'application/postscript' ext '.gz' (IC: 0x1e24960)
-1610551960[1b06ce0]: OS gave us: By Type: 0x0 By Ext: 0x5161870 type has default: false
-1610551960[1b06ce0]: OS gave back 0x5161870 - found: 1
-1610551960[1b06ce0]: Data source: Via type: retval 0x80040111
-1610551960[1b06ce0]: Data source: Via ext: retval 0x80040111
-1610551960[1b06ce0]: Extension '.gz' matches mime info: 0
-1610551960[1b06ce0]: MIME Info Summary: Type 'application/postscript', Primary Ext 'gz'
> -1610551960[1b06ce0]: Getting mimeinfo from type 'application/postscript' ext
'gz'
> -1610551960[1b06ce0]: Mac: HelperAppService lookup for type
'application/postscript' ext 'gz' (IC: 0x1e24960)
> -1610551960[1b06ce0]: OS gave us: By Type: 0x0 By Ext: 0x6d10060 type has
default: false

Hmm...  So your OS knows nothing about application/postscript in this case.

biesi, we should probably not do the extension lookup, or modify it, when we're decompressing and the extension is just the content-encoding.  What do you think?

Comment 9

12 years ago
Doing so would probably fix bug 229871 (a similar issue) as well.

And this bug depends on bug 132702, I think.
This could be done independently of bug 132702, I think.

But yeah, bug 229871 is very much related (possibly to the point of being a dup).
Depends on: 229871

Comment 11

12 years ago
Well, until bug bug 132702 is fixed, we pass the compressed file to the helper application. So currently, offering to open in Stuffit Expander actually sort of makes sense. If this bug is fixed to offer the user to open the document in the Preview application (or any other app capable of viewing PostScript), the helper app will - rightly - complain that the (still compressed) file is not a PostScript file. That's why I think fixing this bug without fixing bug 132702 as well will make things actually worse than they are now.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Reporter)

Comment 12

12 years ago
I wonder if there could be a security problem by not honoring strictly the Content-Type, in particular if the user chooses alternate helper applications. For instance, the user could have a filter (provided by a local proxy or whatever) based on the Content-Type, but then, since the Content-Type is not honored, the file will be passed to a different application, for which there may be more risks. And the filter corresponded to this application was not executed because the Content-Type corresponds to another helper application.

If this bug isn't fixed yet, the browser should make sure that, for instance in the case of a file ending with .gz, the file is really a gzipped one (and not a shell script or something like that).

Comment 13

12 years ago
Vincent: This is more of a general issue with helper applications. The browser cannot verify that a given file is actually what it claims to be (using either Content-Type or file extension), and even if it is, there may be risks involved, see the recent issue with WMF files on Windows. So we ultimately have to trust the helper apps here to report bad/invalid files to the user.

Filtering Content-Types at the proxy level fundamentally does not work for archives (think zip or tar), so completely relying on that won't work anyway.

Hm, looks like I accidentially assigned this bug instead of confirming...
Status: ASSIGNED → NEW
(Reporter)

Comment 14

12 years ago
(In reply to comment #13)
> Vincent: This is more of a general issue with helper applications. The browser
> cannot verify that a given file is actually what it claims to be (using either
> Content-Type or file extension), and even if it is, there may be risks
> involved, see the recent issue with WMF files on Windows.

The WMF problem was probably yet another security hole in Windows.

> So we ultimately have to trust the helper apps here to report bad/invalid
> files to the user.

I disagree. A problem is that a helper application may be generic, and it is not necessarily possible or easy to do.

> Filtering Content-Types at the proxy level fundamentally does not work for
> archives (think zip or tar), so completely relying on that won't work anyway.

I don't see any problem with archives.
(Reporter)

Comment 15

12 years ago
Here are more details concerning the problem:

The user may want to use a generic application for archives, e.g. zip, tar, and possibly shell scripts (is that application/x-shar?). Any format would be accepted (the user assumes that for local files, e.g. on his intranet, there's no security problem). But as some formats are not trusted from the internet, the user would set up some filtering, e.g. disallowing shell scripts for any archive Content-Type (but not for text/*, as the user still wants to be able to *view* shell scripts). Therefore, with such a filtering, the helper application would be executed on internet files only for known and trusted archive formats.

Now assume that the user downloads a file named file.gz, and this file has the Content-Type text/x-sh. No filtering is done because text/* is safe (e.g. should be viewed in the browser or saved to the disk).

However, Firefox doesn't know how to display a text/x-sh file, and looks at the extension (or the Content-Encoding, which may be fake). From it, Firefox tells the user that the file is a GNU Zip archive and proposes to open it with the helper application for archives (configured by the user). The user thinks that it is a known and trusted archive format (due to his filtering based on the Content-Type -- see above) and executes the helper application. But in the reality, it may be a shell script since Firefox has messed up the Content-Type!
where does the security problem come in? the archive manager will refuse to open the file.
(Reporter)

Comment 17

12 years ago
(In reply to comment #16)
> where does the security problem come in? the archive manager will refuse to
> open the file.

The user could have changed the configuration to use another archive manager that also handles shell archives.

Comment 18

12 years ago
> The user could have changed the configuration to use another archive manager
> that also handles shell archives.

In which case a malicious server can simply send a shell script with the Content-Type "application/zip" to get around all of your filtering. Any user who does this is just plain _stupid_, period (well, one could also say this about the person writing such an archive manager). The concept of shell archives works only in trusted environments, and that is why they are dead for close to 10 years now.

Can we now return to the topic of this bug, please?
(Reporter)

Comment 19

12 years ago
(In reply to comment #18)
> In which case a malicious server can simply send a shell script with the
> Content-Type "application/zip" to get around all of your filtering.

No. Please read comment #15 carefully: "disallowing shell scripts for any
archive Content-Type" (note the "any").

Comment 20

12 years ago
In that case you need to filter on the actual content, not (only) the content type, which is different from what you said before. And if you do content filtering anyway, you can also exclude shell archives in general (or you can exclude all the text/* content types that Firefox will not render in the browser, see bug 57342). In short: Yes, you can set up your browser in a way that may compromise security (shar archive manager). Don't do that then.
(Reporter)

Comment 21

12 years ago
(In reply to comment #20)
> In that case you need to filter on the actual content, not (only) the content
> type, which is different from what you said before.

Yes, sorry if this wasn't clear. Filtering is done on the actual contents, but the filter itself is selected according to the Content-Type.

> And if you do content filtering anyway, you can also exclude shell archives
> in general (or you can exclude all the text/* content types that Firefox
> will not render in the browser, see bug 57342).

I do not wish to exclude shell archives in general. Also remember that this is just an example. There could be similar problems with other types of files (and if other extensions are used).

> In short: Yes, you can set up your browser in a way that may compromise
> security (shar archive manager). Don't do that then.

If the browser honored the Content-Type (always) in some way, then security wouldn't be compromised. The problem is that until I was aware of this bug, I didn't know that such a filtering method could compromise security.

So, if this bug could be fixed soon[*], then OK. Otherwise I think that there should be a temporary warning (or more useful information) in the dialog box if this is easier than fixing the bug completely.

[*] Does this mean that bug 132702 must be fixed first? This one is almost 4 years old, so it could still last months or years before this bug is fixed.
Assignee: file-handling → nobody
QA Contact: ian → file-handling
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.