Firefox Search Bar unexpectedly tries to launch nonsense protocol handler due to protocols in handlers.json
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: cowthecows, Unassigned)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file)
38.69 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0
Steps to reproduce:
I have this error from terminal and I copy and then paste in the Firefox Search Bar(snap package Ubuntu 22.04.1 LTS).
This is the link/string I used:
greenlet.c:538:17: error: %E2%80%98PyThreadState%E2%80%99 {aka %E2%80%98struct _ts%E2%80%99} has no member named %E2%80%98use_tracing%E2%80%99; did you mean %E2%80%98tracing%E2%80%99
Actual results:
What happened is that when I tried to search Ubuntu Software showed up and said "No apps available". This resulted in a possible XSS that if crafted very professionally it could be used to do harm.
Expected results:
It should have treated it like another string to search or a domain.
Comment 1•2 years ago
|
||
Can you reproduce this with a Mozilla-built version of Firefox downloaded from https://www.mozilla.org/firefox ? I can't reproduce this on mine. If you're using the Ubuntu version it's possible they have different default settings which could be a problem.
If you don't explicitly say you want a search (by using the separate search box, or selecting a searching in the drop-down) then Firefox has to guess. The stuff you pasted starts with allowed characters and then a ':' which syntactically could be a URL. In this case Firefox would check whether that protocol ("greenlit.c" in this case) is known to Firefox (no) or the Operating System (should be no in this case!). If it is known then it will ask if you want to launch the external program, and by default Firefox should ALWAYS ask first. If it's not known then Firefox will do a search.
"greenlit.c" is obviously not a real protocol. At least, obvious to a person; Firefox has to ask the OS. Is Ubuntu telling Firefox "yes I know what that is" for every bit of nonsense we ask about?
Is Ubuntu's version of FIrefox set to launch external protocols without asking first?!
Updated•2 years ago
|
Comment 2•2 years ago
|
||
(In reply to Ricky Low from comment #0)
What happened is that when I tried to search Ubuntu Software showed up and said "No apps available". This resulted in a possible XSS that if crafted very professionally it could be used to do harm.
I don't see how this is an XSS - nothing executes inside a site's permissions area. We open a local app because that's associated with a protocol. That could do harm if the local app doesn't deal with its input correctly, but that problem shouldn't be web-reachable without further confirmation (there will be a permissions prompt if a website tries to open a protocol like this; there isn't one because you put it in the address bar yourself - we can't stop the user opening apps themselves!).
I expect the root cause of the bug is some variation of bug 1618094.
Comment 4•2 years ago
|
||
(In reply to :Gijs (he/him) from commen
I expect the root cause of the bug is some variation of bug 1618094.
This issue might be caused by recent changes to mitigate bug 1618094. It sounds similar to the complaint in https://bugzilla.mozilla.org/show_bug.cgi?id=1618094#c60 that:
Now there is the opposite problem of not being able to easily register a new protocol
Comment 5•2 years ago
•
|
||
(In reply to Will Shanks from comment #4)
This issue might be caused by recent changes to mitigate bug 1618094.
It's likely the protocol, as opened, is in handlers.json
There's no easy way to remove stuff from there, apart from deleting the file and letting Firefox generate a new one.
It sounds similar to the complaint in https://bugzilla.mozilla.org/show_bug.cgi?id=1618094#c60 that:
Now there is the opposite problem of not being able to easily register a new protocol
Yeah, the way to fix this bug is likely to remove handlers.json, though the problem of not easily registering new protocols still exists.
Comment 6•2 years ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:stransky, since the bug has recent activity, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Comment 8•1 year ago
|
||
Description
•