CVE-2026-79977

Beschreibung

Der WireGuard VPN-Dienst in subsys/net/lib/wireguard/wg.c aktualisierte den Peer-Endpunkt aus einer Nachricht, die nicht authentifiziert werden konnte. In handle transport data(), wenn der 32-Bit-Empfängerindex einer eingehenden Transportdatennachricht ohne Sitzung übereinstimmte, plante der Code sowohl einen neuen Handshake als auch kopierte die Quelladresse des Datagramms mit memcpy(&peer->endpoint, peer addr, sizeof(peer->endpoint) in peer->endpoint. Da der Empfängerindex unbekannt ist, gibt es keinen Schlüssel, mit dem eine solche Nachricht verifiziert werden könnte, so dass die in peer->endpoint geschriebene Adresse vollständig vom Angreifer bereitgestellt wird. Jede andere Endpunktaktualisierung in der Implementierung erfolgt nur nach der Authentifizierung - nach dem Noise-Handshake in handle handshake init() oder nach der AEAD-Entschlüsselung plus dem Anti-Replay-Check in wg process data message(). Der WireGuard-Hörer ist bei net udp register() registriert und verwendet keinen Remote-Adressen- oder Portfilter und ist standardmäßig beim UDP-Port 51820 (CONFIG WIREGUARD PORT) und wg ctrl recv() löst den Peer nach Schnittstelle und nicht nach kryptographischer Identität auf. Jeder Host, der in der Lage ist, ein UDP-Datagramm an diesen Port zu senden, kann daher den defekten Off-Pfad erreichen, ohne den legitimen Datenverkehr beobachten zu müssen: Ein 16-Byte-Datagramm mit dem Transportdatentyp, auf Null gesetzte reservierte Bytes und ein beliebiger Empfängerindex sind ausreichend. Der anfällige Zweig läuft immer dann, wenn der Peer weder einen gültigen Handshake noch ein aktuelles Schlüsselpaar hat - der Zustand beim Booten und nach Ablauf einer Sitzung. Ein einzelnes verfälschtes Datagramm leitet den Peer->Endpunkt zu einer Adresse um, die der Angreifer gewählt hat, und alle nachfolgenden Handshake-Initiationen, Keepalives und verschlüsselte Datenpakete werden dorthin gesendet. Der legitime Peer erhält niemals die Initiationen und authentifiziert sich daher nie wieder, und nichts setzt den Endpunkt danach zurück, so dass der Tunnel auf Geräten, deren Peer sich nicht selbst initiiert, dauerhaft unbrauchbar bleibt. Der Angreifer kann auch die umgeleiteten Initiationen an den echten Peer weiterleiten, um sich im Pfad des Tunnels zu platzieren, Ciphertext- und Verkehrsmetadaten zu beobachten und selektiv Pakete fallen zu lassen. Die Ende-zu-Ende-Kryptographie von WireGuard verhindert immer noch die Entschlüsselung oder Fälschung von Tunnelinhalten, so dass die Auswirkungen auf den Verlust der Verfügbarkeit plus begrenzte Vertraulichkeit und nicht auf wichtige Kompromisse zurückzuführen sind. Der Fix entfernt das Endpunktlernen vollständig von diesem Pfad: Die Wiederherstellung der veralteten Sitzung wird beibehalten, aber der Handshake wird nur an einen Endpunkt gesendet, der aus einer authentifizierten Nachricht gelernt wurde, und fällt auf den konfigurierten cfg endpoint zurück, und die Nachricht wird gelöscht, wenn keiner von beiden bekannt ist. CONFIG WIREGUARD ist experimentell markiert und standardmäßig nicht aktiviert.

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Herstellerhinweise prüfen und das betroffene Produkt kurzfristig patchen oder kompensierende Schutzmaßnahmen aktivieren.

Empfohlene Schritte

• Betroffene Systeme identifizieren.
• Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
• Hersteller-Advisory öffnen und verfügbare Updates, Workarounds oder Deaktivierungen prüfen.
• Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

• Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
• WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
• Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.
• Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.