331334 - DoS / security-dialog-badgering with the external-protocol dialog

Status: RESOLVED DUPLICATE of bug 167475

(Firefox :: File Handling, defect)

Description

[Mike]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

check out what happens http://www.mikerosoftware.com/blah.jpg , zipped exploit http://www.mikerosoftware.com/Files/test.rar
IT has to do with flooding requests to open programs.

Reproducible: Always

Comment 1

[Jo Hermans]

works for me, both opening directly, and saving to disk
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Comment 2

[Daniel Veditz [:dveditz]]

The testcase, should it go away, consists of hundreds of lines of
  <iframe src="telnet:127.0.0.1"></iframe>
which creates a denial-of-service condition with the protocol check dialog along the lines of "while(true) alert('ha ha ha');"

CC'ing Jesse -- would people be badgered into agreeing to allow it all the time? Maybe we should remember the state for the current load group regardless of the "always" option, though I'm not sure how we'd store that information.

If you Exit the app (from another window) while you're in the DoS state the app crashes. I got TB16696740.

Comment 3

[Mike]

(In reply to comment #2)
> The testcase, should it go away, consists of hundreds of lines of
>   <iframe src="telnet:127.0.0.1"></iframe>
> which creates a denial-of-service condition with the protocol check dialog
> along the lines of "while(true) alert('ha ha ha');"
> 
> CC'ing Jesse -- would people be badgered into agreeing to allow it all the
> time? Maybe we should remember the state for the current load group regardless
> of the "always" option, though I'm not sure how we'd store that information.
> 
> If you Exit the app (from another window) while you're in the DoS state the app
> crashes. I got TB16696740.
> 

Just wanted to let you know it will work with YMSGR: , IRC: , and any other 3rd pty. Links that have urls that need to be opened with another program other then   firefox. Mike

Comment 4

[Jesse Ruderman]

> Would people be badgered into agreeing to allow it all the time?

I'd guess yes.  That is, I think a significant percentage of people who initially click "Cancel" in that dialog would click "Launch application" or "Always launch application" if they found themselves in an infinite loop with the dialog.

I can think of several possible solutions, but I don't really like any of them.

A) If the user says "no" to any security dialog, turn all future security dialogs in the same browser session into yellow bars.  (I don't think it's safe to limit this protection to a specific security dialog, a specific external protocol, a specific hostname, or even a specific tab.)  Certain user actions, such as clicking a yellow bar, could reset this protection.

B) Add a "Make it stop!!!" button to all security dialogs (similar to bug 61098).

C) Make it possible to switch tabs, close tabs, and close windows even when a security dialog is visible (similar to bug 59314).  (This would turn pop-up blocking holes into security holes.)  (This has the disadvantage that people might not know they can close the tab to get rid of the security dialog.)

D) Only allow sites to pose security dialogs when they'd be allowed to open popups, and then only one at a time.  (This would also turn pop-up blocking holes into security holes.)

E) Eliminate security dialogs, replacing each one with one of the following:
* Error page (e.g. for SSL errors)
* Yellow bar
* Non-modal window (e.g. for external-protocol links?)
* Automatic accept
* Automatic accept when popups would be allowed, automatic reject otherwise
* Automatic reject

Comment 5

[Jesse Ruderman]

> If you Exit the app (from another window) while you're in the DoS state the 
> app crashes. I got TB16696740.

Sounds like bug 315254.

Comment 6

[Mike]

Ok , Im not sure if this will also help you. I also found that by denying the type of request for good , clicking the check box. You still get the crash. Also , since im obviously not going to get the cash for posting this bug , can I still get a T-Shirt and I really need the cash by the way. I am new to exploiting but im sure you will here for me much more. Thanks and hope the above info will help you more in figureing out A) B) C) D ) etc..             Mike. 
              P.S. Next bug I find will be ROOT ACCESS , I will make a calc.exe POC also. To gurantee the cash of course. I do like mozilla's Firefox browser and I encourage the fight for more secure software.

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to comment #6)
> Also , since im obviously not going to get the cash for posting this bug,

The main part of the bug, the DoS aspect, is not eligible for a bounty (see the FAQ). The crash is...interesting. We're still evaluating that part.

Comment 9

[Mike]

My bug is fixed , where is my T-Shirt??

Comment 10

[Samuel Sidler (old account; do not CC)]

dveditz checked this bug and the crash wasn't exploitable. Taking it out of security sensitivity.

Comment 12

[Jesse Ruderman]

> D) Only allow sites to pose security dialogs when they'd be allowed to open
> popups, and then only one at a time.  (This would also turn pop-up blocking
> holes into security holes.)

Jonas Sicking points out that the "only one at a time" bit can be limited to the case where a user has clicked "No" or "Cancel" in a security dialog.  So if you click "Yes", the site can pose another security dialog, but if you click "No", it doesn't get to badger you until you click part of the page again.

Comment 13

[Jesse Ruderman]

The badgering issue is [sg:moderate] because:

* Infinite loops of security dialogs give sites a way to hold users hostage until they give into a site's demands.  We've seen malicious sites do exactly this with ActiveX.  Users who do not know how to force-quit applications or power-cycle their laptops are especially vulnerable.

* An attacker can combine badgering with other bugs to increase the chance of convincing a user to click "Yes".  These other bugs, alone, would be considered [sg:moderate] or [sg:low] or even SEP.

  * A poorly worded security dialog (e.g. bug 326628).

  * A security dialog that an attacker can *make* confusing by inserting contradictory text.

  * A design flaw in a helper application which has registered to handle a protocol.  Firefox's external-protocol-handling dialog is not obviously a security dialog, so if "cancel" does not make the dialog go away, even users who read dialog text (!) and know about Force Quit (!) are likely to try the other button.

Comment 14

[Justin Dolske [:Dolske]]

Maybe we should do something akin to what we do for alert() et al... Either add some kind of "stop this site from asking me again" UI (eg checkbox), or just say after X canceled attempts we just automatically block the action.

Comment 15

[Jesse Ruderman]

> or just say after X canceled attempts we just automatically block the action.

My feeling is that canceling any security dialog should prevent more security dialogs from appearing until the next time you click on the web page.  Additionally, most security dialogs should be restricted to appearing at times when popups can appear.

Comment 16

[:Gavin Sharp [email: [e-mail]]]

I disagree with "sec-moderate" - this is closer to a DoS than something that can cause real damage, and the actual attack scenario (causing the user to make a connection/launch an app they don't want) is not likely to be abused much in practice.

If we are going to throttle this dialog, it would probably happen in nsExternalHelperAppService.cpp code, so moving over to Core.

Comment 17

[Tanvi Vyas[:tanvi]]

Similar to bug 167475, but probably not a duplicate.

Comment 18

[Kate McKinley [:kmckinley, :Kate]]

Attachment: Pop up 4 dialogs

Simple test case

Comment 19

[Daniel Veditz [:dveditz]]

Another case is using the mailto: protocol to launch an external mail app. We're not going to completely forbid that because people use it all the time, so we need to add limits. See bug 1435497 for an abuse example.

Comment 22

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Cleaning per duplicate.