1309630 - (CVE-2022-22755) Code execution after tab and window close.

Status: VERIFIED FIXED

(Core :: XSLT, defect, P3)

Description

[Jack Wrenn]

Attachment: Minimal Test Case

STEPS TO REPRODUCE:
  1 Download 'exploit.xsl' (a minimal testcase of the bug).
  2 Run `python -m SimpleHTTPServer 8080` in a terminal.
  3 Navigate to 'http://localhost:8080/exploit.xsl'.
  4 Check the output of the server started in Step 2.
  5 Open another tab.
  6 Close the 'exploit.xsl' tab.
  7 Check the output of the server started in Step 2.
  8 Close the browser window. Grab lunch.
  9 Check the output of the server started in Step 2.

EXPECTED BEHAVIOR:
  - At Step 4, the server IS reporting incoming GET requests.
  - At Step 7, the server is NOT reporting incoming GET requests.
  - At Step 9, the server is NOT reporting incoming GET requests.

ACTUAL BEHAVIOR:
  - At Step 4, the server IS reporting incoming GET requests.
  - At Step 7, the server IS reporting incoming GET requests.
  - At Step 9, the server IS reporting incoming GET requests.

POSSIBLE EXPLOITATION
A. User Tracking
I've constructed a proof-of-concept user-tracking server that serves
each request a variant of 'exploit.xsl' which has been tagged with a 
unique identifying number. The server sleeps for several seconds before
responding to each incoming request, so as not to cause an undue amount
of network traffic. Upon each request, the server logs the time of the
heartbeat, the user ID, and their IP address. This leaks, roughly, the
user's possibly-changing location and their computer usage habits.

B. Theft of Computing Resources
This bug can be exploited to force the user's browser to perform general
computation after the user has left the page. The attached file does not
have a base-case to its recursive calls, but can be easily modified to
have one that forwards the result of the computation to the attacker.

C. Denial-of-Service Attacks
This attack can be used to generate a large volume of network trafic
from a user after they have left the page. Combined with an XSS attack,
Firefox users could be co-opted into bombarding a site long after they
have left the page.

OTHER OBSERVATIONS
  1 This bug is exploitable with javascript disabled (unsurprising from
    a technical perspective, but given the possible attacks, probably
    surprising from a user's perspective).
  2 If the firefox process ends and then is restarted with the session
    restored, the requests pick right up from where they left off.
  3 If the recursion reaches a base case after the window is closed,
    Firefox appears to do some DOM processing. This can be tested by
    modifying 'exploit.xslt' to output an HTML file containing,
      <link rel="prefetch" href="/test.png">
    upon reaching its base case. The server logs will display a request
    to 'test.png', even though the window was closed before processing
    the XSLT completed. It may be able to combine this bug with other
    bugs to produce other exploits at this point.
  4 The attacker can detect when the tab is closed since the pending 
    request is interrupted.
  5 The attacker may modify an in-progress computation by serving a
    different 'exploit.xsl?n=N' at a particular value of N. (I haven't
    explored this in much depth, yet.)
  6 This bug is exploitable with javascript disabled (unsurprising from
    a technical perspective, but given the possible attacks, probably
    surprising from a user's perspective).

Comment 1

[Daniel Veditz [:dveditz]]

Having trouble reproducing this, but some of these results would be alarming from a privacy POV if true. For instance "OTHER OBSERVATIONS" #2 seems really surprising given the way sessionrestore works.

Comment 2

[Jack Wrenn]

Attachment: Video demonstration the bug.

For the sake of testing, it's useful to set Firefox's cache size to zero, or clear the cache before navigating to 'exploit.xsl'. Otherwise, since 'exploit.xsl' is cached aggressively, the requests will not appear in the server log until the appended query parameter becomes sufficiently large as to not be in the cache already.

Comment 3

[Jack Wrenn]

I've had the situation of observation #2 occur a few more times since filing the report (I notice because the server log suddenly explodes), but I haven't figured out the sequence of events that causes it to happen reliably, yet.

Having played around with this a bit more, I'm pretty sure that the appearance (from the server's perspective) that the "requests pick right up from where they left off" is because the requests up to that point have just been fetched from cache.

Comment 4

[Peter Van der Beken [:peterv]]

Hmm, we probably should add a request to the loadgroup to stop new loads if the loadgroup is canceled. Haven't been able to reproduce the session restore case yet.

Comment 5

[Jack Wrenn]

Attachment: Video demonstrations of session restore case.

I've attached two video demonstrations in which I open Firefox, navigate to 'exploit.xsl', kill the Firefox process, and then restart it. Immediately after the browser window opens, Firefox navigates to the previously open 'exploit.xsl' tabs. (It took a few tries between each video, however.)

Comment 6

[Jack Wrenn]

Attachment: javascript-after-tab-close.tar

Using this bug and Gecko's XSLT/Javascript interface, I was able to execute javascript code in a tab after the window was closed.

Attached is a very hastily assembled demo server and video demonstrating the exploit.

Comment 7

[Jack Wrenn]

Attachment: A more coherent demonstration of executing javascript after a tab is closed, including source code, videos, and logfiles.

I've attached a more coherent demonstration of executing javascript after the tab or window is closed. See 'demonstration.mp4' for a demonstration, or open Firefox to 'http://localhost:8000/' and execute 'cargo run' to play with the backdoor yourself. I've found it to be a very convenient way to test which web APIs are available after the tab is closed. I have also included the stdout and stderr of firefox during the video demonstration as 'firefox.log'.

I've had firefox eventually segfault a few times, too.

Can anyone at firefox confirm this bug? Is there any information I can include that would help?

Comment 8

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

Tyson, can you see if you can reproduce this PoC?

Comment 9

[Tyson Smith [:tsmith]]

(In reply to Al Billings [:abillings] from comment #8)
> Tyson, can you see if you can reproduce this PoC?

I can reproduce the issue. I used the html page in the rust example combined with the original xsl file and served them using Python's SimpleHTTPServer.

Comment 10

[Tyson Smith [:tsmith]]

I am unable to reproduce the session restore version of the bug.

Comment 11

[Tyson Smith [:tsmith]]

To be clear I followed the original steps to trigger the issue. Once the hidden script was running I opened one new fresh tab and closed all remaining tabs. The script was still pinging the test server. I called "killall firefox" to trigger session restore and reopened the browser. The "fresh tab" I previously opened was restored and the script was no longer pinging the server.

Comment 12

[Tyson Smith [:tsmith]]

Closing the last tab when the hidden script is running keeps the browser alive even though it appears to be closed when e10s is disabled (this is not the case with e10s enabled)

Comment 13

[Jack Wrenn]

Attachment: Video demonstration of session restore bug with blank profile. (Mozilla Firefox 57.0.3)

I've attached a slightly different demonstration of the exploit being run across sessions.

If I get the exploit page into the profile's 'Top Sites' list, the exploit will run quietly in the background, without the browser actually showing that it's trying to load the page at all.

In the attached video, I create a blank profile, and then navigate to the exploit page twice. After the second navigation, the exploit page is placed in the 'Top Sites' list. I then:
 • Open the browser to no particular page at all; the exploit runs (1:54).
 • Open a new tab, close the old opened 'New Tab' page, and navigate to mozilla.org; the exploit is still running (~2:08).
 • Close the browser.
 • Open the browser directly to mozilla.org; the exploit runs (2:30).
 • Close the browser.
 • Open the browser directly to a private browsing window to no particular page at all; the exploit runs (2:50).

Comment 14

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

Andrew, can someone take a look at this issue? It's been sitting around for quite a bit.

Comment 15

[Peter Van der Beken [:peterv]]

Attachment: v1

Need to add an automated testcase.

Comment 16

[Peter Van der Beken [:peterv]]

Attachment: Bug 1309630 - Use a request to stop transforming, test. r?smaug!

Comment 17

[Peter Van der Beken [:peterv]]

Attachment: Bug 1309630 - Use a request to stop transforming. r?smaug!

Depends on D134249

Comment 18

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

Use a request to stop transforming. r=smaug
https://hg.mozilla.org/integration/autoland/rev/2c0666d500df57b12358c008f7a8faa7cfaeb26e
https://hg.mozilla.org/mozilla-central/rev/2c0666d500df

Comment 19

[Hani Yacoub, Desktop QA]

Verified as fixed on macOS 11.6, Windows 10 and on Ubuntu 20.04.

Comment 20

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Is this ready for an ESR approval request? Please nominate if yes.

Comment 21

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Per Slack discussion with Peter, better to let this one ride the trains.

Comment 22

[Tom Ritter [:tjr] (OOTO until mid-August)]

Attachment: advisory.txt

Comment 23

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

Use a request to stop transforming, test. r=smaug
https://hg.mozilla.org/integration/autoland/rev/0690f629f8c7a25ca7fc235c1efa6b6a1c205d0f
https://hg.mozilla.org/mozilla-central/rev/0690f629f8c7