1917536 - (CVE-2025-2817) Firefox Updater Elevation of Privilege to SYSTEM

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect, P1)

Description

[justlikebono]

Attachment: Report.zip

All details exist within the .md file in the attachment.

zip password: 0118dbe97dc23de28009c4c49fa879503d97966a09f920c5962ed7610f7d14b1

Comment 1

[justlikebono]

Attachment: FireFox_PoC1.mp4

Add FireFox_PoC1.mp4

Comment 2

[justlikebono]

Attachment: FireFox_PoC2.mp4

FireFox_PoC2.mp4

Comment 3

[justlikebono]

I forgot to attach the PoC video, so I just added it.

Comment 4

[Robin Steuber (she/her) [:bytesized]]

Contents of Firefox Updater Elevation of Privilege to SYSTEM.md from Report.zip:

---

Firefox Updater Elevation of Privilege to SYSTEM (Exploited)

Summary

A vulnerability exists in the Firefox updater that bypasses the .lock file mechanism, allowing a medium privileged user to elevate to SYSTEM via arbitrary file deletion. This is a very serious issue because the update process happens completely in the background, with no UI exposure to the user, and can be exploited very reliably. Furthermore, not only Firefox but also other programs in mozilla, such as Thunderbird, can be exploited with the same vulnerability because they use the exact same update component.

The report covers the root cause of the vulnerability, proof of exploitability through real exploits, and patching suggestions.

Basic Information

• Tested Target Version: Firefox 129.0.2 (The latest version is currently 130.0, but we use that version to trigger the update function. Obviously, vulnerabilities still exist in the latest versions.)
• Tested OS: Windows 11 x64 (OS Build 22631.4037)

Description

Mozilla Firefox's updater.exe downloads updates (in mar format) in the background if a target exists to update, and waits for the user to exit or restart firefox.

The updater.exe operates as two separate processes: one with normal user privileges and the other with SYSTEM privileges. These processes share a file called "update_elevated.lock”.

The updater.exe with user privileges “locks” the “update_elevated.lock” file, which is done by setting the SHARED_MODE flag to NULL (0) and calling CreateFile. Through this approach, even a process with SYSTEM privileges cannot obtain a handle to the file.

In fact, in normal behavior, we can see that updater.exe with SYSTEM privileges returns a SHARING VIOLATION to DeleteFile request for the “update_elevated.lock” file.

At first glance, it may not seem problematic, but the vulnerability occurs because the process that locks the "update-elevated.log" file operates with user privileges.
In Windows, processes created with the same account's privileges can overwrite the memory of another process using WINAPIs such as OpenProcess, VirtualProtectEx, and WriteProcessMemory (even if it's just a code section).

Therefore, by patching the code where the updater.exe with user privileges applies the lock, it is possible to bypass this mechanism.

If we actually implement and apply this behavior using the WINAPIs mentioned above, we can see that a DeleteFile call with SYSTEM privileges will return NAME NOT FOUND, not SHARING VIOLATION.

This means that a SYSTEM privilege DeleteFile is performed on a path that is under the control of a medium user.

Exploit

On Windows, primitives exist to link high-privilege arbitrary file deletion to SYSTEM EoP. You can read more about this technology on ZDI's blog. (https://www.zerodayinitiative.com/blog/2022/3/16/abusing-arbitrary-file-deletes-to-escalate-privilege-and-other-great-tricks)

It is also known how to make a file deletion in a fixed path that the user can control into a arbitrary file deletion. This uses Junction and Object Manager Symlink, for a detailed implementation you can refer to james forshaw's code: (https://github.com/googleprojectzero/symboliclink-testing-tools/tree/main/CreateSymlink)

By channing the previously described vulnerabilities and the primitives above, we have a stable EoP exploit in Firefox.

Reproduction Steps

1. Build Firefox_EoP.exe with the Visual Studio 2022 MSVC (or use the already existing FireFox_EoP.exe)
2. Install version 129.0.2 of Mozilla Firefox on your machine. (https://ftp.mozilla.org/pub/firefox/releases/129.0.2/win64/en-US/)
3. Launch the installed Firefox, and wait for the update to download and pending application. (You can also manually trigger the update if you go into Settings).
4. Run FireFox_EoP.exe while Firefox is in a state waiting to restart.
5. Restart Firefox, or click “Restart to Update Firefox” in Settings. (The PoC videos are available in two versions.)
6. Within 30 seconds, cmd.exe with SYSTEM privileges will be dropped.

PoC

• Source code: FireFox_EoP
• Videos: FireFox_EoP1.mp4, FireFox_EoP2.mp4

Comment 5

[Robin Steuber (she/her) [:bytesized]]

After some talk about this today, it sounds like next steps are to identify all places where we might delete that file and ensure that they do not run in the elevated updater. If we don't do this already, we may want to add a deletion of the file in the un-elevated updater in order to cleanup safely.

I haven't actually ran the proof of concept, but whether it works for me or not, we definitely should not be deleting a file in an unprivileged location from a privileged process. And I believe that we are currently doing that. So we should fix it regardless.

Comment 6

[justlikebono]

If you want to reduce development complexity, you might consider using an API like ImpersonateLoggedOnUser to impersonate user privilege only when performing that action.

Comment 7

[Daniel Veditz [:dveditz]]

Setting the security rating based on the videos; I have not confirmed the PoC but the explanation makes sense.

Comment 8

[Max Christian Pohle [:/dev/max]]

Hi! I just wanted to share first insides quickly.

1. With the latest Visual Studio versions the solution (sln) from the zip file requires:

#define _CRT_NON_CONFORMING_SWPRINTFS
#define _CRT_SECURE_NO_WARNINGS

2. There is an executable FolderOrFileDeleteToSystem.exe contained in that zip without source code, which

• I think comes from here (to be checked)
• is compiled into the Firefox_EoP.exe using the rc-file under the ID IDR_DATA1
• Firefox_EoP.exe is then supposed to write this resource to C:\Users\Public\DeleteEoP.exe as part of its Initialize() function.

3. @justlikebono: ImpersonateLoggedOnUser could simplify the fix and is a good idea. Can you confirm the origin of the executable?

Comment 9

[Robin Steuber (she/her) [:bytesized]]

(In reply to Max from comment #8)

ImpersonateLoggedOnUser could simplify the fix and is a good idea.

Calling ImpersonateLoggedOnUser "simple to use" sounds inaccurate to me. I've used it before, and it's a bit tricky to get right. Of course we could use it if necessary, but I am reasonably confident that we can just stop making the delete call in the elevated updater, which sounds much simpler.

Comment 10

[justlikebono]

Let's share some information about the binaries that exist within the PoC code.

FolderOrFileDeleteToSystem.exe - As you guessed, it comes from https://github.com/thezdi/PoC/tree/main/FilesystemEoPs/FolderOrFileDeleteToSystem, but with a little modification.
In this example, they set the rbs (MSI rollback script) to drop a dll in “C:\Program Files\Common Files\microsoft shared\ink\HID.DLL” when the exploit is successful. However, I wanted to run the SYSTEM cmd.exe immediately, so I replaced 5eeabb3.rbs with the cmd.rbs found at https://github.com/Wh04m1001/CVE-2023-21752/tree/main/v2/SDRsvcEop. After that, I replaced the last bit of output and built it.

Comment 11

[justlikebono]

Attachment: FilesystemEoPs.zip

Comment 12

[justlikebono]

I uploaded source codes of the FolderOrFileDeleteToSystem.exe.
(FilesystemEoPs.zip)

Comment 13

[Nick Rishel [:nrishel]]

Attachment: Bug 1917536 - Check for Admin and LocalSystem permissions in updater instead of inferring them from a lockfile. r=bytesized,nalexander

Comment 14

[Nick Rishel [:nrishel]]

:bytesized does this affect Thunderbird?

Comment 15

[Nick Rishel [:nrishel]]

Attachment: Bug 1917536 - Check for Admin and LocalSystem permissions in updater instead of inferring them from a lockfile. r=bytesized,nalexander

Original Revision: https://phabricator.services.mozilla.com/D223223

Comment 16

[Nick Rishel [:nrishel]]

Comment on attachment 9426643 [details]
Bug 1917536 - Check for Admin and LocalSystem permissions in updater instead of inferring them from a lockfile. r=bytesized,nalexander

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Given the small size of the patch, someone familiar with the hazard could likely reason about it quickly.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: The issue is not directly called out, but could use an audit for being too obvious. Messaging could probably be tweaked to make this look more like a cleanup refactor.
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: All Branches
• If not all supported branches, which bug introduced the flaw?: None
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: Patches are anticipated to apply with minimal effort to older branches. Comments on risk of regression apply to risk of back porting.
• How likely is this patch to cause regressions; how much testing does it need?: Low chance of regression, but high impact if a regression occurs.

Given this relates to the updater and we could be in a better place with respect to testing, this should receive QA attention before shipping.

• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: No

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Is the severity on this bug correct? https://wiki.mozilla.org/BMO/UserGuide/BugFields#bug_severity

S1 (Catastrophic) Blocks development/testing, may impact more than 25% of users, causes data loss, likely dot release driver, and no workaround available

Also, the attach patch applies cleanly to ESR128 but will need some rebasing for ESR115.

Comment 18

[Nick Rishel [:nrishel]]

Kicking this down to an S3. Not sure how to assign severity to a local privilege elevation exploit, since it's not visible to the user (until exploited). Reassign as appropriate.

Comment 19

[justlikebono]

When I checked, this vulnerability also affects Thunderbird.

Comment 20

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

The severity field for this bug is set to S3. However, the bug is flagged with the sec-high keyword.
:nrishel, could you consider increasing the severity of this security bug?

For more information, please visit BugBot documentation.

Comment 21

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

The bug is marked as tracked for firefox132 (nightly). However, the bug still has low severity.

:Amir, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 22

[Nick Rishel [:nrishel]]

:ryanvm I'm surprised we would mark this as a wontfix for Fx131, I was assuming this would likely ride a point release. Was that intentional or a quirk of how we track release vs point release?

Comment 23

[Ryan VanderMeulen [:RyanVM]]

We generally don't uplift security bugs affecting all branches to dot releases except in chemspill situations. If you feel super strongly that we need to (this would also include ESR dot releases too then), however, we can have that discussion. The security team should also weigh in on that.

Comment 24

[Nick Rishel [:nrishel]]

Bringing QA into the discussion for test planning.

Comment 25

[Tom Ritter [:tjr] (OOTO Oct 18-26)]

Comment on attachment 9426643 [details]
Bug 1917536 - Check for Admin and LocalSystem permissions in updater instead of inferring them from a lockfile. r=bytesized,nalexander

Approved to land and uplift

Comment 26

[Nick Rishel [:nrishel]]

Comment on attachment 9426643 [details]
Bug 1917536 - Check for Admin and LocalSystem permissions in updater instead of inferring them from a lockfile. r=bytesized,nalexander

Beta/Release Uplift Approval Request

• User impact if declined: Users exposed to risk of local privilege escalation attack - not currently known to exist in the wild.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce:

1. Install Firefox with patch and Maintenance Service enabled. Allow Firefox to update. Verify update applies without UAC prompt.
2. Install Firefox with patch and Maintenance Service disabled. Allow Firefox to update. Verify update applies with UAC prompt.

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The code has been tested to run and is well understood. We should have this stress tested by QA to remove any doubt given the code relates to updates.
• String changes made/needed: none
• Is Android affected?: No

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is sec-high.
• User impact if declined: Users exposed to risk of local privilege escalation attack - not currently known to exist in the wild.
• Fix Landed on Version: 133 (anticipated)
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The code has been tested to run and is well understood. We should have this stress tested by QA to remove any doubt given the code relates to updates.

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c22053f7eb41
Check for Admin and LocalSystem permissions in updater instead of inferring them from a lockfile. r=bytesized,nalexander,application-update-reviewers

Comment 28

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

https://hg.mozilla.org/mozilla-central/rev/c22053f7eb41

Comment 29

[justlikebono]

Could you please let me know when I can find out about the bounty and CVE information for this vulnerability?

Comment 30

[justlikebono]

The above content is the same.

Comment 31

[Nick Rishel [:nrishel]]

Bouncing to :tjr, but IIUC the sec-bounty flag should trigger the right people to handle this (I'm not familiar with the timing).

Comment 32

[Tom Ritter [:tjr] (OOTO Oct 18-26)]

Yes, with the bounty flag set, the committee will review the issue and decide on a bounty. CVEs are assigned when the Firefox version the issue is fixed in is close to release. For similar questions about bounty/cve's please email [e-mail]

Comment 33

[Nick Rishel [:nrishel]]

Attachment: Bug 1917536 - Check for Admin and LocalSystem permissions in updater instead of inferring them from a lockfile.

Comment 34

[Phabricator Automation]

esr115 Uplift Approval Request

• User impact if declined: Users exposed to risk of local privilege escalation attack - not currently known to exist in the wild.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Install Firefox with patch and Maintenance Service enabled. Allow Firefox to update. Verify update applies without UAC prompt. Install Firefox with patch and Maintenance Service disabled. Allow Firefox to update. Verify update applies with UAC prompt.
• Risk associated with taking this patch: Low
• Explanation of risk level: The code has been tested to run and is well understood. We should have this stress tested by QA to remove any doubt given the code relates to updates.
• String changes made/needed: none
• Is Android affected?: no

Comment 35

[Bogdan Maris, Desktop Test Engineering]

We started testing on Nightly 133 based on the agreed testing plan, but we are currently blocked by the updates being down on Nightly as per bug 1922546 comment 6

Comment 36

[Bogdan Maris, Desktop Test Engineering]

(In reply to Bogdan Maris, Desktop Test Engineering from comment #35)

We started testing on Nightly 133 based on the agreed testing plan, but we are currently blocked by the updates being down on Nightly as per bug 1922546 comment 6

Updates are up again and QA has finished testing Nightly 133 based on the test plan with no issue found.

Comment 37

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9426643 [details]
Bug 1917536 - Check for Admin and LocalSystem permissions in updater instead of inferring them from a lockfile. r=bytesized,nalexander

Approved for 132.0b5, 128.4esr, and 115.17esr.

Comment 38

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/f0a4d265d58d

Comment 39

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/f7c7a654a9a3

Comment 40

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/32ed89b53aff

Comment 41

[Ryan VanderMeulen [:RyanVM]]

Backed out from ESR115 for bustage.
https://hg.mozilla.org/releases/mozilla-esr115/rev/c33d5062b248091a659662158261cff64f2ab091

https://treeherder.mozilla.org/logviewer?job_id=477259972&repo=mozilla-esr115&lineNumber=34802

Comment 42

[Ryan VanderMeulen [:RyanVM]]

Backed out for 132.0b6 for causing bug 1923376.
https://hg.mozilla.org/releases/mozilla-beta/rev/2655c182a46f256e35701b924637938306719372

Comment 43

[Ryan VanderMeulen [:RyanVM]]

Backed out from central as well. I'll backout from ESR128 at some point over the weekend also.
https://hg.mozilla.org/mozilla-central/rev/ef3ce232d62d8aa869856f351cbbffa702ff9ab1

Comment 44

[Ryan VanderMeulen [:RyanVM]]

Backed out from ESR128.
https://hg.mozilla.org/releases/mozilla-esr128/rev/becf79c96ca97fab1f740497cbffa28a6dfd6be6

Comment 45

[Ryan VanderMeulen [:RyanVM]]

Given that next week is RC week, are we OK with letting this slip a cycle while we continue to investigate bug 1923376? This seems really risky to take so late in the cycle given the potential impact of any regressions the slip through.

Comment 46

[Nick Rishel [:nrishel]]

NI :bytesized, but my intuition is that this will probably slip a cycle.

Comment 47

[Robin Steuber (she/her) [:bytesized]]

Yeah, that seems reasonable to me.

Comment 48

[Donal Meehan [:dmeehan]]

:nrishel next week is the final week of beta for Fx133. There is little time to fix this if it needs to ship with Fx133.

Comment 49

[Nick Rishel [:nrishel]]

I believe we're trying to address this as a byproduct of Bug 1923376; I don't have a sense of the feasibility of that getting over the line.

Comment 50

[Donal Meehan [:dmeehan]]

Comment on attachment 9426643 [details]
Bug 1917536 - Check for Admin and LocalSystem permissions in updater instead of inferring them from a lockfile. r=bytesized,nalexander

Clearing beta and esr128 uplift requests for now. Will need to be reevaluated once this lands again.

Comment 51

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/be6b86852ee8
Check for Admin and LocalSystem permissions in updater instead of inferring them from a lockfile. r=bytesized,nalexander,application-update-reviewers

Comment 52

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5578b6e75ef4
Backed out 6 changesets (bug 1917536, bug 1923376) for causing builb bustages @updater.cpp. CLOSED TREE

Comment 53

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f10b4089ea06
Check for Admin and LocalSystem permissions in updater instead of inferring them from a lockfile. r=bytesized,nalexander,application-update-reviewers

Comment 54

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

https://hg.mozilla.org/mozilla-central/rev/f10b4089ea06

Comment 55

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7dc4f9a38ea9
Backed out 6 changesets (bug 1917536, bug 1923376) for causing bustage @ updater.cpp in mozilla-central CLOSED TREE

Comment 56

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

See bug 1923376 comment 41 for the details about the backout.

Comment 57

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

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/7dc4f9a38ea9

Comment 58

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c703a8a126d9
Check for Admin and LocalSystem permissions in updater instead of inferring them from a lockfile. r=bytesized,nalexander,application-update-reviewers

Comment 59

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

https://hg.mozilla.org/mozilla-central/rev/c703a8a126d9

Comment 60

[justlikebono]

When is the patch for this vulnerability expected to be released?

Comment 61

[Bogdan Maris, Desktop Test Engineering]

(In reply to Bogdan Maris, Desktop Test Engineering [PTO until 13 Jan] from comment #36)

(In reply to Bogdan Maris, Desktop Test Engineering from comment #35)

We started testing on Nightly 133 based on the agreed testing plan, but we are currently blocked by the updates being down on Nightly as per bug 1922546 comment 6

Updates are up again and QA has finished testing Nightly 133 based on the test plan with no issue found.

QA has retested this using Nightly 135 on Windows 11, 10 and 11 ARM, updates work fine in different configurations (see the doc from comment 35. Not sure how is the account from bug 1923376 set up in order to replicate it, but we covered an account with UAC disabled as well during testing and updating worked fine.

Comment 62

[Daniel Veditz [:dveditz]]

(In reply to justlikebono from comment #60)

When is the patch for this vulnerability expected to be released?

It's marked as "fixed in 135" and that is currently planned for February 4.

Comment 63

[Bogdan Maris, Desktop Test Engineering]

(In reply to Bogdan Maris, Desktop Test Engineering from comment #61)

(In reply to Bogdan Maris, Desktop Test Engineering [PTO until 13 Jan] from comment #36)

(In reply to Bogdan Maris, Desktop Test Engineering from comment #35)

We started testing on Nightly 133 based on the agreed testing plan, but we are currently blocked by the updates being down on Nightly as per bug 1922546 comment 6

Updates are up again and QA has finished testing Nightly 133 based on the test plan with no issue found.

QA has retested this using Nightly 135 on Windows 11, 10 and 11 ARM, updates work fine in different configurations (see the doc from comment 35. Not sure how is the account from bug 1923376 set up in order to replicate it, but we covered an account with UAC disabled as well during testing and updating worked fine.

We also tested using Firefox 135 beta builds (5 and 6 updating to 7) across the same platforms (W11, W11 ARM and W10) with the same result.

Comment 64

[Ryan VanderMeulen [:RyanVM]]

Backed out for 135.0rc1 while the investigation of bug 1937806 continues.
https://hg.mozilla.org/releases/mozilla-release/rev/983c92bf7d784b40684da7409a2f72d69a14eec0

Comment 65

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/f5a5a562f9b5

Comment 66

[Pascal Chevrel:pascalc]

Backed out from 136 beta for causing bug 1945654 preventing shipping beta 1.

Comment 67

[Ryan VanderMeulen [:RyanVM]]

I'm confused why the patches in the bug were marked as obsolete. The fix is still present on mozilla-central and ultimately this is a bug we'll still need to uplift to affected branches eventually once we can resolve the regressions caused by it.

Comment 68

[justlikebono]

It has been over five months since the vulnerability was reported.
I understand applying patches for large-scale software such as Firefox is not easy.
Nevertheless, I think the patch should be applied accurately because it can be exploited in a fully backgrounded process.

Comment 69

[Nick Rishel [:nrishel]]

:RyanVM The obsoleted revision was code that was rolled into D225422, I assume we'd uplift that revision stack instead.

:bytesized NI to confirm we'd want that stack over this prior (obsoleted) revision.

Comment 70

[Robin Steuber (she/her) [:bytesized]]

D225422 was built on top of D224395. D225422 does not include D224395. We need both.

Comment 71

[Nick Rishel [:nrishel]]

My bad, misinterpreted what I was seeing in a diff and extrapolated incorrectly. Revision is not reopened.

Comment 72

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

The patch landed in nightly and beta is affected.
:nrishel, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval. Also, don't forget to request an uplift for the patches in the regression caused by this fix.
• If no, please set status-firefox136 to wontfix.

For more information, please visit BugBot documentation.

Comment 73

[justlikebono]

When will a CVE be issued for this vulnerability?

Comment 74

[Nick Rishel [:nrishel]]

:justlikebono See prior response, this was fixed in Fx137 which is currently in Beta.

(In reply to Tom Ritter [:tjr] from comment #32)

... CVEs are assigned when the Firefox version the issue is fixed in is close to release. For similar questions about bounty/cve's please email [e-mail]

Comment 75

[Nick Rishel [:nrishel]]

Attachment: Bug 1917536 - Check for Admin and LocalSystem permissions in updater instead of inferring them from a lockfile.

Original Revision: https://phabricator.services.mozilla.com/D223223

Comment 76

[Nick Rishel [:nrishel]]

Attachment: Bug 1917536 - Check for Admin and LocalSystem permissions in updater instead of inferring them from a lockfile.

Original Revision: https://phabricator.services.mozilla.com/D223223

Comment 77

[Pascal Chevrel:pascalc]

Backed out on beta in bug 1955505 before we enter Release Candidate week as the patch for ESR 115 needs more work and the patch for ESR 128 needs rebasing. If we have backports we are confident with for our older supported ESR branches, we could reconsider it for RCs next week and reland them.

Comment 78

[Phabricator Automation]

esr115 Uplift Approval Request

• User impact if declined: Potential exploit of sec bug.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Install older version of Firefox, trigger update, verify update applies correctly for both elevated and unelevated installs.
• Risk associated with taking this patch: Moderate
• Explanation of risk level: Uncertainty that automated testing coversage is sufficient.
• String changes made/needed: n/a
• Is Android affected?: no

Comment 79

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: Potential exploit of sec bug.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Install older version of Firefox, trigger update, verify update applies correctly for both elevated and unelevated installs.
• Risk associated with taking this patch: Moderate
• Explanation of risk level: Uncertainty that code coversage is sufficient.
• String changes made/needed: n/a
• Is Android affected?: no

Comment 80

[Tom Ritter [:tjr] (OOTO Oct 18-26)]

While we typically do not issue CVEs before things are fixed I'm pre-issuing for this one, this missed the landing for 135 (understandable) but also 136 and now 137 - we need to ensure we have rebased patches and that this sticks in 138.

Comment 81

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/cf51dae8d242

Comment 82

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/00aa6241f022

Comment 83

[Jason Kratzer [:jkratzer]]

Attachment: advisory.txt

Comment 84

[justlikebono]

Hello,

Could you clarify why the term "Potential" was included?
I have successfully demonstrated the exploit along with proof-of-exploit code and even provided a video.
This vulnerability was immediately exploitable, not "potential."

Also, I would appreciate it if you could update my handle from Dong-uk Kim to Dong-uk Kim (@justlikebono).

Thanks,

Comment 85

[Tom Ritter [:tjr] (OOTO Oct 18-26)]

(In reply to justlikebono from comment #84)

Could you clarify why the term "Potential" was included?
I have successfully demonstrated the exploit along with proof-of-exploit code and even provided a video.
This vulnerability was immediately exploitable, not "potential."

That's fair, I've requested the change. We use the attachments to generate a file that will go into https://github.com/mozilla/foundation-security-advisories - so while we may not update the attachment, the resulting advisory will be corrected.

Also, I would appreciate it if you could update my handle from Dong-uk Kim to Dong-uk Kim (@justlikebono).

Can do.

Comment 86

[justlikebono]

(In reply to Tom Ritter [:tjr] from comment #85)

(In reply to justlikebono from comment #84)

Could you clarify why the term "Potential" was included?
I have successfully demonstrated the exploit along with proof-of-exploit code and even provided a video.
This vulnerability was immediately exploitable, not "potential."

That's fair, I've requested the change. We use the attachments to generate a file that will go into https://github.com/mozilla/foundation-security-advisories - so while we may not update the attachment, the resulting advisory will be corrected.

Also, I would appreciate it if you could update my handle from Dong-uk Kim to Dong-uk Kim (@justlikebono).

Can do.

Thank you for your efforts.

Comment 87

[Bogdan Maris, Desktop Test Engineering]

After discussing on slack with :nrishel there will be no manual QA needed here due to complications, we'll rely on automated tests. Dropping qa-verify+

Comment 88

[Tom Ritter [:tjr] (OOTO Oct 18-26)]

Updating title - 'Exploited' implies it was exploited in the wild.