Problematischer WireGuard-Port für FreeBSD und pfSense
Zusammenfassung
Netgate, die Firma hinter der Firewall pfSense, hatte einen WireGuard-Port für den FreeBSD-Kernel in Auftrag gegeben, und der Code war 2021 kurz vor der Veröffentlichung von FreeBSD 13.0 im Hauptzweig gelandet. Als die WireGuard-Entwickler um Jason Donenfeld ihn sich ansahen, fanden sie Pufferüberläufe, schwere Krypto-Fehler, nicht implementierte Protokollteile und Kernel-Paniken. Nach zwei Wochen Arbeit war vom ursprünglichen Code nichts mehr übrig, und FreeBSD 13.0 erschien ohne WireGuard im Kernel.
Was WireGuard ist
WireGuard ist ein modernes VPN-Protokoll, ähnlich IPsec, aber mit sehr wenig Code und festgelegten, modernen Kryptoverfahren. Seit Linux 5.6 ist es Teil des Linux-Kernels. Netgate wollte es in pfSense anbieten und bezahlte dafür eine Portierung in den FreeBSD-Kernel.
Die Mängelliste der WireGuard-Entwickler war lang: Sleep-Aufrufe gegen Race Conditions, Prüffunktionen, die einfach immer „gültig“ zurückgaben, Debug-Ausgaben mitten im Krypto-Code und Linux-Nachbildungen per ifdef. Netgate widersprach Teilen der Darstellung.
Was der Fall über Prozesse sagt
Das eigentliche Problem war nicht ein schlechter Port, sondern dass er ohne gründliche Prüfung in den Hauptzweig eines Betriebssystems gelangen konnte, wenige Wochen vor einer Veröffentlichung. Der Beitrag verwies zynisch auf Linus Torvalds, der für das strikte Ablehnen schlechter Patches oft kritisiert wird. Eine überarbeitete WireGuard-Implementierung kam später doch in FreeBSD.
Ideen
- Code für Kernel und Kryptografie braucht unabhängige Prüfung vor der Aufnahme.
- Die Entwickler eines Protokolls sollten bei Portierungen einbezogen werden.
- Kurz vor Veröffentlichungen ist die Aufnahme großer Änderungen besonders riskant.
Einsichten
- Bezahlte Entwicklung garantiert keine Qualität ohne Prüfprozesse.
- Strenge Reviews wirken unbequem, schützen aber Nutzer vor schweren Fehlern.
Fakten
- WireGuard ist seit Linux 5.6 Teil des Linux-Kernels.
Referenzen
Kritik
- Die Bezeichnung des Porters als „Typ“ und die Zuspitzung im Original zielen auf eine Person; das Kernproblem lag im Prüfprozess.
Bemerkungen
- Ars Technica und die FreeBSD-Mailingliste dokumentieren den Ablauf ausführlich.
Empfehlungen
- Nutze für VPNs ausgereifte, geprüfte Implementierungen und aktualisiere sie zügig.
- Plane in eigenen Projekten Code-Review als festen Schritt vor jeder Aufnahme ein.
Links zur Originalquelle und zum Webarchiv öffnen einen neuen Tab.