1837916 - (CVE-2024-0953) Firefox for iOS QR Code Scanner does not show the URL for user confirmation before opening it

Status: NEW

(Firefox for iOS :: General, defect)

Description

[Lohith Gowda M]

The QR Code Scanner feature in the Firefox iOS app is vulnerable to an open redirect attack. This vulnerability allows an attacker to redirect users to malicious websites or URLs, potentially leading to phishing attacks or the disclosure of sensitive information.

Steps To Reproduce:

1. Launch the Firefox iOS app.
2. Navigate the QR code scanner in the Home page search bar (Top Right Side)
3. Scan a QR code that contains a specially crafted URL with an external domain.
4. Create a QR Code with a specially crafted URL using https://www.the-qrcode-generator.com/
5. Scan a QR code that contains a specially crafted URL with an external domain.
6. Observe that the app redirects to the external domain without proper validation or user consent

Fix:

• The QR Code Scanner should validate the URL before redirecting users.
• Implement proper input validation and URL verification in the QR Code Scanner feature to prevent open redirect vulnerabilities.
• Apply the same fix for iOS and Android

Impact:

• This vulnerability could be exploited by attackers to trick users into visiting malicious websites, potentially leading to the theft of personal information, financial fraud, or other security risks.

Supporting materials/ references:

• https://hackerone.com/reports/1946534

Comment 2

[:Gijs (he/him)]

The point of a QR code is to point to an arbitrary URL. So I don't understand this report - what would "proper input validation" even look like? The browser cannot determine whether the URL is safe on the user's behalf, and/or if it's the URL the user was expecting.

What do other browsers do here?

Comment 3

[Lohith Gowda M]

Hi Gijs,
Thanks for your update. The issue here is, the browser is not verifying the QR Code content. It directly redirects the user to an external domain, without any consent. The browser should validate the QR content. If the QR code contains any type of URL, it should show a Popup or consent on the screen, before redirecting to another site.

Here is one example for your reference. This issue fixed on Brave Browser https://hackerone.com/reports/1946534

Also, I have verified other browsers like Chrome, and Yandex. They strictly validate the Content. In crime, They’re not directly redirecting to another site. Thye just adding data to the browser. If the user is okay with that content, then only it will redirect to an external site. Please find the below detailed video. You can see the difference between Crome and Firefox Video POC

https://youtube.com/shorts/79Rkcr5e17A

Comment 4

[:Gijs (he/him)]

(In reply to Lohith Gowda M from comment #3)

https://youtube.com/shorts/79Rkcr5e17A

This only shows the behaviour in Chrome, and not on Firefox. Did you mean to provide a second link showing what happens on Firefox?

I do not have an iDevice to test with. On Android Firefox, a prompt shows up asking if the navigation should be allowed.

Comment 5

[Lohith Gowda M]

Hi Gijs,
Thanks for your quick validation. I have verified it on Android and it shows prompts to the user. So, android is not vulnerable. But in iOS it directly redirects to the external site. I already attached a video POC. You can find the same video here. Kindy check

https://youtube.com/shorts/VLx3TPUezkk

Please let me know if you’ve any questions.

Comment 6

[Daniel Veditz [:dveditz]]

Changing title to avoid the "open redirect" term (generally a web site bug involving literal HTTP 3XX redirects)

I like the clarity of the Firefox for Android prompt over the Chrome behavior ("why did my browser stop opening this half-way?"), but one advantage to chrome is the user could copy the URL to use somewhere else without having to open the site. The built-in Android QR reader (or at least the one on Samsung Galaxies) has a prompt like Firefox, but with both "open" and "copy" options.

That's more about usefulness than security. A prompt would be better, but in the case of an actual malicious URL the user isn't going to have a chance. At best the user could know "I've been to that site before" or "a .gov address sounds legit". QR codes are often from ads or informational signs and would likely be expected by the user to go to sites they don't know.

Comment 7

[Daniel Veditz [:dveditz]]

I don't know how this and bug 1837917 both got the "[client-bounty-form]" whiteboard without a corresponding sec-bounty? flag. Since the bounty team almost exclusively uses the flag that could be quite bad if the form is broken somehow.

Was this bug intended to be a bug bounty request, or did you clear that flag yourself on purpose?

Comment 8

[Lohith Gowda M]

Hi Daniel Veditz,
Have you verified the issue? This is the bug bounty submission. Not an issue related to performance or design changes. Kindly treat this report as Bug Bounty Report

Let me know if you need more details on this report

Comment 9

[Lohith Gowda M]

Hi Team,
Should I report this issue through HackerOne?

Comment 10

[Andrew McCreight [:mccr8]]

This is the correct place to report Firefox security issues.

Comment 11

[Lohith Gowda M]

Great. Thanks for the update. Let me know if you need more details on this vulnerability

Comment 12

[Lohith Gowda M]

Hi Team,
Any updates here?

Comment 13

[Lohith Gowda M]

Hi Andrew McCreight,
Have you verified the issue?

Comment 14

[:Gijs (he/him)]

(In reply to Lohith Gowda M from comment #13)

Hi Andrew McCreight,
Have you verified the issue?

It isn't reasonable to ping bugs every [other] day to ask for updates. Please stop. Any updates will appear explicitly on the bug - we don't have some kind of "secret" second bugtracker whose updates we are withholding from you. If there is no update on the bug, that means there is no update, and asking for one is just annoying and doesn't yield any additional information.

Comment 15

[Lohith Gowda M]

I don’t understand your triage process and this form. At least let me know whether this is a valid vulnerability.

Comment 16

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

The severity field is not set for this bug.
:jeevans, could you have a look please?

For more information, please visit BugBot documentation.

Comment 17

[Lohith Gowda M]

Any updates here?

Comment 18

[Daniel Veditz [:dveditz]]

(In reply to Lohith Gowda M from comment #15)

I don’t understand your triage process and this form. At least let me know whether this is a valid vulnerability.

The issue Status was changed from "UNCONFIRMED" to "NEW" on 2023-06-12, which means at least one person—me, in this case—agrees that what you reported is real. If we thought it was not a valid issue the Resolution would have been changed from "Open" to "Invalid".

To be clear I only confirmed part of your initial claim. As I mentioned at the time, I changed the summary of the bug to focus on the part I considered valid and worth fixing. Specifically you said:

Observe that the app redirects to the external domain without proper validation or user consent

• I disagreed with the use of the term "redirect" in this context, but browser redirects are common and not an attack anyway
• You have presented no evidence for "without proper validation"
  • We definitely do validation and reject some URLs
  • What do you consider "proper"?
  • What URL does Firefox open that you think validation should have rejected?
    • you can put plain links in a comment here
    • or screenshot the QR codes and attach them to this issue as images
    • Specific examples are important so we can determine whether we disagree about "proper validation" or if you have found an unintentional defect in our validation
    • Please explain why those URLs are a "vulnerability" rather than simply a different choice made by browser vendors?
• I agreed there is no user consent and that it would be better if it had that

Is it a "vulnerability"? IMHO it's borderline; some could argue it's a usability enhancement instead. I lean toward "minor vulnerability". The shift to the user consent model in browsers might lead users to assume Firefox for iOS works the same way. As a result they might be less careful about scanning codes in dodgy locations because they expect to get a chance to inspect it before opening it. Notice those two sentences are speculative: no one has done any user studies on this. Also note that any website can send you to any arbitrary URL at any time with zero user interaction—unlike the multiple steps required to scan and open a QR code. The real worry (for me) is when QR codes are allowed to load kinds of URLs that web sites are not allowed to load (our validation code is largely focused on that potential attack).

Any updates here?

Please stop asking if there are updates. If you don't see any updates then there are no updates. There are a lot of bugs our developers have to juggle and it will be a while before anyone has time to work on this.

Comment 19

[Lohith Gowda M]

Hi Daniel Veditz,

Thanks for your detailed justification. Actually, I have already given the proper evidence. You can find the same here --https://youtube.com/shorts/VLx3TPUezkk . In this POC I have demonstrated How victims can redirect malicious sites without any user confirmation before opening a scanned URL. This issue only exists in ioS Application. I have tried the same thing on Android as well. But in Android, the user will get a consent prompt. So no issues in Android Opera. You have to fix the issue on Opera ioS Application.

The same issue is on Brave Browser as well. They fixed the issue. You can find the HackerOne Report for your Reference: https://hackerone.com/reports/1946534

Comment 21

[Daniel Veditz [:dveditz]]

We don't need to keep this hidden: the Brave report is public, we've gotten multiple submissions, and it's just generally known as "best practice" for a QR reader these days (to prevent e.g. Rick Rolls or worse surprises)

Comment 22

[Lohith Gowda M]

Can I get the CVE for this Vulnerability?

Comment 23

[Andrew McCreight [:mccr8]]

(In reply to Lohith Gowda M from comment #22)

Can I get the CVE for this Vulnerability?

Questions about CVEs or bug bounties are better directed via email to [e-mail] rather than in the bug, because the people who work on those may not see your questions here.

Comment 25

[Lohith Gowda M]

May I know When this CVE will be a going to publish? How much time it will take for the issue to be fixed?

Comment 26

[Tom Ritter [:tjr]]

Attachment: advisory.txt