abraxas/sonic-gnmi-noauthDokumentiert und reproduziert eine Fail-Open-Authentifizierungsschwachstelle in SONiC gNMI, bei der eine leere UserAuth-Map unauthentifizierte gNMI Set- und gNOI-Schreibvorgänge ermöglicht, mit einem Loopback-Lab-Harness.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · sonic-gnmi-noauth
SONiC gNMI f13a08e0440f - SONiC Foundation / sonic-net
Community SONiC NOS. Nicht Dell Enterprise SONiC. Nicht SonicWall SonicOS. Das Komitee vergibt keine CVEs. gnmi-native.sh weiß, dass das Weglassen von --client_auth früher die Authentifizierung vollständig deaktivierte, daher erzwingt es den Zertifikatsmodus, wenn user_auth fehlt. Fail-closed. Dann übergibt es jedoch nie --ca_crt, wenn Zertifikate fehlen. setupFlags hebt das Zertifikat auf, weil keine CA vorhanden ist. authenticate() behandelt die leere Map als Erfolg. Native- und translib-Schreibvorgänge bleiben einkompiliert (ENABLE_NATIVE_WRITE=y). Zwei Produktions-Flag-Sets, derselbe Skip: Standard-ToR --noTLS --bind_address 127.0.0.1; SmartSwitch DPU --insecure --allow_no_client_auth, leeres Bind, alle Interfaces, Port 8080.
Leeres UserAuth nach dem Zertifikats-Unset bedeutet unauthentifizierte gNMI Set- und gNOI-Schreibvorgänge. DPU ohne Zertifikate ist remote auf :8080.
| ID | noch keine CVE |
| CWE | CWE-306, CWE-287 |
| CVSS | Kritisch: 9.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (DPU ohne Zertifikat). Standard-ToR ist derselbe Skip auf 127.0.0.1:8080 (Hoch, lokal). |
| Produkt | sonic-gnmi / sonic-buildimage |
| Betroffen | sonic-gnmi bis master f13a08e0440f; Launcher 9495839742e4 |
| Auth | unauthentifiziert |
| Lizenz | GNU Affero GPL v3.0 |
| Lab | nur 127.0.0.1 |
Auf einer SmartSwitch DPU ohne gNMI-Zertifikate: aus dem Netzwerk, TCP :8080, kein JWT, kein PAM, kein Client-Zertifikat. gnmi.gNMI/Set aufrufen (native CONFIG_DB / translib). gnoi.debug.Debug aufrufen. Neustart. Werksreset. File.Put unter /tmp, /var/tmp, /host.
Auf einem Standard-ToR/Leaf ohne Zertifikate: jeder Prozess, der 127.0.0.1:8080 erreichen kann, tut dasselbe. Der gnmi-Container läuft im Host-Netz, also ist dieses Loopback das des Hosts.
Das bedeutet Switch-Konfigurationsumschreibung und Host-Befehle als admin, ohne Authentifizierung. Die Debug-Whitelist enthält docker, config, redis-cli, sonic-installer, reboot. Standard-admin ist in docker und %sudo. Nicht das dokumentierte Standard-admin-Passwort. KillProcess gibt bei leerem UserAuth weiterhin Unauthenticated zurück. Verwenden Sie das nicht als Erfolgs-Orakel.
Ich habe zuerst SECURITY.md gelesen. sonic-net/SONiC ist das Wiki. Der Code sind benachbarte sonic-net/*-Bäume. Dann zehn Jagden auf diesen Pins: CLI-Injection, REST-Auth, gNMI Set, hostcfgd PAM, RESTCONF, ZTP, Image Redis/sshd/sudo, FEATURE-Defaults, GCU/SSTI, DHCP/LLDP/SNMP. Kein Live-Switch. Die Messlatte war Kritisch/Hoch.
Der größte Teil dieser Messlatte ist bereits geschlossen oder nicht Standard. sonic-restapi ist INCLUDE_RESTAPI ?= n. Der Produktions-Launcher von RESTCONF erzwingt PAM. Host-Redis ist 127.0.0.1 ohne requirepass, was ein erster Hop ist, kein Finding. Der gnmi-Container ist nicht optional. INCLUDE_SYSTEM_GNMI = y. FEATURE gnmi ist aktiviert. Host-Netz, Host-PID, Host-Userns.
Ich habe kein vollständiges sonic-vs-Image aufgesetzt. Das Lab ist ein dünnes gRPC-Wrapping von SHA256-geprüften Extrakten aus setupFlags und authenticate() vom Pin f13a08e0440f. Beide Listener gaben SONIC-GNMI-NOAUTH-WITNESS mit auth_enabled=false und enable_native_write=true zurück. Passwort-UserAuth ohne Credentials ist Unauthenticated. Das ist der echte Skip, kein Stub, der immer erfolgreich ist.
Bereits dokumentierte Irrwege: KillProcess Unauthenticated (dieser RPC lehnt leeres UserAuth bereits ab - das Lab erfordert den Set-Pfad-authenticate()-Skip); Probe OK, wenn Passwort-UserAuth aktiv ist und keine Credentials vorliegen (dann ist das Orakel ein Stub); ein gNOI-Debug-Docker-Gadget, nsenter-Payload, Reverse Shell. Theater. Das auf eine Dell Enterprise SONiC-Box oder eine SonicWall zu richten. Falsches Produkt.
cd lab
./run.sh
Ziel nur 127.0.0.1:18080 (ToR Klartext) und 127.0.0.1:18081 (DPU TLS-insecure). Dünnes gRPC, kein vollständiges DPU-Image. Pin-Extrakte werden beim Build gegen sonic-gnmi f13a08e0440f gehasht.
IOC tor-connect 127.0.0.1:18080 plaintext no-metadata
IOC tor-check witness=SONIC-GNMI-NOAUTH-WITNESS auth_enabled=false enable_native_write=true user_auth_any=false mode=tor
IOC dpu-connect 127.0.0.1:18081 tls-insecure no-client-cert no-metadata
IOC dpu-check witness=SONIC-GNMI-NOAUTH-WITNESS auth_enabled=false enable_native_write=true user_auth_any=false mode=dpu
IOC tor-negative status=UNAUTHENTICATED
IOC dpu-negative status=UNAUTHENTICATED
SUCCESS SONIC-GNMI-NOAUTH who=unauth tor=18080 dpu=18081 SONIC-GNMI-NOAUTH-WITNESS
Wenn UserAuth nach dem Entfernen des Zertifikats leer ist, bedienen Sie Set/gNOI-Schreibvorgänge nicht, oder lauschen Sie nicht außerhalb von Loopback. Kopieren Sie UserAuth auch auf dem --noTLS-Pfad. Stellen Sie Server-Zertifikate und eine CA bereit, damit --ca_crt gesetzt ist und der Zertifikatsmodus nicht aufgehoben wird. Betreiben Sie SmartSwitch DPU ohne Zertifikat (--insecure --allow_no_client_auth mit leerer CA) nicht auf einem erreichbaren :8080. Beide Listener müssen bei leerem UserAuth auf dem Schreibpfad Unauthenticated zurückgeben.
telemetry.go · server.go · whitelist.go · command.gognmi-native.sh · rules/config · init_cfg.json.j2