Closed Bug 1131310 Opened 11 years ago Closed 11 years ago

Cache-poisoning via WYCIWYG; changes leak data across private browsing boundary

Categories

(Core :: Networking: Cache, defect)

Product:
Core
Component:
Networking: Cache
Version:
35 Branch
Platform:
x86_64
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 619092
Tracking Flags:
Tracking Status
firefox36 --- affected
firefox37 --- affected
firefox38 - affected

People

(Reporter: axanderghemov, Unassigned)

References

(
URL
)

Details

(Whiteboard: dupe of bug 619092)

Attachments

(3 files)

Firefox 35 - proof of working exploit
280.03 KB, image/png
Details
Firefox 35 - fresh new test on the latest stable firefox : working
98.55 KB, image/png
Details
Firefox 31 ESR(Tor Bundle Browser) - working
104.02 KB, image/png
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20150126171358 Firefox for Android Steps to reproduce: [WARNING: I'm not the guys who found the vulnerability, I'm just concerned about Firefox security] Using the exploit in this video http://1337day.com/exploit/description/22578 Actual results: viewed/got the user cache,and you can obviously edit it as you prefer to even inject malicious code in it Expected results: It wouldn't worked, but it does.
Severity: normal → critical
OS: Linux → All
(I can get in contact with the guy who found the vuln.)
Note that the vulnerability page says affects Firefox less than 32 which is where Cache2 landed. This may not apply to release versions.
Component: Untriaged → Networking: Cache
Product: Firefox → Core
The reported said (on IRC) that he was shown it still working in Fx35
about Fx35, proof is cooming.
This appears to be the wyciwyg mechanism not the http cache. It's not surprising "cache2" didn't affect this bug.
Assignee: nobody → honzab.moz
Nice would be to get the JS code that exploits this in hands. Is it possible?
the guy will probably want the bounty..I'll ask him anyway.
Flags: needinfo?(axanderghemov)
i don't get it,what you need?
Flags: needinfo?(axanderghemov)
I need a way to reproduce. The JS code that does it is for "5000 gold" on that site and was not uploaded here. W/o it I'm not sure how to reproduce and fix. In other words, it would make it simpler for me to fix when I have it.
Flags: needinfo?(axanderghemov)
Summary: Firefox Anonymous mode cache bypass (all OS) → Private windows can see WYSIWYG data created at regular browsing
of course but i don't have the exploit,I'm waiting a response from that guy
Flags: needinfo?(axanderghemov)
Summary: Private windows can see WYSIWYG data created at regular browsing → Firefox Anonymous mode cache bypass (all OS)
Summary: Firefox Anonymous mode cache bypass (all OS) → Private windows can see WYSIWYG data created at regular browsing
the guy is a little upset: "go and find it(the exploit) in a bugzilla of some years ago"
Summary: Private windows can see WYSIWYG data created at regular browsing → Firefox Anonymous mode cache bypass (all OS)
he previously told me that he once reported the vuln but they simply forgot it or something lile.
So please tell him that his behavior is really super-helpful for us... Please, stop reverting the bug title on and on, thanks.
Summary: Firefox Anonymous mode cache bypass (all OS) → Private windows can see WYSIWYG data created at regular browsing
he won't release the exploit,but will tell how he trigger the wysiwyg.
I don't agree with the title,it doesn't represent the full concept of the vuln, something wirh cache-poisoning would be better since you can be infected and execute code everytime you visit a previously cached website.
Are the changes made to the HTTP-cache copy or to the "bfcache" used for fast history switching? One way to test that would be whether the changes persist after restarting Firefox or not.
Summary: Private windows can see WYSIWYG data created at regular browsing → Cache-poisoning via WYCIWYG; changes leak data across private browsing boundary
Older bugs with similar symptoms and various ways to reproduce: bug 619092 (document.write, reload, document.write, reload) bug 788547 (but I can't reproduce using the attachment) bug 1107113 (explicitly mentions the changes are in the http cache)
URL: http://1337day.com/exploit/descripti...
the trigger: javascript:document.write("<!doctype%20html>\n<html>\n"+document.getElementsByTagName('html')[0].innerHTML+"\n</html>");window.stop();location.reload();
his bug it's the first one 619092
change the status to CONFIRMED, please.
Any update?
I don't see any press here. If anyone tho wants to work on this sooner then me (I won't get to this sooner then in two weeks) then feel free to take. Please change the Assignee field accordingly.
Sounds like a straigt up dupe of bug 619092.
One reason not to dupe it is if there's new details here about how to exploit this. Merely showing the wyciwyg url is a bug, being able to edit the cache is scarier. But to exploit something you have to somehow get this code into someone else's domain, and isn't an injection flaw already a serious bug for that site?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: 619092
Whiteboard: dupe of bug 619092
Not so serious if you put the js in your site or in a page you compromised even before the users visit it
Any bounty reward for this guy?
(In reply to axanderghemov from comment #29) > Any bounty reward for this guy? No because he has to disclose the bug to us in detail and with his actual proof of concept. He's not doing so. Bounties are awarded *after* bugs are fixed and if they are deemed to be sec-high or sec-critical rated issues. Basically, if this person isn't going to tell us all the details, a bounty is not an option.
got it, I will get a reply from him.
I would encourage him to make a bugzilla account and speak to us directly.
He already have one, it's ShotokanZH, you can find it on a previous link
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Group: core-security
Assignee: honzab.moz → nobody
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: