Aus dem Codebasis, auf der die Ver\u00f6ffentlichungen von FreeBSD 13 basieren, wurde nach einem Skandal der Code f\u00fcr das VPN-Protokoll WireGuard entfernt. Dieser wurde von Netgate in Auftrag gegeben, ohne R\u00fccksprache mit den Entwicklern des urspr\u00fcnglichen WireGuard und war bereits in den stabilen Versionen der Distribution pfSense enthalten. Nach einer \u00dcberpr\u00fcfung des Codes durch Jason A. Donenfeld, dem Autor des urspr\u00fcnglichen WireGuard, stellte sich heraus, dass die f\u00fcr FreeBSD vorgeschlagene Implementierung von WireGuard ein Beispiel f\u00fcr einen minderwertigen Code war, der voller Buffer\u00fcberl\u00e4ufe und Lizenzverletzungen der GPL war. <\/p>\n
Die Implementierung wies katastrophale M\u00e4ngel im Code der Kryptografie auf. Ein Teil des WireGuard-Protokolls wurde ausgelassen, es traten Fehler auf, die zu Kernel-Abst\u00fcrzen und Umgehungen von Schutzmethoden f\u00fchrten. F\u00fcr die Eingabedaten wurden Buffer fester Gr\u00f6\u00dfe verwendet. Die Qualit\u00e4t des Codes wird durch das Vorhandensein von Platzhaltern anstelle von \u00dcberpr\u00fcfungen, die immer den Wert \u201etrue\u201c zur\u00fcckgeben, und vergessene Debug-Ausgaben mit Parametern, die f\u00fcr die Verschl\u00fcsselung verwendet werden, sowie die Anwendung der Funktion sleep zur Vermeidung von Race Conditions stark in Frage gestellt. <\/p>\n
Einige Teile des Codes, wie die Funktion crypto_xor, wurden in Versto\u00df gegen die GPL-Lizenz aus der f\u00fcr Linux entwickelten Implementierung von WireGuard \u00fcbernommen. In der Folge haben Jason Donenfeld zusammen mit Kyle Evans und Matt Dunwoodie (dem Entwickler des WireGuard-Ports f\u00fcr OpenBSD) die problematische Implementierung \u00fcberarbeitet und innerhalb einer Woche den gesamten Code des von Netgate engagierten Entwicklers ersetzt. Die \u00fcberarbeitete Version wurde als separate Patch-Sammlung ver\u00f6ffentlicht und im Repository des WireGuard-Projekts bereitgestellt, ist jedoch noch nicht Teil von FreeBSD. <\/p>\n
Es ist interessant, dass anfangs nichts auf die Schwierigkeiten hindeutete. Das Unternehmen Netgate, das die Nutzung von WireGuard in der pfSense-Distribution erm\u00f6glichen wollte, beauftragte Matthew Macy, einen Experten f\u00fcr den FreeBSD-Kernel und den Netzwerkstack, der an Fehlerbehebungen arbeitete und Erfahrung in der Entwicklung von Netzwerktreibern f\u00fcr dieses Betriebssystem hatte. Macy erhielt einen flexiblen Zeitplan ohne Fristen oder Zwischenpr\u00fcfungen. Entwickler, die bei FreeBSD mit Macy zusammengearbeitet haben, beschrieben ihn als talentierten und professionellen Programmierer, der nicht mehr Fehler machte als andere und konstruktiv auf Kritik reagierte. Die bedauerliche Qualit\u00e4t des WireGuard-Codes f\u00fcr FreeBSD \u00fcberraschend f\u00fcr sie. <\/p>\n
Nach neun Monaten Arbeit f\u00fcgte Macy im Dezember letzten Jahres seine Implementierung ohne Abschluss der \u00dcberpr\u00fcfung und Tests durch Dritte in den HEAD-Branch ein, der f\u00fcr die Erstellung des Releases von FreeBSD 13 verwendet wurde. Die Entwicklung erfolgte ohne Kontakt zu den Entwicklern des urspr\u00fcnglichen WireGuard und den Ports f\u00fcr OpenBSD und NetBSD. Im Februar integrierte Netgate WireGuard in die stabile Version von pfSense 2.5.0 und begann mit der Lieferung in darauf basierenden Firewalls. Nach Auftreten von Problemen wurde der WireGuard-Code aus pfSense entfernt. <\/p>\n
Im hinzugef\u00fcgten Code wurden kritische Sicherheitsanf\u00e4lligkeiten entdeckt, die in 0-Day-Exploits ausgenutzt wurden. Zun\u00e4chst erkannte Netgate die Schwachstellen nicht an und versuchte, den Entwickler des urspr\u00fcnglichen WireGuard wegen Angriffen und Vorurteilen zu beschuldigen, was sich negativ auf seinen Ruf auswirkte. Der Portentwickler wies anfangs die Qualit\u00e4tsvorw\u00fcrfe zur\u00fcck und hielt sie f\u00fcr \u00fcbertrieben, lenkte jedoch nach der Demonstration der Fehler ein und erkannte, dass ein wirklich wichtiges Problem das Fehlen einer angemessenen Qualit\u00e4tspr\u00fcfung des Codes in FreeBSD war, da die Probleme \u00fcber viele Monate hinweg unbemerkt blieben. (Vertreter von Netgate wiesen darauf hin, dass die \u00f6ffentliche \u00dcberpr\u00fcfung bereits im August 2020 gestartet wurde, aber einzelne Entwickler von FreeBSD merkten an, dass die \u00dcberpr\u00fcfung in Phabricator von Mayci ohne Erledigung und unter Ignorierung von Kommentaren geschlossen wurde). Das FreeBSD Core Team reagierte auf den Vorfall mit dem Versprechen, die Prozesse zur Code\u00fcberpr\u00fcfung zu modernisieren. <\/p>\n
Matthew Maisey, Entwickler des Problemportals f\u00fcr FreeBSD, kommentierte die Situation, indem er zugab, einen gro\u00dfen Fehler gemacht zu haben, indem er sich an ein Projekt setzte, f\u00fcr das er nicht bereit war. Das Ergebnis erkl\u00e4rt Maisey mit emotionaler Ersch\u00f6pfung und Problemen, die aus dem postcovid-Syndrom hervorgingen. Dennoch fand Maisey nicht den Mut, sich von den bereits \u00fcbernommenen Verpflichtungen zur\u00fcckzuziehen, und versuchte, das Projekt zu Ende zu bringen. <\/p>\n