Closed Bug 1483510 (CVE-2019-11725) Opened 3 years ago Closed 2 years ago
Browsing bypass by web socket
Steps to reproduce the problem: 1. Try to go to website, which is blocked by Safebrowsing API, for example: ri-online.su. Firefox will block navigate and show warning. Also, we'll see in console, that request was blocked by safebrowsing. 2. If an attacker create malicious web site, which will load content from Safe Browsing blocked resource (script src, or xhr/fetch), such site also will blocked. 3. If an attacker create malicious web site, which will load content from Safe Browsing blocked resource through websocket protocol no warning will be shown. Please, see test2.html for variant of the POC. What is the expected behavior? Firefox should show safe browsing warning before navigate to malicious web resource. What went wrong? Firefox does navigate to malicious resource through websocket without any warnings. So, this issue is a variation of the SafeBrowsing bypass, which allow to load and evaluate malicious scripts from known and blocked resources.
Francois, can you please take a look?
Yes, that's one of the many known bypasses for Safe Browsing / Tracking Protection. The expected behavior is for us to block web socket requests from malicious domains, which we are not doing right now.
There is actually the race condition in xhr requests. If I do fetch to this host, I see message about safe browsing blocking, but request is done.
Hi guys, Is it duplicate or confirmed as already known?
(In reply to Andrey from comment #3) > There is actually the race condition in xhr requests. If I do fetch to this > host, I see message about safe browsing blocking, but request is done. Can you explain in more details what the race condition is? I don't see that from the bug description.
Sorry for delay. Seems, that it doesn't have security impact, but fetch and xhr requests have different behavior. Please, see attached examples. In fetch example FF doesn't produce request to the malicious server, in xhr request still appear. That's case, which I meant when wrote about race condition. It doesn't harm to end user but could call false positive alerts from protection services and tools.
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?]tp-leak
Hello! Any update here? Probably bounty and / or CVE? =)
Depends on: 1522412
Assignee: nobody → dlee
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Group: firefox-core-security → core-security-release
Flags: sec-bounty? → sec-bounty-
Flags: needinfo?(dlee) → needinfo?(brindusa.tot)
Whiteboard: [reporter-external] [client-bounty-form] [verif?]tp-leak → [reporter-external] [client-bounty-form] [verif?][adv-main68+] tp-leak
10 months ago
You need to log in before you can comment on or make changes to this bug.