Closed Bug 1317873 (CVE-2022-22756) Opened 6 years ago Closed 1 year ago

Tricking user into creating an executable by hijacking drag n drop of an image

Categories

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

52 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
97 Branch
Tracking Status
firefox-esr91 97+ verified
firefox95 --- wontfix
firefox96 --- wontfix
firefox97 + verified

People

(Reporter: qab, Assigned: enndeakin)

References

Details

(Keywords: sec-moderate, Whiteboard: [post-critsmash-triage][adv-main97+][adv-esr91.6+])

Attachments

(5 files)

Attached file DnD-PoC.html
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.87 Safari/537.36

Steps to reproduce:

Run attached PoC on latest firefox (I confirmed this on latest stable and nightly) and simply drag and drop the img seen into any folder on your local disk.


Actual results:

We can successfully hijack 'application/x-moz-file-promise-dest-filename' and 'application/x-moz-file-promise-url' and be able to set the filename and contents of the newly created file. The result is a .bat file with the contents to run calc on windows. 

I assume the file promise feature exists in order to drag and drop images you see on the web and easily save them on your desktop. If we drag and drop anchor tags into a folder we just get an 'internet shortcut' file pointing to the url. 

It's clear though this is unintended, if we assume this feature is purely for images then an attacker could easily create an executable with an icon of an image, with some tricks to obfuscate the '.exe' and we could potentially have a user unintentionally open an executable assuming its the image they saw.

Also, because of Bug 1317023 (I assume since this part does not work with e10s disabled) if we choose 'application/x-moz-file-promise-url' to equal say file:///C:// we can save a file locally with the full directory contents of C: drive. But this would require the user to resubmit the 'image' they just saved.


Expected results:

Perhaps 'application/x-moz-file-promise-dest-filename' and 'application/x-moz-file-promise-url' should be read only? and also make sure that those are only set on valid images.
Flags: needinfo?(dveditz)
Just submitted a report similar to this: Bug 1318736 which 'hijacks' the 'copy image' option and if pasted will result in an executable. Both of these combined should make this a more serious bug in the realm of image download/saving handling.
We should be able to easily just block these additional types from content in DataTransfer::PrincipalMaySetData.
Neil, are you saying we should do this? And if so what component/priority is correct for this bug?
Flags: needinfo?(enndeakin)
Yes, it just requires adding a couple of extra checks on other types to DataTransfer::PrincipalMaySetData.
Group: firefox-core-security → core-security
Component: Untriaged → Drag and Drop
Flags: needinfo?(enndeakin)
Product: Firefox → Core
Group: core-security → dom-core-security
Should I open another bug for what I described in comment 3?
May I get an update on this bug, please?
Flags: needinfo?(dveditz)
Flags: sec-bounty?

I think comment 11 is for Neil

Flags: sec-bounty?
Flags: sec-bounty+
Flags: needinfo?(enndeakin)
Assignee: nobody → enndeakin
Attachment #9227390 - Attachment description: Bug 1317873, don't allow any of the promise types to be assigned to a DataTransfer, r=nika → Bug 1317873, don't allow any internal types to be assigned to a DataTransfer, r=nika
Group: dom-core-security → core-security-release
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch

I'm going to assume that all branches are affected.

Flags: qe-verify+
Whiteboard: [post-critsmash-triage]
  1. This patch broke drag & drop in the Sidebery extension, because some setData calls now throw: https://github.com/mbnuqw/sidebery/search?q=setData
  2. We could probably use the same internal type check for bug 1728425, so this is nice.
  3. I was wondering why we didn't rename text/_moz_htmlcontext or text/_moz_htmlinfo as well?
See Also: → 1728425

(In reply to Tom Schuster [:evilpie] from comment #17)

  1. This patch broke drag & drop in the Sidebery extension, because some setData calls now throw: https://github.com/mbnuqw/sidebery/search?q=setData
  2. We could probably use the same internal type check for bug 1728425, so this is nice.

Seems like we could just add text/x-moz-text-internal to the ones that extensions are allowed to set.

On one hand, it may be useful for tab management extensions to be able to assign text/x-moz-text-internal so that they can emulate tab dragging.

On the other hand, the sidebery extension doesn't use 'text/x-moz-text-internal' for its intended purpose anyway. I'm not sure what it's author intended, but the use of 'text/x-moz-text-internal' is fairly useless there since the code also assigns 'text/plain' during the same drag. The internal type is intended to assign plain text to be used only internally by the same application, so setting the plain text type as well breaks this.

  1. I was wondering why we didn't rename text/_moz_htmlcontext or text/_moz_htmlinfo as well?

These types shouldn't have any security considerations if assigned -- they specify some contextual information for html data -- I avoided changing them in case of compatibility issues.

Flags: needinfo?(enndeakin)

The patch landed in nightly and beta is affected.
:enndeakin, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(enndeakin)

Thanks for your response Neil. I think your explanation makes sense I actually opened a PR to remove the usage of text/x-moz-text-internal.

Testing results:

  • test case 1: DnD-PoC.html
    97.0a1: when the image is dragged to the desktop, it gets copied as a png image named "0PhK7.png"
    96.0b7: when the image is dragged to the desktop, a "bad.bat" file is created
    95.0.2: when the image is dragged to the desktop, a "bad.bat" file is created

  • test case 2: Poc2
    97.0a1: when the image is dragged to the desktop, nothing happens, but it may be invalid considering the image is missing from the test page
    96.0b7: when the image is dragged to the desktop, nothing happens, but it may be invalid considering the image is missing from the test page
    95.0.2: when the image is dragged to the desktop, nothing happens, but it may be invalid considering the image is missing from the test page

  • test case 3: DnD-PoC.html
    97.0a1: when dragging the "First" and "Second" links to the bookmarks bar, nothing happens
    96.0b7: when dragging the "First" and "Second" links to the bookmarks bar, nothing happens
    95.0.2: when dragging the "First" and "Second" links to the bookmarks bar, nothing happens

This was tested in Windows 10. but it will be tested in the other OS types once clear steps to reproduce/verify are provided.
Considering the confusing results, I assume that the second and third test cases attached are not working properly.
Can you provide us correct steps to verify this implementation? Clear actual and expected results of the test cases are not found here.

Thanks, Neil!

Testcase 1 is showing the changed behaviour. It should drop the image with the png filename of the image and not 'bad.bat'. An exception should appear on the console.

Testcase 2 isn't related to this bug, but I don't see any issues with it. Likely fixed by some other bug.

Testcase 3 was fixed by bug 1543694.

Flags: needinfo?(enndeakin)

I have confirmed this implementation also on Ubuntu 20.04.3 LTS and Mac OS 11.6.2.
Furthermore, the exception is seen in the Web COnsole is:
Uncaught DOMException: The operation is insecure. attachment.cgi:5
ondragstart https://bug1317873.bmoattachments.org/attachment.cgi?id=8811122&t=5jADaxuCwTIPOvknM5hZbt:5

Closing as verified. Thanks!

Status: RESOLVED → VERIFIED
Flags: qe-verify+

Please nominate this for ESR approval when you get a chance.

Flags: needinfo?(enndeakin)

Comment on attachment 9227390 [details]
Bug 1317873, don't allow any internal types to be assigned to a DataTransfer, r=nika

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Provides extra protection from possible exploit when dragging and dropping a file to the desktop. An attacker could create an image that is saved with an exe extension.
  • User impact if declined: No user noticeable change
  • Fix Landed on Version: 97
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Not risky
Flags: needinfo?(enndeakin)
Attachment #9227390 - Flags: approval-mozilla-esr91?

Comment on attachment 9227390 [details]
Bug 1317873, don't allow any internal types to be assigned to a DataTransfer, r=nika

Approved for 91.6esr.

Attachment #9227390 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+

Testing results of reproduction and fix verification:

  • Windows 10:
    ESR v91.5.1esr - when the image is dragged to the desktop, a "bad.bat" file is created
    ESR v91.6.0esr - when the image is dragged to the desktop, it gets copied as a png image named "0PhK7.png"

  • Mac OS 11.6.2:
    ESR v91.5.1esr - when the image is dragged to the desktop, NOTHING HAPPENS (bat.bat is not created)
    ESR v91.6.0esr - when the image is dragged to the desktop, it gets copied as a png image named "0PhK7.png"

  • Ubuntu 20.04.3 LTS:
    ESR v91.5.1esr - when the image is dragged to the desktop, it gets copied as a png image named "0PhK7.png" (appears to not reproduce)
    ESR v91.6.0esr - when the image is dragged to the desktop, it gets copied as a png image named "0PhK7.png" (as expected in a fixed build)

  • ESR build is taken from here:
    https://treeherder.mozilla.org/jobs?repo=mozilla-esr91&revision=d8affed56ce5cbbc47e05736d7ce714bffd1f968

Based on the previous information, I will set this bug as verified fixed in ESR v91.6.0esr.
Please NI me if more investigation is necessary considering the unexpected behavior in ESR v91.5.1esr (on Mac and Linux).

Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main97+]
Attached file advisory.txt
Whiteboard: [post-critsmash-triage][adv-main97+] → [post-critsmash-triage][adv-main97+][adv-esr91.6+]
Alias: CVE-2022-22756
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.