943886 - A download filename starting with ~ (tilde) affects the download location

Status: NEW

(Firefox :: File Handling, defect)

Description

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

From: =?ISO-8859-1?Q?Malek_Ha=EFssous?= <[e-mail]>
Date: Wed, 27 Nov 2013 12:43:12 +0100
Subject: [Firefox] Security Vulnerability in downloads
To: [e-mail]
-----//-----
Bonjour,

Cette faille de sécurité concerne en particulier les systèmes Linux dont Mac à priori (pas testé).
Le téléchargement d'un fichier dont le nom commence par une tilde "~", a pour conséquence de modifier l'emplacement de téléchargement choisi par l'utlisateur ou par défaut.
En effet, la tilde est un raccourci pour accéder au répertoire personnel de l'utilisateur executant Firefox. Et il se trouve qu'au lieu d'accéder au répertoire /home/user/, le fichier tente de s'enregistrer dans /home/nomdufichier

Je pense qu'il faut approfondir la question, il est peut-être envisageable qu'un nom de fichier malicieusement choisi permette de corrompre les données personnel de l'utilisateur voire de la machine.

Cordialement.

Malek HAISSOUS
Étudiant Epitech Paris - Promo 2017
[e-mail]
------//-----
[Translation]
-----\\------

Hello,

This vulnerability applies in particular to which Linux Mac priori (not tested) systems.
Downloading a file whose name begins with a tilde "~", has the effect of changing the download location chosen by the onscreen user or default.
Indeed, the tilde is a shortcut to the home directory of the user running Firefox. And it turns out that instead of accessing the directory / home / user /, the file attempts to register in / home / filename

I think we should deepen the question, it may be possible that a file name chosen maliciously allow corrupt personal data of the user or the machine.

Cordially.
Student Epitech Paris - Promo 2017
[e-mail]

Comment 1

[Benjamin Smedberg]

I expect bug 76968/bug 298801 is the cause of this, although I'm not how the download manager is using files (maybe it's using os.file instead). NI?paolo

Comment 2

[Matt Wobensmith [:mwobensmith][:matt:]]

I can't reproduce this. I renamed a file on a server to begin with a tilde, but when prompted to download, it defaults to my chosen default location.

Can you stage a sample of this? Or provide more details?

Comment 3

[:Paolo Amadini]

I reproduced this locally, and this is apparently a file picker issue, thus it only happens when prompted for the final file name, not when downloading automatically.

You can inspect this in a browser scratchpad on Linux as a test case:

let fp = Cc["@mozilla.org/filepicker;1"].createInstance(Ci.nsIFilePicker);
fp.init(window, "Test", Ci.nsIFilePicker.modeSave);
fp.displayDirectory = Services.dirsvc.get("DfltDwnld", Ci.nsIFile);
fp.defaultString = "~test";
fp.show();
fp.file.path; // "/home/~test"

The expected result was "/home/paolo/Downloads/~test".

Note that if I choose the parent folder as the target location in the file picker, instead of a subfolder of it, the result is correct, for example "/home/paolo/~test".

I wonder if this may be related to the fact that, as an intermediate step, we use a file URI:

http://mxr.mozilla.org/mozilla-central/source/widget/gtk/nsFilePicker.cpp#179

(I hope I found the correct platform-specific code, correct me if I'm wrong.)

Benjamin, can you or someone with a C++ debugger on Linux continue from here? I'm on vacation and I'm not certain of my availability in the next few days.

Comment 4

[:Paolo Amadini]

I noticed that mFileURL is actually a string (it seemed a sort of native URI type to me at first glance). So, I was able to test its conversion to a real URI in JavaScript, and I noticed that we do the right thing there:

NetUtil.newURI("file:///home/paolo/Downloads/~test").QueryInterface(Ci.nsIFileURL).file.path
NetUtil.newURI("file:///home/paolo/Downloads/%7Etest").QueryInterface(Ci.nsIFileURL).file.path

// "/home/paolo/Downloads/~test"

It might be that the operating system gives us the wrong path. In that case, as a workaround we should just ensure that suggested file names never start with a tilde when we invoke the dialog in the platform-specific code.

Comment 5

[Daniel Veditz [:dveditz]]

we shouldn't let you overwrite existing files (without prompting the user, at least), but could you try getting a user to save a .bashrc or similar config file that would have executable-like effects?

Comment 6

[:Paolo Amadini]

(In reply to Daniel Veditz [:dveditz] from comment #5)
> we shouldn't let you overwrite existing files (without prompting the user,
> at least), but could you try getting a user to save a .bashrc or similar
> config file that would have executable-like effects?

As far as I can tell, we sanitize all attachment file names to prevent directory separators to be inserted, so this file picker bug will always result in a target file in the "/home/" directory, moreover starting with a tilde.

For example, an attachment file name like "~user/.bashrc" would result in a target file similar to "/home/~user.bashrc", that by default should not even be creatable by unprivileged users, resulting in a download error.

Comment 7

[Al Billings [:abillings - ex-MoCo]]

Three months later, any progress on this security bug?

Comment 8

[:Gavin Sharp [email: [e-mail]]]

This isn't really a security bug as far as we know now, per comment 6, and probably shouldn't be hidden.