KIberschutz: Speakr fixt vier Lücken in Stunden
Wir meldeten dem Transkriptions-Tool Speakr vier Lücken. Wenige Stunden später waren alle gefixt und released. Was Projekte daraus mitnehmen können.
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 dem ersten Fall bei logtide ist jetzt der zweite durch, und er ist noch schneller gelaufen.
Was passiert ist
Das Projekt war Speakr, eine selbst gehostete Web-Anwendung zum Transkribieren von Audioaufnahmen. Wer Meetings mitschneidet und die Mitschrift nicht bei einem Cloud-Dienst abladen will, ist genau die Zielgruppe. Das Projekt steht unter AGPL-3.0, ist in Python geschrieben und hat rund 3.500 Sterne auf GitHub, also kein Nischenexperiment.
Wir haben vier Funde bestätigt und am 15. Juli gemeldet: drei als private Security Advisories über GitHub, den vierten als öffentliches Issue, weil es dabei nur um veraltete Abhängigkeiten ging. Am selben Abend waren alle vier gefixt und in Version v0.10.2-alpha veröffentlicht. Die zugehörigen Advisories hat der Maintainer am Morgen des 16. Juli publiziert.
Die vier Funde
| Fund | Schwere | Kurz erklärt |
|---|---|---|
| Stored XSS über Tag-Farbe und Tag-Name | hoch | Ein Gruppen-Admin konnte mit einer präparierten Tag-Farbe aus dem HTML-Attribut ausbrechen. Der Code lief dann im Browser jedes Gruppenmitglieds, das die Account-Seite öffnete |
| SSO-Account-Übernahme über unverifizierte E-Mail | mittel | Ein Login wurde auch dann mit einem bestehenden Konto verknüpft, wenn der Identity Provider die E-Mail nicht als verifiziert markiert hatte |
| Webhook-SSRF über DNS-Rebinding | mittel | Zwischen URL-Prüfung und Verbindungsaufbau lag ein Zeitfenster, in dem die Auslieferung auf eine interne Adresse umgebogen werden konnte |
| Veraltete Werkzeug-Version | mittel | Zwei bekannte Multipart-DoS-Lücken (CVE-2023-46136, CVE-2024-49767) steckten noch in der Abhängigkeit |
Der XSS-Fund war der unangenehmste, weil er eine Rechtegrenze überschreitet: von einem Gruppen-Admin zu allen Mitgliedern der Gruppe. Der SSO-Fund ist in der richtigen Konstellation ebenfalls scharf, da geht es um eine echte Kontoübernahme, nur eben gebunden an einen Identity Provider, der kein email_verified mitschickt. Beim SSRF und der veralteten Werkzeug-Version geht es eher um Härtung. Echte Befunde sind alle vier, keine theoretischen Konstrukte.
Was der Maintainer daraus gemacht hat
Die Fixes sind nicht einfach schnell, sondern auch sauber. Beim SSRF-Fund verifiziert die Auslieferung jetzt die Adresse, mit der sich der Socket tatsächlich verbunden hat, und bricht vor dem Senden ab, wenn diese privat, loopback oder link-local ist. Prüfung und Verbindungs-Check nutzen denselben Test auf private Adressen, damit beide gar nicht erst auseinanderlaufen können. Das ist die Lösung, die das Problem an der Wurzel packt, statt nur den gemeldeten Weg zuzumauern.
Beim SSO-Fund hat er sich für den unbequemeren Weg entschieden: Die Prüfung auf verifizierte E-Mails war vorher ein Opt-in, jetzt ist sie der Standard. Das kann Deployments treffen, deren Identity Provider kein email_verified mitschickt. Genau dafür stehen in den Release-Notes ein deutlicher Hinweis, die betroffene Konstellation und eine Ausweichoption. Wer den Standard aufweicht, bekommt beim Start eine Warnung ins Log. Sicher als Voreinstellung, mit einer bewussten Tür für Sonderfälle.
Bemerkenswert ist außerdem, dass der Security-Fokus nicht erst durch unsere Meldung entstanden ist. Einen Tag vorher, am 14. Juli, war v0.10.1-alpha erschienen, ausdrücklich als Härtungs-Release: Der fest eingebaute Fallback-Secret-Key flog raus, Passwort-Reset-Links wurden auf einmalige Nutzung umgestellt, und die Anwendung setzt seitdem selbst Security-Header inklusive Content-Security-Policy, damit auch ein Deployment ohne vorgelagerten Reverse Proxy geschützt ist. Diese CSP war dann übrigens streng genug, dass die Swagger-Seite nicht mehr lud, weil sie ihre Dateien von einem öffentlichen CDN holte. Auch das ist in v0.10.2 behoben, die Dateien liefert die Anwendung jetzt selbst aus. Wir sind hier also auf ein Projekt getroffen, das ohnehin schon aufgeräumt hat. Das erklärt einen Teil der Geschwindigkeit.
Tipp für Projekte: Nutzt den Advisory-Prozess von GitHub
Wenn wir eine Sache aus diesem Fall mitgeben, dann die: Richtet in eurem Repository die GitHub Security Advisories ein. Der Prozess ist wirklich gut und kostet euch fast nichts.
Was ihr davon habt:
- Ein privater Meldeweg. Meldende brauchen keine E-Mail-Adresse zu erraten und müssen nichts in ein öffentliches Issue schreiben, das die Lücke sofort für alle sichtbar macht.
- Ein privater Ort zum Reden und Reparieren. Diskussion, Patch und Test laufen im geschützten Rahmen, bis der Fix draußen ist.
- Veröffentlichung auf Knopfdruck. Ihr entscheidet, wann das Advisory publiziert wird. Danach landet es automatisch in der GitHub Advisory Database, und die Abhängigkeits-Warnungen eurer Nutzer greifen.
- Sauberes Credit. Meldende werden als Reporter eingetragen. Das klingt nach einer Kleinigkeit, ist aber genau der Anreiz, der dafür sorgt, dass Leute den nächsten Fund auch wieder bei euch melden statt anderswo.
Der Aufwand liegt bei ein paar Klicks in den Repository-Einstellungen. Eine SECURITY.md, die auf diesen Weg zeigt, macht es rund.
Wenn ihr Speakr selbst betreibt
Updatet auf v0.10.2-alpha. Für die meisten Installationen ist das ein Image-Pull ohne Konfigurationsänderung. Ein Sonderfall: Wenn ihr SSO nutzt und euer Identity Provider kein email_verified mitschickt, lest vorher den Hinweis in den Release-Notes, sonst kommen eure Nutzer nach dem Update nicht mehr rein. Die gängigen Provider wie Keycloak, Authentik, Google oder Microsoft Entra schicken den Claim, für die meisten ändert sich also nichts.
Warum das zählt
Zwei Fälle sind noch keine Statistik, das behaupten wir nicht. Aber das Muster aus dem logtide-Fall wiederholt sich: sorgfältig verifizierte Funde, ein privater Meldeweg, ein Maintainer, der zügig liefert. Bei Speakr kam dazu, dass die Grundlagen schon standen. Ein Projekt, das vorher aufräumt, kann eine Meldung in Stunden verarbeiten statt in Wochen.
Die verbreitete Sorge lautet, dass KI Lücken künftig schneller findet, als irgendwer patchen kann. Dieser Fall zeigt die andere Möglichkeit: Wenn die Meldung präzise ist und das Projekt vorbereitet, wird aus dem Tempo ein Vorteil für die Sicherheit. Danke an Murtaza Nasir für die schnelle und unkomplizierte Zusammenarbeit.