KIberschutz: pipeshub behebt alle 13 Lücken

Transparenz vorweg: KIberschutz ist unser eigenes Projekt. Wir prüfen mit KI-Unterstützung Open-Source-Software auf Sicherheitslücken und melden die Funde verantwortungsvoll an die Maintainer. Veröffentlicht wird normalerweise erst, wenn der Fix bei den Nutzern angekommen ist. Bei pipeshub sind wir davon am 27. September abgewichen, zum ersten Mal.

Am 25. Juli haben wir dem Projekt dreizehn Lücken gemeldet. Als wir den Fall veröffentlicht haben, waren sechs davon nicht behoben, drei kritisch. Einen Tag später hat sich das Team gemeldet und innerhalb von drei Tagen alle sechs Lücken im Code geschlossen. Seit dem 12. Oktober sind alle dreizehn behoben und ausgeliefert, die letzten drei mit Version 0.10.0, darunter die letzte kritische. Wer pipeshub betreibt, sollte auf v0.10.0 aktualisieren und die Hinweise weiter unten beachten. Eine Anleitung zum Angreifen steht hier nicht drin, dafür das, was ihr selbst tun könnt.

Um welche Software es geht

pipeshub beschreibt sich als Open-Source-Plattform für "Workplace AI". Sie verbindet sich mit Slack, Google Drive, GitHub, Microsoft 365, Notion und über fünfzig weiteren Systemen, macht deren Inhalte durchsuchbar und beantwortet Fragen dazu mit Quellenangaben. Dieselben Inhalte stehen auch eigenen Agenten und MCP-Clients zur Verfügung. Apache-2.0, rund 3.800 Sterne auf GitHub, selbst hostbar per Docker Compose oder Helm.

Genau das macht die Lücken ernst. Eine solche Plattform hält Zugangsdaten zu den wichtigsten Firmensystemen und einen Index über deren Inhalte. Wer sie übernimmt, sitzt an der Schnittstelle zu all diesen Systemen.

Was wir gemeldet haben und was daraus wurde

flowchart TB
  A["25.07.<br/>13 Lücken gemeldet"] --> B["26.08.<br/>Nachfrage, bis dahin<br/>keine Reaktion"]
  B --> C["01.09.<br/>Antwort: Fixes für alle<br/>bis 10.09. zugesagt"]
  C --> D["14.09.<br/>v0.8.0 behebt fünf"]
  D --> E["19.09.<br/>Nachfrage mit Patches<br/>für die übrigen acht"]
  E --> F["27.09.<br/>Veröffentlichung,<br/>sechs offen"]
  F --> G["28.09.<br/>v0.9.0 und v0.9.1,<br/>Team meldet sich"]
  G --> H["29. und 30.09.<br/>drei weitere Fixes<br/>im Hauptzweig"]
  H --> I["12.10.<br/>v0.10.0 liefert<br/>die letzten drei aus"]
  class C decision
  class D success
  class F abort
  class G success
  class H success
  class I success
  classDef decision fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  classDef success fill:#14532D,stroke:#22C55E,color:#86EFAC
  classDef abort fill:#7F1D1D,stroke:#EF4444,color:#FCA5A5

Gemeldet haben wir über das private Meldeverfahren von GitHub, so wie es die SECURITY.md des Projekts vorsieht. Dort verspricht das Team eine Eingangsbestätigung in 48 Stunden, eine Einschätzung in fünf Werktagen, Updates alle sieben Tage und die Behebung kritischer Lücken in 30 Tagen. Nichts davon ist eingetreten. Fünf Wochen lang kam keine Antwort.

Am 26. August haben wir nachgefragt. Zwei Tage später war der erste Fix im Code, am 1. September kam die Antwort: Man entschuldige sich, die Meldungen seien angekommen, die kritischen würden priorisiert. Und: "We expect to have fixes for all reported issues ready by September 10."

Version 0.8.0 vom 14. September behob fünf Funde, eins der zugehörigen Advisories hat das Team selbst veröffentlicht, mit Nennung von uns als Melder (GHSA-47gf-3x62-7jfm). Am 19. September haben wir uns dafür bedankt und für jeden der übrigen acht Funde einen fertigen Fix-Vorschlag im privaten Advisory-Fork hinterlegt. Darauf kam zunächst keine Antwort. Zwei der acht hat das Team in der Woche darauf selbst behoben, ausgeliefert mit Version 0.9.0 am 28. September.

Am selben Tag hat sich das Team in den Advisories gemeldet. Es hat die Meldungen nach und nach geschlossen, jeweils mit dem Hinweis, dass der Fix im Hauptzweig liegt oder schon ausgeliefert ist, und uns in einem Fall eingeladen, selbst nachzutesten. Noch am Nachmittag erschien Version 0.9.1 mit Fixes für drei weitere Funde, darunter zwei der kritischen. Am 29. und 30. September folgten drei weitere Fixes im Hauptzweig, darunter der für die letzte kritische Lücke. Bis sie bei den Nutzern ankamen, dauerte es noch zwölf Tage: Das Team hatte das nächste Release für die Woche bis zum 4. Oktober angekündigt, erschienen ist es am 12. Oktober als Version 0.10.0. Wir haben alle drei Fixes am Code dieses Releases nachgeprüft. Auf Docker Hub zeigt auch latest seit dem 12. Oktober auf den neuen Stand.

Die fünf mit v0.8.0 behobenen betreffen die Erzeugung von Signaturschlüsseln und Einmalcodes mit einem nicht kryptografischen Zufallsgenerator, signierte Download-Links ohne Rechteprüfung, eine Verwechslung von Token-Arten und widerrufene Tokens, die weiter galten. Die zwei mit v0.9.0 behobenen: Normale Nutzer konnten die API-Schlüssel der eingebundenen Websuche-Dienste im Klartext abrufen, und ein interner Dienstaufruf ließ sich über einen manipulierten Pfad umlenken.

Die sechs Lücken aus unserer Veröffentlichung

Zu diesen Funden nennen wir weiter nur die Art der Lücke und die betroffene Komponente. Codestellen und Schritte zum Nachstellen lassen wir weg, auch jetzt noch: Das letzte Release ist frisch, und nicht jede Installation ist am ersten Tag aktualisiert. Wer die Software betreibt, soll einschätzen können, was auf dem Spiel steht, ohne dass wir eine Anleitung mitliefern.

Die Lücke bei der Code-Ausführung setzte ein Konto in der Instanz voraus, ebenso die im Web-Konnektor. Für die Lücke bei den Refresh-Tokens brauchte ein Angreifer ein abgeflossenes Token. Ohne jeden Zugang von außen kam man nach unserem Stand an keine der drei heran. Bei einer Plattform, an der die halbe Belegschaft angemeldet ist, ist "ein Konto" allerdings keine hohe Hürde.

Was ihr tun solltet

• Aktualisiert auf v0.10.0. Das schließt alle dreizehn Funde. Wer noch auf v0.9.1 oder älter läuft, hat die kritische Lücke bei der Code-Ausführung und die beiden hohen im OAuth-Anbieter und im Web-Konnektor weiter offen.
• Setzt SANDBOX_MODE=docker ausdrücklich, egal wie ihr installiert habt. Bis v0.9.1 fiel jede Installation ohne die Variable still auf die unsichere Variante zurück. Ab v0.10.0 ist die Code-Ausführung ohne gültigen Wert abgeschaltet, und die Variante ohne Isolation (local) startet nur noch, wenn zusätzlich SANDBOX_ALLOW_LOCAL=true gesetzt ist. Prüft nach dem Update in der laufenden Umgebung, welcher Wert tatsächlich gilt, und setzt SANDBOX_ALLOW_LOCAL nicht auf einem Server, an dem mehrere Menschen angemeldet sind.
• Begrenzt den ausgehenden Netzverkehr der Konnektor-Dienste, solange ihr nicht aktualisiert habt. Interne Netze und die Metadaten-Adresse eurer Cloud (169.254.169.254) sollten von dort nicht erreichbar sein. Das schadet auch nach dem Fix nicht.
• Räumt beim OAuth-Anbieter auf. Prüft, welche OAuth-Apps registriert sind und welche Tokens ausgestellt wurden, und widerruft, was ihr nicht zuordnen könnt. Wenn ihr den OAuth-Zugang für eigene Agenten oder MCP-Clients nicht braucht, gebt keine Tokens aus.
• Vergebt Konten nur an Menschen, denen ihr auch einen Shell-Zugang auf den Server geben würdet, solange ihr weder aktualisiert noch die Container-Isolation sicher gesetzt habt. Klingt drastisch, läuft aber genau darauf hinaus.
• Rotiert die API-Schlüssel eurer Websuche-Anbieter, falls ihr eine eingebunden habt. Die waren bis v0.9.0 für jeden Nutzer im Klartext abrufbar.

Warum wir am 27. September veröffentlicht haben

Unsere Regel ist, dass wir einen Fall erst beschreiben, wenn der Fix beim Nutzer angekommen ist. Davon weichen wir nur ab, wenn ein Projekt über Wochen nicht kooperiert. So sah es am 27. September aus, und die Entscheidung haben wir uns nicht leicht gemacht.

Seit der Meldung waren neun Wochen vergangen. Die SECURITY.md des Projekts nennt 30 Tage für kritische Lücken, das Team hatte selbst den 10. September zugesagt. Beide Termine waren verstrichen, ohne dass jemand einen neuen genannt hätte. Eine Zeile mit einem realistischen Zeitplan hätte gereicht, und wir hätten gewartet.

Fairerweise: Die SECURITY.md sieht eine Veröffentlichung "typically within 90 days" nach der Meldung vor, nach dem Fix. Wir waren bei Tag 64 und damit früher. Wir hielten das für vertretbar, weil die Lücken unabhängig von unserer Meldung existieren und wer gezielt danach sucht, sie finden kann. Wer pipeshub betrieb, hatte dagegen keinen Hinweis, dass etwas im Argen liegt.

Ob unsere Veröffentlichung den Ausschlag gegeben hat, wissen wir nicht. Wichtiger ist, dass in drei Tagen alle sechs Lücken im Code zugegangen sind. Das Veröffentlichen der Advisories bei GitHub bleibt Sache des Teams, das tun wir nicht selbst.

Wie es weitergeht

Mit v0.10.0 ist der Fall für uns abgeschlossen: Alle dreizehn gemeldeten Lücken sind behoben und ausgeliefert, 79 Tage nach der Meldung. Auf unserer Statusseite steht er unter dem Klarnamen mit allen Funden. Offen ist noch die Veröffentlichung der übrigen zwölf Advisories bei GitHub. Das Team hat uns am 11. Oktober zugesagt, sie für die behobenen Funde zu veröffentlichen. Bis dahin bleibt dieser Text die einzige öffentliche Beschreibung.