KIberblick

KIberschutz: Mira räumt eigene Lücken auf

Wir meldeten dem KI-Code-Reviewer Mira zwölf Funde. Die kritischen waren am nächsten Tag gefixt, jetzt ist alles in v0.8.0 released.

Entwickler:inQA / Tester:inProduct Owner
27. Juli 20267 Min. Lesezeit

Transparenz vorweg: KIberschutz ist unser eigenes Projekt. Wir prüfen mit KI-Unterstützung Open-Source-Software auf Sicherheitslücken und melden Funde verantwortungsvoll an die Maintainer. Nach logtide und Speakr ist das der dritte Fall, den wir hier aufschreiben. Und er hat eine kleine Pointe: das geprüfte Projekt ist selbst ein Werkzeug, das Code auf Schwachstellen scannt.

Was passiert ist

Das Projekt war Mira, ein selbst gehosteter KI-Code-Reviewer. Man hängt ihn an seine Repositories, er liest Pull Requests mit einem LLM der eigenen Wahl und schreibt konkrete Review-Kommentare, inklusive einer Schwachstellen-Prüfung. Das Projekt ist in Python geschrieben, hat rund 216 Sterne auf GitHub und bewirbt sich ausdrücklich als "Self-host every feature", also alles auf der eigenen Infrastruktur, ohne SaaS und ohne Lizenzschlüssel.

Ein Werkzeug, das fremden Code auf Lücken abklopft, ist ein besonders reizvolles Ziel. Nicht um jemanden vorzuführen, sondern weil hier die naheliegende Frage lautet: Wie sieht der eigene Code aus? Die ehrliche Antwort, die für fast jedes Projekt gilt: Der eigene blinde Fleck bleibt ein blinder Fleck, egal wie gut das Werkzeug ist. Genau dafür sind fremde Augen da.

Wir haben zwölf Funde am 23. Juli gemeldet: elf als private Security Advisories über GitHub, den zwölften als öffentliches Issue, weil es dabei um einen Qualitätsbug und nicht um Sicherheit ging. Am nächsten Tag saßen die wichtigsten Fixes bereits, und mit Version v0.8.0 sind sie jetzt alle draußen.

Die Funde

Elf der zwölf Funde waren sicherheitsrelevant und liefen über private Advisories. Inhaltlich bündeln sie sich zu diesen Themen:

FundSchwereKurz erklärt
Path Traversal in der SPA-Fallback-RoutekritischEine Catch-all-Route baute den Dateipfad direkt aus der URL, ohne ..-Segmente zu prüfen. Unauthentifiziert erreichbar, damit ließen sich Dateien außerhalb des vorgesehenen Verzeichnisses lesen
Standard-Admin admin/adminhochWar kein Admin-Passwort gesetzt, legte die Anwendung beim ersten Start ein Admin-Konto mit dem Passwort admin an, erreichbar über das öffentliche Login
Passwörter mit schnellem SHA-256 und statischem SaltmittelLogin-Passwörter wurden mit einem einzelnen schnellen Hash und einem festen, für alle Nutzer gleichen Salt gespeichert, statt mit einem echten Passwort-Verfahren
Fehlende Autorisierung auf mehreren Dashboard-EndpointsmittelEinige zustandsändernde Endpoints prüften die Admin-Rolle nicht, ein niedrig privilegierter Nutzer kam so an Aktionen, die ihm nicht zustanden
Unauthentifiziertes Lesen der Repo-StrukturmittelEine zu breite Ausnahme für .svg-Pfade in der Auth-Middleware ließ einen Endpoint durch, der die Dateistruktur indizierter Repositories preisgab
Session-Cookie ohne Secure-FlagmittelDas Session-Cookie wurde ohne Secure gesetzt, der Token konnte damit auch über unverschlüsseltes HTTP mitgeschickt werden
Webhook-SSRF über DNS-NamenniedrigDer SSRF-Schutz für ausgehende Webhooks prüfte nur IP-Literale, ein DNS-Name mit interner Auflösung kam daran vorbei

Der Path-Traversal-Fund war der ernsteste, weil er ohne Login erreichbar war und auf einer typischen Installation an die Konfiguration und die Datenbank herankommt. Der Standard-Admin ist die klassische Falle: harmlos im Testlauf, gefährlich in dem Moment, in dem jemand die Instanz ins Netz stellt, ohne ein Passwort zu setzen. Der Rest ist eine Mischung aus Rechtegrenzen und Härtung. Echte Befunde sind es alle, keine theoretischen Konstrukte.

Der zwölfte Fund war ein Qualitätsbug, keine Lücke: Starten zwei Reviews desselben Pull Requests gleichzeitig, entstehen doppelte Kommentare. Deshalb ging er als offenes Issue raus und nicht als Advisory. Ein Community-Beitrag hat inzwischen einen Riegel innerhalb eines Prozesses vorgeschoben. Für Deployments mit mehreren Worker-Prozessen ist die Sache damit noch nicht vollständig gelöst, deswegen ist das Issue bewusst offen.

Was der Maintainer daraus gemacht hat

Das Tempo ist die eine Hälfte, die Reihenfolge die andere. Der Maintainer hat nicht einfach von oben nach unten abgearbeitet, sondern nach Risiko. Am 24. Juli, dem Tag nach der Meldung, saßen zwischen 15:42 und 20:06 Uhr fünf Fixes: Path Traversal, Standard-Admin und Passwort-Hashing zuerst, dann die fehlenden Autorisierungen und das Session-Cookie. Der Webhook-SSRF, als einziger niedrig eingestuft, kam ein paar Tage später dran. Genau so soll Triage aussehen: das, was ohne Login eine Instanz aufmacht, geht vor der Härtung.

Die Fixes greifen an der Wurzel. Die SPA-Route löst den Pfad jetzt auf und prüft, dass er innerhalb des erlaubten Verzeichnisses bleibt, statt nur einzelne Muster zu sperren. Der Standard-Admin ist weg, das Passwort-Hashing auf ein echtes Verfahren umgestellt. Bemerkenswert ist auch, dass nicht alles vom Maintainer allein kam: Den Riegel gegen die doppelten Reviews steuerte ein anderer Beitragender bei. Ein Projekt, bei dem die Community an solchen Stellen mitzieht, verarbeitet eine Meldung schneller als eines, an dem eine Person alles allein tragen muss.

Wenn ihr Mira selbst betreibt

Updatet auf v0.8.0. Zwei Punkte, die dabei besonders zählen:

  • Der Standard-Admin. Wenn ihr Mira ohne gesetztes Admin-Passwort gestartet habt, existiert womöglich ein Konto admin mit dem Passwort admin. Ändert das Passwort, prüft die Zugriffe, und stellt die Instanz nicht ohne gesetztes Passwort ins offene Netz.
  • Bestehende Passwörter. Die mit dem alten Verfahren gespeicherten Hashes werden durch den Fix nicht rückwirkend stark. Ein Passwortwechsel nach dem Update sorgt dafür, dass der neue, sichere Weg auch wirklich greift.

Warum das zählt

Es ist der dritte Fall in dieser Reihe, und das Muster hält: sorgfältig verifizierte Funde, ein privater Meldeweg, ein Maintainer, der zügig und in der richtigen Reihenfolge liefert. Neu bei Mira ist die Selbstironie der Ausgangslage. Ein Werkzeug, das anderen Projekten beim Finden von Schwachstellen hilft, hatte selbst eine ganze Reihe davon. Das ist keine Schwäche, sondern der Normalfall. Niemand sieht den eigenen blinden Fleck, und je näher man an einem Codebestand dran ist, desto größer wird er.

Die verbreitete Sorge lautet, dass KI Lücken künftig schneller findet, als irgendwer patchen kann. Dieser Fall zeigt wieder die andere Möglichkeit: Wenn die Meldung präzise ist und das Projekt nach Risiko priorisiert, wird aus dem Tempo ein Vorteil für die Verteidigung. Danke an den Maintainer von Mira für die schnelle und saubere Reaktion.

Quellen8