1483510 - (CVE-2019-11725) SafeBrowsing bypass by web socket

Status: RESOLVED FIXED

(Toolkit :: Safe Browsing, defect, P3)

Description

[Andrey]

Attachment: 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.

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Francois, can you please take a look?

Comment 2

[François Marier [: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.

Comment 3

[Andrey]

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.

Comment 4

[Andrey]

Hi guys, 

Is it duplicate or confirmed as already known?

Comment 5

[François Marier [:francois]]

(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.

Comment 6

[Andrey]

Attachment: test-fetch.html

Comment 7

[Andrey]

Attachment: test-sb-xhr.html

Comment 8

[Andrey]

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.

Comment 9

[Andrey]

Hello! 

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

Comment 10

[Johann Hofmann [:johannh]]

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

Comment 11

[Dimi Lee [:dimi]]

(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 :)

Comment 12

[Dimi Lee [:dimi]]

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

Comment 13

[Dimi Lee [:dimi]]

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

Comment 14

[Brindusa Tot, DTE]

(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?

Comment 15

[Andrey]

(In reply to Andrey from comment #9)

Hello!

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

Hi! Still actual question =)

Comment 16

[Daniel Veditz [:dveditz]]

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

Comment 17

[Dimi Lee [:dimi]]

(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

Comment 18

[Brindusa Tot, DTE]

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.

Comment 19

[Dimi Lee [:dimi]]

(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.