1752396 - (CVE-2022-26386) Temporary file creation moved from /tmp/mozilla_${USER}0 to /tmp. Potential security risk

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, defect)

Description

[attila]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Firefox used to create a folder /tmp/mozilla_${USER}0 where it stored all temporary files (mostly downloads for display). Somewhen between 78 and 91 this was abolished and now all downloaded files end up in /tmp/.

This is a potential security risk!

/tmp/mozilla_${USER}0 was 0700, i.e. nobody but the $USER could create files in it. Now, with files being created in /tmp, an attacker can not only guess a filename but, by monitoring web traffic, actually knows what file is created next. This is a variant of the insecure temporary file creation attack, where the attacker doesn't even has to guess.

Actual results:

Downloaded temporary files end up in /tmp

Expected results:

Downloaded temporary files should not end up in /tmp/but in a sub-directory that is owned by the user and write protected for everyone else.

Comment 1

[:Gijs (he/him)]

There was some related work in bug 1726537 and bug 1726732, but both of those landed in the 93 cycle, so I would expect both 92 and 93 (and later releases) to still use the subfolder approach. Certainly the relevant code is still there. It seems you're reporting this with 91 (esr?), on Linux - is that right? If so, can you check:

1. if this reproduces with a clean Firefox profile ( https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles ; and if not, what configuration changes are needed to get into a state where this reproduces)
2. if this reproduces with a non-snap/flatpak build from mozilla.org (ie an official build, rather than one from your linux distro) ?

If you can reproduce in both cases, please can you provide more details about the exact steps you're using (ie how are you downloading what file)?

If you have time, you could probably narrow down when/how this broke using mozregression.

Comment 2

[Daniel Veditz [:dveditz]]

This really does sound like a duplicate of bug 1726732, but that bug is supposedly fixed and the regression was not shipped. Would not have affected Firefox 91 though.

Comment 3

[:Gijs (he/him)]

I think the answer is that this actually regressed with bug 1710933, not bug 1714107. I ran mozregression and confirmed. So 91 esr is affected but no other supported releases are.

Ryan, what do you want us to do here? Can we back out 1710933 on esr, or do a selective fix of 1710933, or do we just not address this on 91esr because it's ESR and any changes carry risk, and this is a sec-low?

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Depends on how simple the fix is :-). Bug 1710933 doesn't backout cleanly from ESR91 and I honestly don't have a good way of assessing whether it'd be more risky trying to come up with a working backout vs. creating an actual fix. And I think the answer to that question would influence the answer as to whether or not we should try to address this or not.

Comment 5

[:Gijs (he/him)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #4)

Depends on how simple the fix is :-). Bug 1710933 doesn't backout cleanly from ESR91 and I honestly don't have a good way of assessing whether it'd be more risky trying to come up with a working backout vs. creating an actual fix. And I think the answer to that question would influence the answer as to whether or not we should try to address this or not.

AFAICT the backout only doesn't work because of the test it added, which got modified to include a single extra pref env push (see https://hg.mozilla.org/releases/mozilla-esr91/log/tip/uriloader/exthandler/tests/mochitest/browser_launched_app_save_directory.js and specifically https://hg.mozilla.org/releases/mozilla-esr91/diff/4ebb5912bb0efbe2cccbc56887cdd5b580761461/uriloader/exthandler/tests/mochitest/browser_launched_app_save_directory.js ). But the test file can just be removed. Then the remaining question would be if any other tests fail, which from a quick local check is not the case. So I guess I'll put up the backout patch.

Comment 6

[:Gijs (he/him)]

Attachment: Bug 1752396, r?mtigley

Comment 7

[:Gijs (he/him)]

Comment on attachment 9263163 [details]
Bug 1752396, r?mtigley

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: sec-low privacy issue; many distros ship esr-based builds
• User impact if declined: see above
• Fix Landed on Version: 93 (but this is a backout of a patch that is 91-specific)
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Nearly straight backout, minus the change in the test the backout deletes.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9263163 [details]
Bug 1752396, r?mtigley

Simple backout to fix a bug introduced by the original patch. Approved for 91.7esr.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/bb298c7c5613

Comment 10

[Anca Soncutean, Desktop QA]

I’ve managed to reproduce this issue with 91.6.0esr on Ubuntu 20.04.
Verified fixed with 91.7.0esr on Ubuntu 20.04.

Comment 11

[Tom Ritter [:tjr]]

Attachment: advisory.txt

AFAICT this affects Mac and Linux only.