Bug 245968

Summary: www/firefox 75.0_2,1 & www/chromium 81.0.4044.113 - Servere Security Issue
Product: Ports & Packages Reporter: Greg Quinlan <gwq_uk>
Component: Individual Port(s)Assignee: freebsd-ports-bugs (Nobody) <ports-bugs>
Status: Open ---    
Severity: Affects Only Me CC: chromium, gecko, joneum, portmaster, rene
Priority: --- Keywords: needs-qa, security
Version: LatestFlags: koobs: maintainer-feedback? (gecko)
koobs: maintainer-feedback? (chromium)
Hardware: Any   
OS: Any   
Attachments:
Description Flags
Wireshark network monitoring log file
none
Pkg version output
none
Package conf file from /usr/local/etc/pkg.conf none

Description Greg Quinlan 2020-04-27 11:34:42 UTC 
Created attachment 213850 [details]
Wireshark network monitoring log file

Hi All,

Firefox & Chromium appear to have been compromised with what looks like a "backdoor".

I recently upgraded all my FreeBSD boxes to 12.1-p3 and ALL packages including the latest Firefox i.e. 75.0.2_1

One of my FreeBSD 12.1 boxes uses WIFI (wpa) and after opening the Firefox browser the WIFI network became extremely slow. So I installed Wireshark (GUI) from packages to see what was happening.

With just Firefox running and Google's home page loaded, I saw WireShark displaying dozens of WAN IP addresses connecting to my FreeBSD box. Network traffic suddenly went very high, and it seems all of the connections were using TCP ports r80 (HTTP) and 443 (HTTPS) through my machine.

With Firefox closed the WAN connections disappeared. Just to be clear, Firefox was open but there was no web activity initiated by me.

To be absolutely sure, I systematically made sure that EVERY wired and wireless device (that could possibly browse the internet) was switched off, changed the WIFI ssid and password, and I ran the above tests again, I got the same result.

Would someone else run the same tests and confirm please?

** Method
- Install the latest Firefox & Wireshark from packages.
- Start Wireshark first (internet->wireshark), select your network adapter and monitor the network - traffic to and from your machine.
- Start Firefox (or Chromium) only
- Now look at the network traffic to and from your IP address

I have attached a log, my IP address is 192.168.1.14 in the log, this file should be opened in Wireshark only.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2020-04-27 11:52:25 UTC 
@Greg Could you please provide:

- pkg version -v output (as an attachment)
- package repository configuration (as an attachment)

Note: It is expected behaviour that browsers produce network traffic (in either, and both directions), particularly with regard to bootstrapping, on initial loads, and in particular (for example) downloading/updating internal databases such as safebrowsing data, among other things.

Can you provide any additional information/evidence which indicates that the network traffic in question is specifically unexpected or malicious in nature?
Comment 2 Greg Quinlan 2020-04-27 12:42:39 UTC 
I undertsand what is normal, I been using FreeBSD since version 1.0 around Jan 1994. :)

If you look at the log I have provided, which was less than two minutes of logging, there are an abnormal number of connections to/from my Freebsd system.

The recent log is for my whole network, which includes two PCs running Windows 10 with Chrome or Firefox running. There is no such output from these machines! The Windows PC I am currently on, typing this reply, is currently running Chrome version 81.0.4044.122.

Chrome or Firefox on a Windows 10 machine do not produce anything like this. This is not normal!

Getting the files requested.
Comment 3 Greg Quinlan 2020-04-27 12:44:46 UTC 
Created attachment 213852 [details]
Pkg version output

pkg version -v output
Comment 4 Greg Quinlan 2020-04-27 12:46:53 UTC 
Created attachment 213853 [details]
Package conf file from /usr/local/etc/pkg.conf

/usr/local/etc/pkg.conf file
Comment 5 Greg Quinlan 2020-04-27 14:16:14 UTC 
I saved a logfile as txt and used awk to extract some of the IP addresses that my FreeBSD box is talking to...

using `nslookup` here is the output:

40.227.224.13.in-addr.arpa      name = server-13-224-227-40.lhr61.r.cloudfront.net.
28.170.227.13.in-addr.arpa      name = server-13-227-170-28.lhr52.r.cloudfront.net.
1.200.159.162.in-addr.arpa      name = time.cloudflare.com.
123.200.159.162.in-addr.arpa    name = time.cloudflare.com.
123.34.120.185.in-addr.arpa     canonical name = 123.64-127.34.120.185.in-addr.arpa.
123.64-127.34.120.185.in-addr.arpa      name = time.netweaver.uk.
66.59.114.217.in-addr.arpa      name = ns0.luns.net.uk.
139.242.208.34.in-addr.arpa     name = ec2-34-208-242-139.us-west-2.compute.amazonaws.com.
36.75.98.34.in-addr.arpa        name = 36.75.98.34.bc.googleusercontent.com.
253.118.10.52.in-addr.arpa      name = ec2-52-10-118-253.us-west-2.compute.amazonaws.com.
20.188.122.92.in-addr.arpa      name = a92-122-188-20.deploy.static.akamaitechnologies.com.
121.255.86.99.in-addr.arpa      name = server-99-86-255-121.lhr3.r.cloudfront.net.
18.255.86.99.in-addr.arpa       name = server-99-86-255-18.lhr3.r.cloudfront.net.
Comment 6 Greg Quinlan 2020-04-27 15:27:34 UTC 
Ok, I have left the Firefox browser "do its thing" for nearly an hour, the network traffic that I was seeing has settled down.

Embarrassing is this may sound, after a considerable amount of network activity Wireshark is not showing any more connections being made.

This appears to be a false positive, I just did not expected to be "hammered" when starting the browser every time!!!

Sorry .. but I think this can be closed.
Comment 7 Greg Quinlan 2020-04-27 16:16:59 UTC 
(In reply to Greg Quinlan from comment #6)
It has started again... browser sitting idle (from a user's perspective) and loads of traffic to/from lots of WAN addresses appearing in Wireshark. 

AGAIN!!!

None of my other OSes (aka Windows 10) are doing this!
Comment 8 Chris Hutchinson 2020-04-27 18:30:18 UTC 
(In reply to Greg Quinlan from comment #5)
You forgot one (mozilla's "phone home"):

a1089.dscd.akamai.net (detectportal.firefox.com)

It's address changes. So not included.
Comment 9 Jochen Neumeister freebsd_committer 2020-05-23 12:02:27 UTC 
not directly a ports-secteam problem. Back to pool
Comment 10 Rene Ladan freebsd_committer 2020-07-12 10:31:36 UTC 
Hmm, looking at your Wireshark dump it seems like your laptop (192.168.1.14) is connecting to all those services, not the other way around. As Kubilay mentions, it all seems to do with preloading and caching stuff (including tabs that you left open from your last session?). So nothing to see here really from a FreeBSD point of view.