The release of pfSense® software version 2.4.0 is near. Originally, we had hoped to publish it this week, however, the process had to be halted before we could finish.
While we were engaged in the process of wrapping up testing and preparing the release, Google announced vulnerabilities they discovered in dnsmasq, which is a part of the pfSense software base installation. The dnsmasq daemon is no longer used by default on new pfSense software installations, but users who manually activated it or upgraded older systems which used it by default in the past continue to rely on dnsmasq. On top of that, since the release builds started, there were also updates to OpenVPN and Perl that, while not directly impacting the base system, are also worth addressing given the setback.
The short version of the story is that we are having to stop and rebuild the release, which also means a fresh round of testing. This will set the pfSense 2.4.0-RELEASE date back for a few days, with the new target being October 12, 2017.
Analyzing the Situation
Let’s take a moment to discuss these security issues:
OpenVPN 2.4.4 / 2.3.18
OpenVPN released version 2.4.4 and 2.3.18 to address CVE-2017-12166
If ‘key-method 1’ is present in an OpenVPN configuration, an attacker could exploit an improperly tested value to trigger a stack buffer overflow.
The GUI for OpenVPN clients and servers in pfSense does not have a control for this option, it is not relevant to our users. That said, someone may have entered the directive in the advanced options area by hand.
Even so, ‘key-method 1’ is not the default behavior of OpenVPN. It was replaced by ‘key method 2’ in OpenVPN 2.0, released over 10 years ago in 2005, and the keyword has been explicitly deprecated in 2.4 and marked for removal in 2.5.
Given the low impact, we did not consider that to be a release blocker, especially considering we had planned to release pfSense 2.4.1 within the next month.
An update to the OpenVPN Client Export Package with installers for OpenVPN 2.4.4 and 2.3.18 will be available shortly. Since that is a package it can be updated at any time.
Perl released version 5.24.3 to address CVE-2017-12837 and CVE-2017-12883, both issues in regular expression parsing, and the latter could result in memory contents being exposed as part of an error message.
The pfSense base installation only uses Perl for rrdtool, and its inputs are checked, so the potential impact was low. For packages, if any were impacted we could have updated Perl after release and the update could have been brought in as needed later. So again, we did not consider that a release blocker given our timeline.
The dnsmasq 2.78 release addresses CVE-2017-14491, CVE-2017-14492, CVE-2017-14493, CVE-2017-14494, CVE-2017-14495, CVE-2017-14496, and CVE-2017-13704, and Google has published a detailed analysis of the issues.
These CVE entries are for various problems including overflows, information leaks, improper bounds checking, and crashes. The first three are extremely critical as they can lead to remote code execution, and several of the other bugs are potential denial of service vectors.
Even though dnsmasq is not enabled by default, we felt that these severe issues impacted enough users to warrant stopping the release process and rebuilding.
Users on pfSense 2.3.x or earlier concerned about these bugs can switch to the DNS Resolver (Unbound) until a new pfSense software release is available. Users on 2.4.0-RC or earlier snapshots can either switch to Unbound or upgrade to a new snapshot after the correction date, or both.
FreeBSD 11.0 EOL
FreeBSD 11.0 reaches its End of Life (EOL) on October 26, 2017, 3 months after the release of FreeBSD 11.1.
In the past we have run releases well past their EOL dates for a variety of reasons, but that requires us to expend a lot more effort in maintaining our own security patches. We prefer to stay up-to-date and within the official supported timelines for our FreeBSD base versions.
The original plan was to publish pfSense 2.4.0-RELEASE this week using a FreeBSD 11.0 base and then work on pfSense 2.4.1 which was to include FreeBSD 11.1 as its base instead. We would have had just enough time to get a pfSense 2.4.1 release tested and published before FreeBSD 11.0 hit the EOL date. However, due to the delay incurred by having to restart all of the builds and testing for dnsmasq, we decided to alter our course.
Now we plan on changing pfSense 2.4.0 to a FreeBSD 11.1 base and we’re pushing the release back date a few days to allow more testing. We have been testing images based on FreeBSD 11.1 internally for a while now, and users have been running pfSense 2.4.1 snapshots based on FreeBSD 11.1 as well. We are confident there will be enough time to get enough useful feedback given the circumstances.
In addition to the changes to the pfSense 2.4.0-RELEASE timeline, we are also planning a pfSense 2.3.5 update to address dnsmasq and other issues at a later date.
We will be restarting public pfSense 2.4.0 Release Candidate snapshots today with a FreeBSD 11.1 base. Anyone that was tracking pfSense 2.4.0-RC snapshots should update and test as much as possible. Given our internal testing and snapshot testing of pfSense 2.4.1 we expect this to be a low-impact beneficial change, but with any change of this nature, caution is warranted.
Keep an eye on our social media accounts to find out when the new snapshots are available. We appreciate all of the help we can get from the community in making sure this is the best release yet!
Updating dnsmasq on 2.4.0-RC Snapshots
Perform an update to the latest available snapshot, which includes the updated dnsmasq package.
Updating dnsmasq on 2.3.4-p1
Due to the severity of the dnsmasq problems we have made an updated build of dnsmasq available for users on 2.3.4-p1. This component must be updated manually.
To update dnsmasq, use either a console shell or Diagnostics > Command Prompt to run the following command, which installs the latest version of the dnsmasq daemon and its associated files:
pkg upgrade -y dnsmasq
Next, verify that the update succeeded by running the following command:
pkg version -vx dnsmasq
It will output the current version of the dnsmasq package and its status, which will look like the following output if the update was successful:
dnsmasq-2.78,1 = up-to-date with remote
For this change to take effect, the DNS Forwarder (dnsmasq) service must be restarted. Restarting the service can be accomplished in several ways.
Choose ONE of the following methods to restart the DNS Forwarder service:
- In the GUI at Status > Services, click the restart icon for the service
- In the GUI, navigate to Services > DNS Forwarder and click Save, then Apply
- From the console or ssh, open a shell prompt and execute
pfSsh.php playback svc restart dnsmasq
- Reboot the firewall
Afterward, visit Status > System Logs on the DNS Resolver tab and check to ensure the new version started. A line similar to this one will appear in the log:
Oct 4 13:48:43 dnsmasq 30799 started, version 2.78 cachesize 10000
Users on version of pfSense older than 2.3.4-p1 should upgrade to pfSense 2.3.4-p1. Users on 2.3.4 or earlier 2.3.x versions will pick up the new dnsmasq automatically when performing an online update to pfSense 2.3.4-p1.