Bug 351035

Summary:	File pickers and Dolphin show icon based on file extension, not contents or MIME type
Product:	[Applications] dolphin	Reporter:	Jeffrey <eljefedelito>
Component:	general	Assignee:	Dolphin Bug Assignee <dolphin-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	frank78ac
Priority:	NOR
Version First Reported In:	16.12.2
Target Milestone:	---
Platform:	Debian unstable
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Jeffrey 2015-08-06 13:44:47 UTC

A common criticism of MSWindows is that malware is easily hidden within files that display the wrong icon based on the file extension alone.  Linux, we're told, doesn't rely on file extensions and that those are only a part of the name.  Example of this common understanding,
> The operating system seems to know what files are without relying on the
> file extension — it does this using MIME types.
http://www.howtogeek.com/192628/mime-types-explained-why-linux-and-mac-os-x-dont-need-file-extensions/

KDE has this same unfortunate behavior as MSWindows; changing a file's written extension changes both the displayed icon and changes the default application that opens a file.  The MIME type is not used and this puts users at risk for opening files within the wrong application, possibly opening buffer overruns or other attack vectors.  If nothing else, it makes the desktop less usable if filetypes are required or if files are opened based on arbitrary information such as the written extension.

Reproducible: Always

Steps to Reproduce:
1. Download unknown message.zip (this is an example and happens with any filetype with an incorrect extension)
2. Double-click message.zip (this is an example and happens with any filetype with an incorrect extension)
3. Ark (or other app based on extension) opens but fails to display the file/result because it's really a python script or who knows (this is an example and happens with any filetype with an incorrect extension)

Actual Results:  
The file's (incorrect) icon is displayed and an incorrect application is opened, both based on the incorrect named extension rather than the MIME type.

Expected Results:  
The icon displays correctly based on the MIME type of a file, and the correct application opens regardless of the name given to the file.

This is a security risk, an inaccurate behavior of the software that can do better, and an inconvenience that users must have the files named correctly.

Comment 1 Frank Reininghaus 2015-08-08 20:59:23 UTC

First of all, thanks for the bug report.

(In reply to Jeffrey G Thomas from comment #0)
> Linux, we're told, doesn't rely on file extensions and that those are only a part
> of the name.

Could you please provide a link to the source of this misinformation? If you want to know how mime types of files are to be determined on systems that respect the "shared mime info" specification, please read

http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-0.18.html

You will see that applications which respect the specification MUST use the extension to determine the mime type, and only read the file contents if the extension is not sufficient to determine the mime type unambiguously.

>  Example of this common understanding,
> > The operating system seems to know what files are without relying on the
> > file extension — it does this using MIME types.
> http://www.howtogeek.com/192628/mime-types-explained-why-linux-and-mac-os-x-
> dont-need-file-extensions/

A quote from this article:

"When you open a file on Linux or Mac OS X, the operating system doesn’t just rely on the file extension."

Please note the word "just"!

> KDE has this same unfortunate behavior as MSWindows; changing a file's
> written extension changes both the displayed icon and changes the default
> application that opens a file.

As I said, this is the behavior that is mandated by the shared mime info specification. This is nothing that KDE can change on its own.

> The MIME type is not used and this puts
> users at risk for opening files within the wrong application, possibly
> opening buffer overruns or other attack vectors.

Sorry, but if there is a buffer overrun or a similar security vulnerability in an application that is used to open a file, then this is a bug in that application that should be reported accordingly. And if there are such security vulnerabilities in an application, then using files with extensions that simulate incorrect mime types is not needed to exploit the vulnerability. Therefore, what you suggest does not provide any additional security from my point of view. 

> This is a security risk, an inaccurate behavior of the software that can do
> better, and an inconvenience that users must have the files named correctly.

If you really feel strongly about this issue, then please discuss this with the shared-mime-info maintainers: http://freedesktop.org/wiki/Software/shared-mime-info/