This article is more than 1 year old
FreeBSD 13.0 to ship without WireGuard support as dev steps in to fix 'grave issues' with initial implementation
Public spat over code quality, reworked code set for 13.1 release, pfSense firewall also affected
A faulty implementation of WireGuard, a high-performance VPN protocol, has been removed from FreeBSD 13.0, shortly to be released, and a new implementation will not ship until the arrival of 13.1.
WireGuard, created by Jason A Donenfeld, was among the most warmly anticipated new features in FreeBSD 13.0. Netgate, sponsors of the popular FreeBSD firewall pfSense, funded a "well-known member of the FreeBSD community in 2019 to bring kernel-mode WireGuard support to FreeBSD."
The work was completed in August 2020 and upstreamed into FreeBSD in November 2020.
Unfortunately, Donenfeld reported last week that he had been disappointed by the implementation, saying that "a popular firewall vendor tasked a developer with writing a WireGuard implementation for FreeBSD. They didn't bother reaching out to the project."
When it came to the code, he said:
There were random sleeps added to "fix" race conditions, validation functions that just returned true, catastrophic cryptographic vulnerabilities, whole parts of the protocol unimplemented, kernel panics, security bypasses, overflows, random printf statements deep in crypto code, the most spectacular buffer overflows, and the whole litany of awful things that go wrong when people aren't careful when they write C.
Donenfeld got together with core FreeBSD developer Kyle Evans along with Matt Dunwoodie, who had worked on a WireGuard implementation for OpenBSD. The three "dug in and completely reworked the implementation," working fast in an effort to get the code into FreeBSD 13.0, which is scheduled to ship next month.
A new implementation was completed by the trio, using far fewer lines of code, and Donenfeld said: "I think we've mostly succeeded in producing something that behaves like WireGuard. The net result certainly isn't perfect, though – the Linux and OpenBSD implementations were long, careful, slow projects by comparison – but it is at least a base on which to build and improve over time."
Rethinking VPN: Tailscale startup packages Wireguard with network securityREAD MORE
That said, he expressed reservations about "additional systems coding issues to work out – locking, lifetimes, races, and that sort of thing."
Although the original hope was to ship this new implementation in FreeBSD 13.0, Donenfeld said: "Fortunately, and contrary to our plans, it looks exceedingly likely that given the grave issues we found in the existing code, they'll in the end just disable the module from the release, and revisit for 13.1, rather than merging our fixes a few short days before the release," which he added was "probably a very wise decision that takes some courage to make."
This is correct and in FreeBSD 13.0 RC3 "the if_wg(4) pseudo driver has been removed," according to the release notes.
Public dispute over code quality
Donenfeld's critique of the original code was not appreciated by Netgate's director of engineering, Scott Long, who said: "My team and I were proud of the work, proud of the results, and eager to share it with the pfSense and FreeBSD communities."
Long added: "Right now, we have not found any issues that would result in a remote or unprivileged vulnerability for pfSense users who are running WireGuard."
Donenfeld then both defended his remarks and expressed the wish to de-escalate the friction between them, in a comment to his original post. Evans also contributed to the discussion, posting about his disappointment in how the communication was handled.
A further consequence is that WireGuard (using the implementation removed from FreeBSD) has also been stripped from pfSense "out of an abundance of caution," according to Netgate co-owner Jim Thompson. He added that "should WireGuard again be accepted into FreeBSD, we will re-evaluate it for inclusion in a future version of pfSense software."
Despite some harsh words, it seems that all parties have had the best intentions in trying to add this important protocol to FreeBSD, and that a strong implementation will appear in version 13.1. In the meantime, it is missing. Another question is around how the removed version came so close to being included in the 13.0 release, if it is as flawed as Donenfeld suggests. ®