Closed Bug 1483510 (CVE-2019-11725) Opened 3 years ago Closed 2 years ago

SafeBrowsing bypass by web socket

Categories

(Toolkit :: Safe Browsing, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox-esr60 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- fixed

People

(Reporter: avkovaleff, Assigned: dimi)

References

(Blocks 1 open bug)

Details

(Keywords: csectype-other, sec-low, Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main68+] tp-leak)

Attachments

(3 files)

Attached file test2.html
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.
Flags: sec-bounty?
Francois, can you please take a look?
Flags: needinfo?(francois)
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.
Blocks: 1207775
Group: toolkit-core-security
Component: Security → Safe Browsing
Flags: needinfo?(francois)
Priority: -- → P3
Product: Firefox → Toolkit
See Also: → 1447935
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.
Attached file test-fetch.html
Attached file test-sb-xhr.html
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.
Group: firefox-core-security
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?]tp-leak
Hello! 

Any update here? Probably bounty and / or CVE? =)
Group: toolkit-core-security → firefox-core-security

Dimi, do you know about the state of this? :)

Flags: needinfo?(dlee)

(In reply to Johann Hofmann [:johannh] from comment #10)

Dimi, do you know about the state of this? :)

Yes, This will be fixed after landing patch in Bug 1522412, which should be done within this week :)

Depends on: 1522412
Flags: needinfo?(dlee)

Bug 1522412 has landed so this issue should be fixed.
I'll add a testcase to verify this.

Assignee: nobody → dlee
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

I have verified that websocket is blocked by SafeBrowsing via:

  1. Add "echo.websocket.org" to safe browsing malware database
  2. Go to https://www.websocket.org/echo.html, make sure we can't connect to echo.websocket.org
  3. remove the malware test table from preference
  4. connect to echo.websocket.org again, can establish the connection now.

So this issue is fixed by Bug 1522412

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Group: firefox-core-security → core-security-release

(In reply to Dimi Lee [:dimi][:dlee] from comment #13)

  1. Add "echo.websocket.org" to safe browsing malware database

Could you please detail here? How exactly can I add "echo.websocket.org" to safe browsing malware database?

Flags: needinfo?(dlee)

(In reply to Andrey from comment #9)

Hello!

Any update here? Probably bounty and / or CVE? =)

Hi! Still actual question =)

Unfortunately this bug does not qualify for a security bug bounty.

Flags: sec-bounty? → sec-bounty-

(In reply to Brindusa Tot[:brindusat] from comment #14)

(In reply to Dimi Lee [:dimi][:dlee] from comment #13)

  1. Add "echo.websocket.org" to safe browsing malware database

Could you please detail here? How exactly can I add "echo.websocket.org" to safe browsing malware database?

Hi Brindusa,
Safe browsing doesn't have a public API to do that, I did that by manually modifying the test entries in our codebase[1].
We have a preference to add a domain to tracking protection for testing, we can do the same thing for safe browsing.
Would that help?

[1] https://searchfox.org/mozilla-central/rev/f46e2bf881d522a440b30cbf5cf8d76fc212eaf4/toolkit/components/url-classifier/SafeBrowsing.jsm#433

Flags: needinfo?(dlee) → needinfo?(brindusa.tot)

I think having a manual way to add safe browsing blocking would help for verifying this bug, however, I'm not sure if the effort is worthwhile if you think there wouldn't be a general and future use for it.

Flags: needinfo?(brindusa.tot)

(In reply to Brindusa Tot[:brindusat] from comment #18)

I think having a manual way to add safe browsing blocking would help for verifying this bug, however, I'm not sure if the effort is worthwhile if you think there wouldn't be a general and future use for it.

I think that will be useful, I filed bug 1546586 to implement this.

Whiteboard: [reporter-external] [client-bounty-form] [verif?]tp-leak → [reporter-external] [client-bounty-form] [verif?][adv-main68+] tp-leak
Alias: CVE-2019-11725
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.