Closed Bug 976266 Opened 11 years ago Closed 5 years ago

infinite loop specifying Firefox as the helper app for a type/protocol Firefox doesn't handle (e.g. telnet:)

Categories

(Firefox :: File Handling, defect)

27 Branch
x86_64
Windows 8
defect
Not set
normal
Points:
8

Tracking

()

RESOLVED DUPLICATE of bug 1496380

People

(Reporter: mayitosj09, Unassigned)

References

Details

(Keywords: csectype-dos, Whiteboard: [DUPEME])

Attachments

(1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Safari/537.36 Steps to reproduce: I wanted to open a telnet address and choose which application to launch, and suddenly firefox chose many tabs opened P.S serves to address any telnet Actual results: Many tabs opened and the browser stopped working Expected results: They wanted to open a link that had shown correctly, P.S excuse the mistakes what happens is that I use google translator
Please visit support.mozilla.org for help with your issue. If there is a bug that needs attention from a developer, they can help you to file a good bug report (steps to reproduce, better symptoms, etc).
Group: core-security
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
Attached file Here I leave the video to see if is a fault (obsolete) (deleted) —
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INCOMPLETE → ---
Flags: sec-bounty?
Flags: sec-bounty?
Status: REOPENED → UNCONFIRMED
Ever confirmed: false
Comment on attachment 8380958 [details] Here I leave the video to see if is a fault The attachment is just the text of the following URL (and isn't a link) http://www.youtube.com/watch?v=ye7YLIOeuJA&feature=youtu.be
Attachment #8380958 - Attachment is obsolete: true
Firefox does not know how to handle the telnet: protocol and when you encounter a protocol or content-type Firefox doesn't know how to handle it asks if you want to use an external program to open the file. If you specify Firefox itself as the handler then when the operating system hands the link to Firefox the browser still doesn't know how to handle this type so it looks for an external handler again. If you check the box so it never asks before doing the action you've then set up an infinite loop. fwiw I don't recommend checking that box: in the benign case it's just an extra click to open up an attachment, and in the malicious case you might have the chance to avoid getting infected if sites suddenly start trying to give you files you weren't expecting because they just found a new zero-day in Word or something. This infinite loop is self-inflicted so it's not a security vulnerability that can be used to attack others. The obvious solution is to not let users specify Firefox as the handler for types Firefox doesn't know how to handle, but we share some of that UI with the case of sites using the content-disposition header to force a download of a type Firefox _does_ know how to handle so that might be annoying. The next solution that comes to mind is to ignore the "don't ask me" option on helper apps for URLs that were themselves loaded from the command-line. Hopefully most people who know enough to have gotten themselves into such a loop would also know how to kill the runaway Firefox process in the task manager. I doubt this happens enough in practice to be prioritized over fixing other bugs. I recall people pointing this out before, we probably already have a bug on this.
Status: UNCONFIRMED → NEW
Component: Untriaged → File Handling
Ever confirmed: true
Keywords: csectype-dos
Summary: error opening telnet links → infinite loop specifying Firefox as the helper app for a type/protocol Firefox doesn't handle (e.g. telnet:)
Whiteboard: DUPEME
Flags: firefox-backlog+
Whiteboard: DUPEME → [DUPEME] p=8
Points: --- → 8
Whiteboard: [DUPEME] p=8 → [DUPEME]

This was fixed on the nightly branch on Windows and Mac in bug 1496380.

Status: NEW → RESOLVED
Closed: 11 years ago5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: