1317873 - (CVE-2022-22756) Tricking user into creating an executable by hijacking drag n drop of an image

Status: VERIFIED FIXED

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

Description

[Abdulrahman Alqabandi]

Attachment: 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.

Comment 1

[Abdulrahman Alqabandi]

Attachment: Poc2

Another interesting behavior, not sure which browser is at fault here.

Open Google Chrome (or IE, not sure if it will work on edge or other browsers) and go to 'https://jpillora.com/base64-encoder/' this website simply grabs any files dropped and turns them into base64 encoded data uri.

Now open the new PoC on firefox then drag and drop the invalid image into the other browser and into that base64 website.

It appears the drag object suddenly has a file object inside of it, weird.

Comment 2

[Abdulrahman Alqabandi]

Nevermind, the above comment is probably related to Bug 1317023 more than this bug, will post it there instead.

Comment 3

[Abdulrahman Alqabandi]

Attachment: DnD-PoC.html

Here is another 'hijack' where it makes it easier to trigger javascript on arbitrary websites. I think the fact that the url is not clearly visible in the addressbar makes this type of bookmark 'self xss' a bit more viable.

Comment 4

[Abdulrahman Alqabandi]

Note: the above PoC can also be done with file: uri schemes

Comment 5

[Abdulrahman Alqabandi]

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.

Comment 6

[Abdulrahman Alqabandi]

Related to Bug 279945 and Bug 426285 (https://www.mozilla.org/en-US/security/advisories/mfsa2005-25/)

Comment 7

[Neil Deakin]

We should be able to easily just block these additional types from content in DataTransfer::PrincipalMaySetData.

Comment 8

[Benjamin Smedberg]

Neil, are you saying we should do this? And if so what component/priority is correct for this bug?

Comment 9

[Neil Deakin]

Yes, it just requires adding a couple of extra checks on other types to DataTransfer::PrincipalMaySetData.

Comment 10

[Abdulrahman Alqabandi]

Should I open another bug for what I described in comment 3?

Comment 11

[Abdulrahman Alqabandi]

May I get an update on this bug, please?

Comment 12

[Abdulrahman Alqabandi]

The PoC I submitted at comment 3 seems to be fixed.

Comment 13

[Daniel Veditz [:dveditz]]

I think comment 11 is for Neil

Comment 14

[Neil Deakin]

Attachment: Bug 1317873, don't allow any internal types to be assigned to a DataTransfer, r=nika

Comment 15

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

don't allow any internal types to be assigned to a DataTransfer, r=nika
https://hg.mozilla.org/integration/autoland/rev/a566c029f7a5af517126482475f022cb675dbd98
https://hg.mozilla.org/mozilla-central/rev/a566c029f7a5

Comment 16

[Andrew McCreight [:mccr8]]

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

Comment 17

[Tom S [:evilpie]]

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?

Comment 18

[Neil Deakin]

(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.

3. 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.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 20

[Tom S [:evilpie]]

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.

Comment 21

[Daniel Bodea [:danibodea]]

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!

Comment 22

[Neil Deakin]

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.

Comment 23

[Daniel Bodea [:danibodea]]

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!

Comment 24

[Ryan VanderMeulen [:RyanVM]]

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

Comment 25

[Neil Deakin]

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

Comment 26

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 27

[Ryan VanderMeulen [:RyanVM]]

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

Comment 28

[Daniel Bodea [:danibodea]]

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).

Comment 29

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: advisory.txt