Vergangene Woche hat Trellix, das IT-Sicherheitsunternehmen, das aus dem Zusammenschluss von FireEye und McAfee hervorging, einen IT-Vorfall gemeldet: Angreifer haben Zugriff auf Quellcode-Repositories erlangt. Da war noch unklar, wer dafür verantwortlich zeichnet. Nun hat sich die kriminelle Vereinigung RansomHouse auf ihrer Darknet-Webseite zu dem Datenklau bekannt.

Der konkrete Darknet-Eintrag hält einen Download-Link auf ein Sample vor. Angeblich hat die Bande die Daten von McAfee am 17. April 2026 „encrypted“, also verschlüsselt. Davon schreibt Trellix jedoch nichts. Die fein geschliffenen Formulierungen von Trellix schließen konkret eine Verschlüsselung der Repositories jedoch nicht aus. Das Unternehmen schreibt lediglich, dass es keine Belege dafür gebe, dass Quellcode-Releases oder der Verteilungsprozess betroffen sind oder dass der Quellcode missbraucht wurde.

Immerhin kommt mit dem Bekenntnis von RansomHouse etwas Licht ins Dunkel, wer bei dem IT-Sicherheitsunternehmen eingebrochen ist und sich den Quellcode von Software beschafft hat. Der Umfang der kopierten Daten bleibt jedoch weiter unklar, ebenso, welche Repositories und damit Informationen nun genau offenliegen.

Zumindest Klarheit über Täter

In der vergangenen Woche schrieb Trellix, dass das Unternehmen unbefugte Zugriffe auf einen Teil der Quellcode-Repositories bemerkt hatte. Es zog daraufhin den eigenen Angaben nach führende Forensikexperten zur Klärung hinzu. Auch die Strafverfolgungsbehörden hat Trellix demnach informiert. Es blieb zu dem Zeitpunkt unklar, wer für den IT-Einbruch verantwortlich war.

(dmk)

Die Integrationssoftware für unter anderem Geschäftsinformationen IBM App Connect Enterprise und IBM Integration Bus for z/OS sind über eine Softwareschwachstelle angreifbar. Schadcode kann Systeme kompromittieren.

Schadcode-Sicherheitslücke

Davor warnen die Entwickler in einem Beitrag. Im Zuge einer Directory-Traversal-Attacke (CVE-2026-67030 „hoch“) können Angreifer auf eigentlich abgeschottete Daten und Verzeichnisse zugreifen, um Schadcode abzuladen und auszuführen. Bislang gibt es keine Berichte, dass Angreifer die Sicherheitslücke schon ausnutzen.

Die Entwickler geben an, dass davon die folgenden Versionen bedroht sind: IBM App Connect Enterprise 12.0.1.0 bis 12.0.12.24 und 13.0.1.0 bis 13.0.7.0 und IBM Integration Bus for z/OS 0.1.0.0 bis 10.1.0.6. Die Lücken seien in den folgenden Ausgaben geschlossen:

• IBM App Connect Enterprise v12- Fix Pack Release 12.0.12.25
• IBM App Connect Enterprise v13- Fix Pack Release 13.0.7.1
• IBM Integration Bus for z/OS v10.1 – Fix Pack Release 10.1.0.7

(des)

Debian verschärft für die kommende Version 14 („Forky“) seine Qualitätsanforderungen deutlich: Pakete dürfen nur noch dann nach „testing“ wandern, wenn sie sich reproduzierbar bauen lassen. Das hat das Debian-Release-Team angekündigt. Die entsprechende Migrationslogik ist bereits aktiv. Sie betrifft sowohl neue Pakete, die sich nicht reproduzieren lassen, als auch bestehende Pakete, deren Reproduzierbarkeit sich verschlechtert hat.

Was reproduzierbare Builds leisten

Reproduzierbare Pakete („reproducible builds“) erzeugen aus identischem Quellcode und in gleicher Build-Umgebung bit-identische Binärpakete. Damit werden Build-Prozesse nachvollziehbar und manipulationssicher. Unterschiede zwischen zwei Builds lassen sich so eindeutig auf echte Änderungen oder mögliche Manipulationen zurückführen.

Nicht reproduzierbare Builds entstehen oft durch banale Faktoren: Zeitstempel, zufällige Build-IDs oder eine nichtdeterministische Reihenfolge von Dateien. Zwei Builds desselben Quellcodes können dadurch unterschiedliche Binärdateien erzeugen, obwohl sich funktional nichts geändert hat. Reproducible Builds eliminieren solche Unterschiede systematisch, etwa durch normierte Zeitstempel oder ein deterministisches Packaging.

Vom Qualitätsziel zur Release-Voraussetzung

Debian arbeitet bereits seit Jahren mit dem Reproducible-Builds-Projekt an entsprechenden Mechanismen. Neu ist, dass Reproduzierbarkeit nicht mehr nur als Qualitätsziel gilt, sondern direkt über die Paketmigration nach „testing“ entscheidet. Damit macht die Distribution reproduzierbare Builds faktisch zur Voraussetzung für den regulären Release-Prozess. Den aktuellen Reproduzierbarkeitsstatus aller Pakete listet reproduce.debian.net auf.

Parallel baut Debian seine automatisierten Tests aus. Laut Release Team prüft die CI-Infrastruktur inzwischen auch sogenannte binNMUs automatisch mit autopkgtests. Dabei handelt es sich um reine Neuübersetzungen von Binärpaketen ohne Änderungen am Quellcode, etwa nach ABI-Übergängen oder neuen Bibliotheksversionen. Bislang lag der Fokus der Tests vor allem auf klassischen Source-Uploads.

Längere Warteschlangen durch loong64

Die neue Architektur loong64 sorgt derzeit vor allem für längere Warteschlangen in Debians Build- und Testinfrastruktur. Weil viele Pakete auf allen Architekturen neu gebaut werden mussten und Debian nun auch binNMUs per autopkgtest prüft, dauert die Migration nach „testing“ derzeit länger.

Zugleich erinnert Debian die Maintainer daran, dass sie selbst für die erfolgreiche Migration ihrer Pakete nach „testing“ verantwortlich bleiben. Blockieren fehlgeschlagene autopkgtests in Reverse-Dependencies die Migration, sollen die Maintainer entsprechende Release-Critical-Bugs melden.

(fo)