Bug 245968 - www/firefox 75.0_2,1 & www/chromium 81.0.4044.113 - Servere Security Issue
Summary: www/firefox 75.0_2,1 & www/chromium 81.0.4044.113 - Servere Security Issue
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
Keywords: needs-qa, security
Depends on:
Reported: 2020-04-27 11:34 UTC by Greg Quinlan
Modified: 2020-07-12 10:31 UTC (History)
5 users (show)

See Also:
koobs: maintainer-feedback? (gecko)
koobs: maintainer-feedback? (chromium)

Wireshark network monitoring log file (170.34 KB, application/octet-stream)
2020-04-27 11:34 UTC, Greg Quinlan
no flags Details
Pkg version output (52.28 KB, text/plain)
2020-04-27 12:44 UTC, Greg Quinlan
no flags Details
Package conf file from /usr/local/etc/pkg.conf (2.18 KB, text/plain)
2020-04-27 12:46 UTC, Greg Quinlan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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 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:      name = server-13-224-227-40.lhr61.r.cloudfront.net.      name = server-13-227-170-28.lhr52.r.cloudfront.net.      name = time.cloudflare.com.    name = time.cloudflare.com.     canonical name = 123.64-
123.64-      name = time.netweaver.uk.      name = ns0.luns.net.uk.     name = ec2-34-208-242-139.us-west-2.compute.amazonaws.com.        name =      name = ec2-52-10-118-253.us-west-2.compute.amazonaws.com.      name = a92-122-188-20.deploy.static.akamaitechnologies.com.      name = server-99-86-255-121.lhr3.r.cloudfront.net.       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. 


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