1310393 - Status Bar Obfuscation

Status: RESOLVED DUPLICATE of bug 1310432

(Firefox :: Address Bar, defect, P1)

Description

[randy]

In this issue, Firefox's Status Bar will show the link where the user will be redirected but after he clicks the link, he redirected to other website.

Products affected:

Last Version of Mozilla Firefox.

Steps To Reproduce:

* Open the HTML file
* You will see a hyperlink of google.com, So hover your mouse.
* See the Status Bar(located at the lower left of the browser) and you will see the link where it should be redirected
* Now, click the hyperlink and you will be redirected to another website which is not the expected website.

Comment 1

[randy]

Attachment: poc-firefox_statusbar_obfuscation.html

Comment 2

[randy]

Attachment: firefox_statusbar_obfuscation.png

Comment 4

[randy]

i am confuse here, take a look at the date of submission i am is the first who submit this bug, but why mine is duplicate of other report ?

and then this bug can lead to any other vulnerability like click jacking and phishing that can effect to steal sensitive information of user/customer. weird huh ? why you wont fix then ?

Comment 5

[Marco Bonardo [:mak]]

(In reply to randy from comment #4)
> i am confuse here, take a look at the date of submission i am is the first
> who submit this bug, but why mine is duplicate of other report ?

bugs are not duplicated based on submission date, but based on contents. if one bug already has developers comments or better STR or similar, we prefer to keep that one.
Luckily this is not a challenge and what matters is that the bug gets fixed, in the end.

> and then this bug can lead to any other vulnerability like click jacking and
> phishing that can effect to steal sensitive information of user/customer.
> weird huh ? why you wont fix then ?

The reasoning is at https://bugzilla.mozilla.org/show_bug.cgi?id=1310432#c1
Gijs may have other to add, not sure, so not unsetting his request.

Comment 6

[:Gijs (he/him)]

(In reply to randy from comment #4)
> i am confuse here, take a look at the date of submission i am is the first
> who submit this bug, but why mine is duplicate of other report ?

Because it was the first that got marked as non-sec-sensitive with an explanation of why we're not fixing it, and all of these reports had essentially the same steps and code.

> and then this bug can lead to any other vulnerability like click jacking

click-jacking is usually about getting the user to do something on a site you have no control over by making them click repeatedly on something you do control. When that happens people can't read the status bar anyway.

> and phishing

If you had a page X on which you could already run JS, there's no reason to not just redirect the user to phishing page Y directly, or using a button that doesn't provide a status bar / link at all.

> weird huh ?

Not really, this is a well-known and well-understood issue.

> why you wont fix then ?

Because it isn't possible to fix this, because the effects aren't severe enough to justify doing much of anything, except perhaps removing the status bar altogether, which has enough UX downsides that it's not really worth pursuing.

How would you propose fixing this? It's not like you've made any suggestions...

(pro tip: we cannot detect beforehand what the target of the link will be by the time you've finished clicking it, as that problem is effectively the same as https://en.wikipedia.org/wiki/Halting_problem )

Comment 7

[randy]

(In reply to Marco Bonardo [::mak] from comment #5)
> (In reply to randy from comment #4)
> > i am confuse here, take a look at the date of submission i am is the first
> > who submit this bug, but why mine is duplicate of other report ?
> 
> bugs are not duplicated based on submission date, but based on contents. if
> one bug already has developers comments or better STR or similar, we prefer
> to keep that one.
> Luckily this is not a challenge and what matters is that the bug gets fixed,
> in the end.
> 
> > and then this bug can lead to any other vulnerability like click jacking and
> > phishing that can effect to steal sensitive information of user/customer.
> > weird huh ? why you wont fix then ?
> 
> The reasoning is at https://bugzilla.mozilla.org/show_bug.cgi?id=1310432#c1
> Gijs may have other to add, not sure, so not unsetting his request.


"bugs are not duplicated based on submission date, but based on contents. if one bug already has developers comments or better STR or similar, we prefer to keep that one." Its because team or the developer its not quick reply or check the submission maybe, logically if the submission got attention and quick response (for example when i submit and or report bug and got quick response not get delay on preview) then of-course the first submission will be the point of other report. 

Yes i do agree this not a challenge but about honor duplicate for me is like plagiarist.

Comment 8

[randy]

again i also submit this to internet bug bounty program, when they see this is mark as duplicate of course they wont accept this event the fact mine is the first reporter. that is the reason why i am little disappointed with the result. the other mark as resolved but mine is duplicate.

Comment 9

[Al Billings [:abillings - ex-MoCo]]

This is not bug bounty eligible. This does not meet our bar for bug bounties and this bug is public now.

Comment 10

[randy]

well, thank you very much for all of you who have response and give nice reason. i appreciate your decision.

Regards,

Comment 11

[Daniel Veditz [:dveditz]]

This issue is inherent to having a scripting language in the browser. For whatever reason a bunch of folks filed essentially the same bug recently and we duped them because we're lazy, but if you want to do the bugzilla searches you'll find this same bug filed every year or so for the past decade.

Comment 12

[randy]

The impact of this vulnerability is variable, depending on how it is used. An attacker could use this vulnerability to target a specific victim or post it in a popular forum frequented by users of this application. If an authenticated user could be tricked into clicking the link it may result in malicious JavaScript executing in the context of the user's session and could result in credential/session theft, disclosure of sensitive information or other targeted attacks. This could result in multiple compromised accounts and theft of user-data and consequently, negative publicity and reputation damage to company (in this cases mozilla company)

Comment 13

[:Gijs (he/him)]

(In reply to randy from comment #12)
> The impact of this vulnerability is variable, depending on how it is used.
> An attacker could use this vulnerability to target a specific victim or post
> it in a popular forum frequented by users of this application. If an
> authenticated user could be tricked into clicking the link it may result in
> malicious JavaScript executing in the context of the user's session and
> could result in credential/session theft, disclosure of sensitive
> information or other targeted attacks. This could result in multiple
> compromised accounts and theft of user-data and consequently, negative
> publicity and reputation damage to company (in this cases mozilla company)

If you have a forum where an attacker can insert arbitrary HTML including javascript that then runs on users' machines, you've already lost, as attackers can already redirect to a page of their choosing, steal cookies, steal credentials ("please input your password a second time to continue") and do all kinds of other evil things. They don't need the status bar behaviour for that, and they wouldn't be able to change it if they were unable to inject arbitrary JS -- so the point in your comment is moot.

In any case, as comment #11 said, this problem has been known for years. See bug 229050 (13 years old) and all its dupes. See bug 229050 comment 25 for why even the solution suggested in that bug would not be foolproof.