1842766 - (CVE-2023-4579) Persisted search terms get formatted as URL

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[Malte Jürgens [:maltejur]]

Attachment: Screenshot_20230711_111307.png

To reproduce:

1. Set DuckDuckGo as the default search engine
2. Search anything on DuckDuckGo
3. On the same page, enter https://addons.mozilla.org/en-US/firefox/ in the search box on the site and press enter

Expected Result: It is clear to the user that the content of the address bar is a search term, not the current URL.

Actual Result: The search term is being formatted as if it were a URL (see screenshot).

I don't think that this is that big of a big problem security-wise, because the search engine has to be the default and the page has to be loaded by the user entering a search term directly in Firefox. But if a malicious search engine could gain access to being set as the default, it could possibly abuse this, since it seems to me that the site itself can set the search query on its own once the page is loaded by a user search query.

A possible solution could be to remove the formatting from the address bar if it contains a search term, or, going one step further, also displaying an icon, like a magnifying glass, before the text, indicating that it is a search term.

Comment 1

[Marco Bonardo [:mak]]

Thank you for reporting, this doesn't look good indeed and should be fixed ASAP.

Comment 2

[Frederik Braun [:freddy] (OOO until August 18th)]

Agreed that this should be fixed soon.
Rating as sec-moderate as per https://wiki.mozilla.org/Security_Severity_Ratings/Client. We usually treat URL spoofs as sec-high, but this involves atypical user interaction.

Comment 3

[James Teow [:jteow]]

A possible solution could be to remove the formatting from the address bar if it contains a search term, or, going one step further, also displaying an icon, like a magnifying glass, before the text, indicating that it is a search term.

IMO, regardless of the formatting, I don't think a URL that differs from the search page should show in the urlbar unless it is in an invalid pageproxystate (aka, only the magnifying glass is visible). Because even without the formatting, I could see it being confusing to users, what with the collection of security icons.

This issue can also be reproduced with other SERPs using search mode with the default engine. And having a term that looks like a origin without a protocol can trigger it too, such as searching www.nytimes.com

As for just showing a magnifying glass next to it, previously, we showed the urlbar in an invalid pageproxystate when search terms were visible, but because we had complaints about hiding the other icons, we had to find a middle ground of showing the other security icons along with the search term. Thus we landed on valid pageproxystate when the urlbar is non-focused, and invalid when it is focused.

One solution I would prefer would be to not show the search term in the urlbar if it looks like it could be interpreted as a URL, specifically if it is a single word that contains one or more periods and/or starts with either http:// or https://. Such a solution would cause situations where words like www. wouldn't show up as a search term unless it was followed by another word separated by a space, but I feel like that's a worthwhile tradeoff. I'll talk with product to get their opinion on this.

Comment 4

[Marco Bonardo [:mak]]

I like the idea of not showing search terms if they are interpreted as a url, though note that because of stripping "mozilla.org/test" will be formatted as a URL as well. So you should use the same code as formatting to discern what to do.
In this case just disabling formatting may not be sufficient since the whole url will then be shown as normal white/black test; not all the users can distinguish the difference between formatted and not formatted urls. Long term we should evaluate better ways to distinguish url mode from edited mode.

Comment 5

[James Teow [:jteow]]

Attachment: Bug 1842766 - r?adw

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d527a0783112
r=adw

Comment 7

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

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

Comment 8

[Cristian Baica [:cbaica], Release Desktop QA]

I've managed to reproduce the issue using Fx117.0a1 2023-07-11.
The issue is verified fixed using Fx118.0a1 and Fx117.0b1 on Windows 10. The full URL is displayed when using websearch with a URL input.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

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

Comment 10

[James Teow [:jteow]]

Hey Ryan, I'm not familiar about when to nominate for ESR, especially since this is my first SEC patch.

The feature is only enabled in Nightly, and a subset of people on Release (users enrolled in an experiment). I'm just wondering for features that are not on by default do we still try to land patches for ESR before they are officially enabled in the future on release? Is it possible some people were enrolled in one of the experiments starting in 113 and were transitioned to ESR 115?

Comment 11

[Ryan VanderMeulen [:RyanVM]]

If the feature isn't enabled by default on ESR and we aren't running experiments there, we don't need to uplift. Thanks for checking!

Comment 12

[June Wilde (she/her) [:jewilde]]

Attachment: advisory.txt