Closed Bug 1873223 (CVE-2024-1555) Opened 1 year ago Closed 1 year ago

FireFox Same Site "Strict" Cookie Bypass via firefox/firefox-private protocol/schemes registered with the OS and using an external browser

Categories

(Firefox :: Installer, defect)

Desktop
All
defect

Tracking

()

RESOLVED FIXED
124 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox121 --- wontfix
firefox122 --- wontfix
firefox123 + fixed
firefox124 + fixed

People

(Reporter: iamnarendrabhati, Assigned: nipunshukla002)

References

(Regression)

Details

(Keywords: regression, reporter-external, sec-moderate, Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main123+])

Attachments

(2 files)

Dear Team,

Here are the vulnerability details.

Description
SameSite is an attribute that can be set for cookies in web browsers. It is used to control how cookies are sent with cross-site requests. The SameSite attribute helps mitigate the risk of cross-site request forgery (CSRF) attacks and protects user privacy.

There are three possible values for the SameSite attribute:

  1. Strict: When a cookie has the SameSite=Strict attribute, it will only be sent in a first-party context. This means that the cookie will only be sent if the request originates from the same site as the one that set the cookie.

    Example:

    Set-Cookie: mycookie=myvalue; SameSite=Strict;
    
  2. Lax:With SameSite=Lax, cookies are allowed to be sent with top-level navigations and safe HTTP methods (like GET), but they will not be sent when the request is initiated by a third-party website through methods such as a cross-origin POST request.

    Example:

    Set-Cookie: mycookie=myvalue; SameSite=Lax;
    
  3. None: Setting SameSite=None allows cookies to be sent with both first-party and third-party requests. This is often used for scenarios where the cookie needs to be sent across different domains, such as when embedding content from one site into another.

    Example:

    Set-Cookie: mycookie=myvalue; SameSite=None; Secure;
    

Uses of Same Site Cookies
CSRF Protection: CSRF attacks involve an attacker tricking a user's browser into making an unintended request to a different site where the user is authenticated. If cookies are sent automatically with every request, the attacker could exploit this to perform unauthorized actions on behalf of the user. SameSite helps mitigate this risk by preventing cookies from being sent in certain cross-site scenarios.

What is Browser Fails to Protect Same Site Cookies
If a browser fails to properly enforce the SameSite=Strict attribute for cookies, it can have security implications, particularly in the context of cross-site request forgery (CSRF) attacks. Here are the potential impacts:

  1. CSRF Vulnerability: The primary purpose of SameSite=Strict is to protect against CSRF attacks by preventing cookies from being sent in cross-site requests. If a browser fails to enforce this attribute, it could expose users to CSRF vulnerabilities. An attacker might be able to initiate unauthorized actions on behalf of a user if their cookies are automatically included in requests to a different site.
    Ex. Daps Website/Program run inside firefox website, might have using SameSite cookie protection (now days most of them are doing it for CSRF protection) Now developer will think that because they have used SameSite Strict cookies, they are safe from CSRF attacks but because of this bypass they are still vulnerable.

  2. Unauthorized Actions: CSRF attacks typically involve tricking a user's browser into performing actions on a target site without the user's consent. If SameSite=Strict is not enforced, an attacker could potentially perform actions, such as changing the user's account settings, making financial transactions, or performing any action that the user is authorized to do on the target site.

  3. Cross-Site Tracking: SameSite=Strict also enhances privacy by preventing automatic cookie inclusion in cross-site requests. If this protection is not in place, third-party sites may have increased visibility into users' activities across different domains, leading to potential tracking and profiling.

  4. Reduced Security by Design: SameSite=Strict is designed to be a security measure by default. If a browser fails to enforce it, the security posture of the web becomes weakened, as developers may rely on this protection when building and securing web applications.

Tested On
Windows 11 Pro
FireFox Window Version 121.0

The POC
Video https://drive.google.com/file/d/12SSLaTQHiNWHYt-53zC3yPO3_NjGLrg7/view?usp=sharing
POC Exploit Codes - Readily available below
https://g00gle.in/samefirefox/ss.php
https://g00gle.in/samefirefox/ss.html
https://g00gle.in/samefirefox/attacker.html

1.Browse https://g00gle.in/samefirefox/ss.php and First click on 1) FirstSet Same Site Cookie Button which will create the same site strict cookie name as SecretCookie and its value as IUHUIGIGAIIGIGUIGSUIGIGIGSIGUIGUIFFTFDTRFYVUVBHJBHJ for website https://com.egghunter.in
2. Go back and now click on 2 ) Verify Same Site Cookie Are Se now because the cookies are set as Strict you won't find them request to https://com.egghunter.in this is how FireFox browser is protecting user from CSRF Attacks because g00gle.in is cross domain which is requesting to "com.egghunter.in" both are cross domain so Strict Cookie won't be pass.
3. Now from Google Chrome browse this https://g00gle.in/samefirefox/attacker.html , there will be button to "Open In FireFox" open it and click on Open in prompt.
4. It will redirect from chrome to firefox with URL pointing to https://com.egghunter.in/showcookie.php but this time the SameSite cookies are sent to that server, which shows we bypass the SameSite cookie protection of firefox browser.

Suggestion
Do not send the same site a strict cookie via deeplink.

CVSS Score

  1. Attack Vector (AV): Network (N)

    • Reason: The attack is conducted remotely, targeting the network. This aligns with the scenario where a browser fails to protect SameSite=Strict cookies, and an attacker can exploit the vulnerability remotely.
  2. Attack Complexity (AC): Low (L)

    • Reason: Exploiting the failure in SameSite=Strict is not particularly complex and can be achieved with relatively low effort.
  3. Privileges Required (PR): None (N)

    • Reason: The assumption is that the attacker does not require any specific privileges to exploit the vulnerability. The attack can be carried out with minimal access.
  4. User Interaction (UI): Required (R)

    • Reason: Victim needs to interact with attacker URL.
  5. Confidentiality (C): High (H)

    • Reason: The failure to protect SameSite=Strict cookies can lead to a high impact on confidentiality, potentially exposing sensitive information (cookies).
  6. Integrity (I): High (H)

    • Reason: The integrity of the system is highly impacted by the vulnerability, as the attacker can tamper with data or perform unauthorized actions using CSRF attack which is most important part of introducing same site cookies.
  7. Availability (A): Low (L)

    • Reason: The assumption is that while the vulnerability has an impact on availability, it is not as severe as the impacts on confidentiality and integrity. The focus is on data manipulation rather than denial of service.

Impact

  1. CSRF Vulnerability: The primary purpose of SameSite=Strict is to protect against CSRF attacks by preventing cookies from being sent in cross-site requests. If a browser fails to enforce this attribute, it could expose users to CSRF vulnerabilities. An attacker might be able to initiate unauthorized actions on behalf of a user if their cookies are automatically included in requests to a different site.

  2. Unauthorized Actions: CSRF attacks typically involve tricking a user's browser into performing actions on a target site without the user's consent. If SameSite=Strict is not enforced, an attacker could potentially perform actions, such as changing the user's account settings, making financial transactions, or performing any action that the user is authorized to do on the target site.

  3. Cross-Site Tracking: SameSite=Strict also enhances privacy by preventing automatic cookie inclusion in cross-site requests. If this protection is not in place, third-party sites may have increased visibility into users' activities across different domains, leading to potential tracking and profiling.

  4. Reduced Security by Design: SameSite=Strict is designed to be a security measure by default. If a browser fails to enforce it, the security posture of the web becomes weakened, as developers may rely on this protection when building and securing web applications.

Flags: sec-bounty?

Reporter: Does clicking the same "Open in Firefox" link from within Firefox not achieve the same thing?

:mhughes / :nshukla: this protocol handler is new. What is its purpose? I can't tell from bug 1862450. Would it be OK if we used null principal for this type of load?

Status: UNCONFIRMED → NEW
Component: Security → Installer
Ever confirmed: true
Flags: needinfo?(nshukla)
Flags: needinfo?(mhughes)
Flags: needinfo?(iamnarendrabhati)
Keywords: regression
OS: Unspecified → All
Regressed by: 1862450
Hardware: Unspecified → Desktop
Summary: FireFox Same Site "Strict" Cookie Bypass → FireFox Same Site "Strict" Cookie Bypass via firefox/firefox-private protocol/schemes registered with the OS and using an external browser

The purpose of the protocol handler is to enable a Chromium extension to open websites in Firefox. I’m unfortunately not familiar with the fundamentals of null principal but as long as it still enables a system app to open a site in Firefox through the protocol there shouldn’t be any issues.

Flags: needinfo?(nshukla)

@Gijs - No, it does not work when clickingg the same "Open in Firefox" link from within Firefox infact by clicking from firefox even does not open a normal URL like this "<a href="firefox://google.com">Open in Firefox</a>" looks like from firefox only we can call firefox but from external apps (What we seen this bug) we can call firefox.

But even if we call firefox from any other app like Chrome or something the bug is sill there, same site strict cookies are getting passed which is not an expected behaviour.

Flags: needinfo?(iamnarendrabhati)
Assignee: nobody → nshukla
Status: NEW → ASSIGNED

@Gijs @Nipun Shukla - Filled a new report https://bugzilla.mozilla.org/show_bug.cgi?id=1873364 for FireFox Focus iOS where, POC works within browser as well which means, clicking the same Prompt Link from within Firefox Focus will achieve the same thing.

(In reply to Narendra Bhati from comment #3)

infact by clicking from firefox even does not open a normal URL like this "<a href="firefox://google.com">Open in Firefox</a>"

Are you deliberately leaving out the http/https bits here, and/or does that make a difference? (Id est, in a quick test, using firefox:https://google.com/ on my mac at least shows me the "do you want to open this with Firefox Nightly" prompt when opened from Firefox beta.).

What do you mean by "does not open a normal URL"? And what happens instead? (if "nothing" when clicked, can you check the browser console?)

looks like from firefox only we can call firefox

Who is "we" here / what do you mean?

Flags: needinfo?(mhughes) → needinfo?(iamnarendrabhati)

Reply to Comment6 - Gijs

Yes, I tried "firefox:https://google.com" as well and it shows the prompt "do you want to open this with Firefox" from firefox but after clicking nothing happenes.

This only works when user call "firefox:https://google.com" from external browser.

"Who is "we" here / what do you mean?"
Sorry for the confusion, when I explain anything I mostly use WE keyword. We means I as an user.

Flags: needinfo?(iamnarendrabhati)

I did a bit of investigation around this -- it seems to always work when you're going from any external application to Firefox. That could be from Firefox Beta to Nightly like in Gijs example. However, if you put firefox:https://www.google.com in the Firefox install which receives the protocol (the one that would've launched) then this error is printed in the terminal:

JavaScript error: resource://gre/modules/ContentDispatchChooser.sys.mjs, line 117: NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIHandlerInfo.launchWithURI]

On a surface glance, this seems more like a (non-sec) issue in our original launchWithURI function than anything else. It looks like it doesn't know what to do when it tries to launch itself, although I haven't gone deeply enough in the code of that function yet to figure out where exactly it's failing. I also haven't filed a bug for it yet as I'm not entirely aware of the protocol when filing a non-sec bug that was found in a security issue. I think it wouldn't be an issue but I'll hold off until someone can confirm that for me.

:Nipun Shukla we are near the end of the beta cycle. 122.0b9 builds on 2024-01-12.
Though the patch is pending review, any concerns with timing/risk on an uplift for Fx122?

Flags: needinfo?(nshukla)

I think it should still be possible to have it ready for uplift by Beta 9. However, if reviews take longer or if some unforeseen issues arise what would be the best course of action? Would this be a candidate for a release uplift into a 122 dot release or would it instead be landed onto 123?

Flags: needinfo?(nshukla) → needinfo?(dmeehan)

It would be Fx123

Flags: needinfo?(dmeehan)

(In reply to Nipun Shukla from comment #8)

I did a bit of investigation around this -- it seems to always work when you're going from any external application to Firefox. That could be from Firefox Beta to Nightly like in Gijs example. However, if you put firefox:https://www.google.com in the Firefox install which receives the protocol (the one that would've launched) then this error is printed in the terminal:

JavaScript error: resource://gre/modules/ContentDispatchChooser.sys.mjs, line 117: NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIHandlerInfo.launchWithURI]

On a surface glance, this seems more like a (non-sec) issue in our original launchWithURI function than anything else. It looks like it doesn't know what to do when it tries to launch itself, although I haven't gone deeply enough in the code of that function yet to figure out where exactly it's failing. I also haven't filed a bug for it yet as I'm not entirely aware of the protocol when filing a non-sec bug that was found in a security issue. I think it wouldn't be an issue but I'll hold off until someone can confirm that for me.

I know this one!

This is the result of some hacky code I added. Basically it does this to (attempt to) force a prompt that asks "what do you want to do with this protocol", because if we keep launching ourselves recursively with the same URI, that goes badly (e.g. bug 215554 and all its dupes).

See also: https://searchfox.org/mozilla-central/rev/52f45d12530f9f8da61c6c7237003b5d1499b6d1/toolkit/mozapps/handling/ContentDispatchChooser.sys.mjs#86-93 and https://searchfox.org/mozilla-central/rev/52f45d12530f9f8da61c6c7237003b5d1499b6d1/uriloader/exthandler/nsMIMEInfoImpl.cpp#366-382 .

Too late for 122.0, switching tracking to Fx123

Pushed by nshukla@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/41378df4fd06 Modified firefox and firefox-private protocol handler behavior r=Gijs,mhughes
Group: firefox-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 124 Branch

Dear All, Just a request. Please refrain from making the details of the recent bug public for the next few months. Other browsers are also vulnerable, and their teams are working on fixes. This measure aims to prevent potential misuse of the vulnerability. Your cooperation is appreciated.

Flags: sec-bounty? → sec-bounty+

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

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox123 to wontfix.

For more information, please visit BugBot documentation.

Flags: needinfo?(nshukla)
Flags: needinfo?(nshukla)
Flags: needinfo?(nshukla)

Comment on attachment 9371396 [details]
Bug 1873223 - Modified firefox and firefox-private protocol handler behavior r=Gijs,mhughes

Beta/Release Uplift Approval Request

  • User impact if declined: This is a security issue that could conceivably expose user data if same site cookies aren't correctly protected. It's also rated as sec-moderate so it's ideal if we can
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): There is a risk that in cases where the system principal should be used, a null principal is used instead. This is furthered by the lack of automated testing in this area. However, it has been tested extensively locally by multiple people so the risk isn't very high.
  • String changes made/needed:
  • Is Android affected?: Yes
Flags: needinfo?(nshukla)
Attachment #9371396 - Flags: approval-mozilla-beta?

Comment on attachment 9371396 [details]
Bug 1873223 - Modified firefox and firefox-private protocol handler behavior r=Gijs,mhughes

Approved for 123 beta 4, thanks.

Attachment #9371396 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [post-critsmash-triage]
Flags: qe-verify-
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][adv-main123+]
Attached file advisory.txt
Alias: CVE-2024-1555
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: