Kanidm: Anonymer Stack-Overflow-Absturz über verschachtelten LDAP-Filter

Ein anonymer Client kann mit einem einzelnen tief verschachtelten LDAP-Suchfilter auf der LDAPS-Schnittstelle den kanidmd-Prozess per Stack-Overflow zum Absturz bringen und damit zugleich die Web/OIDC-API lahmlegen.

Advisory-ID: TP-2026-028
Produkt: Kanidm (Identitäts- und Zugriffsverwaltung)
Schwachstellentyp: Denial of Service durch unbeschränkte Rekursion (CWE-674)
CVE: nicht beantragt
CVSS 3.1: 7.5 (Hoch) · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Betroffene Versionen: <= 1.10.3
Status: Vom Hersteller veröffentlicht; keine Fix-Version benannt
Hersteller-Advisory: GHSA-qcrp-p3rq-pffr
Gemeldet: 11. Juni 2026

Zusammenfassung

Kanidm ist eine Identitäts- und Zugriffsverwaltung. Die LDAPS-Schnittstelle dekodiert jede eingehende Nachricht mit dem BER-Parser, bevor Authentifizierung, Bind oder eine Tiefenprüfung laufen. Der rekursiv absteigende Dekoder hat keine Tiefenbegrenzung, sodass ein Suchfilter mit einigen tausend verschachtelten AND-Elementen je Ebene einen Stackframe verbraucht und den Worker-Stack überläuft. Da die LDAPS-Schnittstelle und die HTTPS-Web/OIDC-API denselben Prozess teilen, legt der Absturz den gesamten Dienst lahm. turingpoint hat den Ablauf verifiziert und an den Hersteller gemeldet.

Ursache

Die LDAPS-Sitzung dekodiert jede Nachricht über FramedRead::new(r, LdapCodec::default()) (server/core/src/ldaps.rs:64); LdapCodec aus ldap3_proto 0.7.1 delegiert die Strukturanalyse an den lber-0.4.2-Dekoder. Dieser rekursiv absteigende Dekoder baut den verschachtelten Tag-Baum ohne Tiefenbegrenzung auf, also einen Stackframe pro Ebene. Die Tiefenprüfung Filter::from_ldap_ro (server/lib/src/filter.rs:772, DEFAULT_LIMIT_FILTER_DEPTH_MAX) läuft erst, nachdem der Codec den vollständigen Baum bereits gebaut hat, und sieht die Eingabe daher nie. Das einzige Codec-Limit ist DEFAULT_MAX_BER_SIZE (32 KB), eine Größen- und keine Tiefengrenze, sodass ein rund 31,9 KB großes Payload darunter bleibt und den Standard-Stack von 2 MB überläuft (server/daemon/src/main.rs:730, thread_stack_size auskommentiert). Es ist ein unvollständiger Fix von GHSA-qcxq-75wr-5cm8: ldap3_proto 0.7.1 begrenzt nur den PEG-String-Filterpfad, der BER-Wire-Pfad bleibt ungebunden.

Proof of Concept

Schematisch (anonym, LDAPS-Port):

SearchRequest mit einem Filter, der einige tausend AND-Elemente verschachtelt
(Gesamtgröße knapp unter 32 KB).

-> rekursiver BER-Dekode überläuft den Worker-Stack, der Prozess bricht ab
   (SIGSEGV / "stack overflow"); LDAPS- und HTTPS-Port sind anschließend offline.

Das Payload bleibt unter der einzigen Größenschranke des Codecs, weil diese die Verschachtelungstiefe nicht misst; die Tiefenprüfung der Anwendung greift erst nach dem Dekodieren und damit zu spät.

Auswirkung

  • Absturz des gesamten kanidmd-Prozesses durch ein einzelnes Paket.
  • Gleichzeitiger Ausfall der LDAPS-Schnittstelle und der HTTPS-Web/OIDC-API, da sie denselben Prozess teilen.
  • Anonym auslösbar, sobald LDAP aktiviert ist; keine Authentifizierung nötig.

Referenzen

Steckt so etwas in Ihrer Software?

Diese Schwachstelle hat unser Team im Rahmen seiner Arbeit gefunden. Lassen Sie Ihre Anwendungen von denselben Spezialisten prüfen, mit einem Penetrationstest von turingpoint.

Pentest anfragen