Die Macher von Tails haben zwei neue Versionen im Köcher: Tails 6.19 und Tails 7.0rc2. Die 6.19er-Fassung aktualisiert im Wesentlichen zentrale Bestandteile. Der 7er-Release-Kandidat bringt kleine Verbesserungen – und ein schwankendes Release-Datum.

Die Release-Ankündigung zu Tails 6.19 nennt die Aktualisierung unter anderem der zentralen Anonymisierungskomponenten. Der Tor-Browser kommt in Version 14.5.6 mit, der Tor Client hingegen in Fassung 0.4.8.17. Der Mail-Client Thunderbird ist auf Stand 128.13.0 dabei. Eine Fehlerkorrektur haben die Entwickler zudem vorgenommen. Bei der Konfiguration von Bridges in der Tor-Connection haben sie eine irrelevante Fehlermeldung entfernt, die lediglich Verwirrung stiftet.

Tails 6.19 steht als Image für USB-Sticks zum Herunterladen bereit, außerdem stellen die Maintainer ein ISO-Abbild für DVDs oder VMs zur Verfügung.

Neuer Release-Kandidat im 7er-Entwicklungszweig

Der neue Tails-7-Zweig hat erst vor einigen Tagen das Licht der Welt erblickt. Zu den wichtigsten Neuerungen gehört etwa der Wechsel der Basis auf Debian 13 mit dem Codenamen „Trixie“. Außerdem kommt als Desktop-Umgebung Gnome 48 zum Einsatz. Einige alte Tools mussten neuen weichen, wobei die Entwickler jedoch auch Dinge kaputt gemacht haben – etwa das „Root Terminal“ lässt sich nicht mehr aufrufen. Interessierte müssen sich bislang temporär mit Workarounds behelfen, indem sie sich etwa mittels des Befehls sudo -i in der das Terminal ersetzenden Console Adminrechte besorgen.

Der jetzt verfügbare zweite Release-Kandidat hat kleine Verbesserungen gegenüber der ersten Fassung aufzuweisen. Wenn etwa nicht die mindestens benötigten 3 GByte RAM in einer Maschine stecken, zeigt Tails 7 eine Benachrichtigung an. Das „Root Terminal“ haben die Programmierer in „Root Console“ umbenannt – das sollte den manuellen Workaround unnötig machen. Das „Places“-Menü haben sie ganz rausgeworfen. Im Release-Kandidat ist der Linux-Kernel ein paar Builds weiter als in rc1 und nun auf Stand 6.12.41 dabei. Das Release-Datum für Tails 7.0 sollte ursprünglich der 16. Oktober 2025 sein. Jetzt bringen die Tails-Macher auch den 18. September als mögliche Option ins Gespräch. Offenbar enthalten die Release-Kandidaten weniger Fehler als erwartet.

(dmk)

Microsoft setzt voll auf künstliche Intelligenz: Der KI-Assistent Copilot ist mittlerweile fester Bestandteil des cloudbasierten Office-Pakets M365. Viele Unternehmen nutzen diesen Dienst auch, um geheime Informationen zu be- und zu verarbeiten. Dass jedwede Zugriffe auf derlei sensible Dokumente protokolliert gehören, versteht sich von selbst. Allerdings sah Copilot das unter bestimmten Bedingungen anders. Microsoft wusste monatelang von der Lücke, behob sie jedoch erst vor wenigen Tagen. Das Unternehmen informierte weder Betroffene noch die Öffentlichkeit.

„Copilot, fasse mir bitte den Geschäftsbericht für das zweite Quartal 2025 zusammen“ – so oder ähnlich könnte eine typische Anfrage lauten. Im „Audit-Log“, also dem Protokoll aller Zugriffe auf Dokumente in der Microsoft-Cloud, taucht dann ein Lesezugriff auf das Quelldokument durch Copilot auf. Befragte man den virtuellen Assistenten auf eine spezielle Art zu einem in M365 gespeicherten Dokument, erzeugte das jedoch lediglich einen leeren Protokolleintrag. Um dieses Verhalten zu erzeugen, genügte die Bitte, das Dokument nicht in der Antwort zu verlinken, sondern lediglich zusammenzufassen.

Dieses seltsame Verhalten fiel Zack Korman, dem CTO eines SaaS-Startups, Anfang Juli 2025 auf. Es erschien ihm problematisch, denn nur mittels vollständiger Audit-Logs können Unternehmen ihre Sicherheits- und Compliance-Anforderungen umsetzen und sich das Abfließen von Dokumenten in unbefugte Hände erkennen. Ein allzu neugieriger oder gar von Angreifern bestochener Mitarbeiter konnte den Copilot-Fehler ausnutzen und sich unerkannt Informationen verschaffen – offenkundig sind verfälschte Protokolle ein Sicherheitsproblem.

Sicherheit ist ein Prozess – aber welcher?

Korman meldete sich also beim Microsoft Security Response Center (MSRC) und vertraute darauf, dass die Profis in Redmond ihren dokumentierten Ablauf einhalten, das Problem beheben und betroffene Kunden informieren würden. Seine anfängliche Euphorie wich jedoch schnell der Ernüchterung: Zwar begann das MSRC nur drei Tage nach seiner Meldung damit, das Problem nachzustellen, doch weitere drei Tage später, am 10. Juli, hatten die Techniker offenbar bereits stillschweigend eine Fehlerbehebung ausgerollt.

Das widersprach der eigenen Prozessbeschreibung – was Korman veranlasste, noch einmal bei den Redmondern anzuklopfen und den Status zu erfragen. Am 2. August meldete der Softwareriese Vollzug: Man werde zwei Wochen später, am 17. August, eine Aktualisierung für die M365-Cloud einspielen und Korman könne einen Tag später seinen Fund veröffentlichen. Als dieser nachfragte, wann er denn eine CVE-Schwachstellenkennung für die von ihm gefundene Lücke erhalte, antwortete das MSRC abschlägig. Man vergebe generell keine CVE-IDs für Lücken in Cloud-Produkten, wenn Endkunden nicht selbst handeln müssten.

Auch das widersprach deutlich den Aussagen, die das MSRC vor etwas mehr als einem Jahr coram publico tätigte. Damals hieß es, man wolle künftig auch in Cloud-Diensten für kritische Lücken CVE-IDs vergeben, explizit auch in Fällen, in denen Kunden nicht selbst tätig werden müssen. Das solle für mehr Transparenz sorgen, versprach das MSRC im Kielwasser eines Security-GAUs: Vermutlich chinesische Angreifer hatten einen Master-Key für Azure geklaut. Doch zurück zur Copilot-Lücke: Als Korman diese Diskrepanz anmerkte, schwenkte das Microsoft-Sicherheitsteam um. Man verstehe, dass er nicht den vollen Durchblick durch den Prozess habe, hieß es leicht passiv-aggressiv, doch die Lücke sei lediglich als „wichtig“ und nicht als „kritisch“ eingestuft. Damit unterschreite sie die Microsoft-eigene Schwelle zur Vergabe einer CVE-ID.

Monatelang fehlerhafte Audit-Logs? Nicht der Rede wert!

Korman wunderte sich erneut: Von einer Klassifizierung der Sicherheitslücke wusste er bis dato nichts – üblicherweise wird diese vom betroffenen Unternehmen gemeinsam mit dem Entdecker vorgenommen und nötigenfalls ausdiskutiert. Zu Diskussionen zeigte sich Microsoft in diesem Fall jedoch genauso wenig aufgelegt wie zu Transparenz. Am 14. August teilte man Korman mit, man verzichte nicht nur auf die Vergabe einer CVE-ID, sondern plane darüber hinaus auch nicht, Kunden über die Lücke zu informieren.

Der Entdecker hatte zwischenzeitlich festgestellt, dass das Problem noch erheblich länger bestanden haben musste als ursprünglich vermutet: Bereits im August 2024, mithin ein Jahr vor Kormans Fund, hatte Michael Bargury, Gründer eines KI-Startups, in einem Vortrag auf der Sicherheitskonferenz Black Hat auf die Fehler bei der Protokollierung von KI-Dateizugriffen in der Microsoft-Cloud aufmerksam gemacht. Reichlich Zeit für den Redmonder Softwaregiganten, sich des Problems anzunehmen – dieser reagierte jedoch erst letzte Woche.

Für Unternehmen, die M365 und Copilot nutzen, bleibt ein schaler Beigeschmack. Sie müssen der Tatsache ins Auge sehen, dass ihre Audit-Protokolle möglicherweise seit Monaten fehlerhaft sind und Zugriffe stattgefunden haben, die nicht mehr nachvollziehbar sind. Auch Angreifer und Industriespione dürften die Prompt-Tricks spätestens seit der letztjährigen Black-Hat-Konferenz in ihr Instrumentarium aufgenommen haben, was die Compliance-Bauchschmerzen bei Betroffenen noch verstärken dürfte.

Microsoft rief als vertrauensbildende Maßnahme nach dem letztjährigen Azure-Disaster die „Secure Future Initiative“ aus, steht aber wegen schlampiger Sicherheitspatches und miserabler Kommunikation seit Monaten in der Kritik. heise-security-Gründer Jürgen Schmidt fasste diese in einem Kommentar mit einer rustikalen Vokabel zusammen: Bullshit. Der jüngste Vorfall scheint diesen Eindruck zu festigen.

(cku)

Angreifer können an zwei Sicherheitslücken in Dell Remote Access Controller (iDRAC) zum Verwalten von Servern ansetzen. Eine aktualisierte Version ist gegen mögliche Attacken abgesichert.

Sicherheitspatch verfügbar

In einer Warnmeldung schreiben die Entwickler, dass konkret iDRAC Service Module unter Windows bedroht ist. Sie versichern, dass die Version 6.0.3.0 abgesichert ist. Alle vorigen Ausgaben sollen verwundbar sein.

Für beide Attacken benötigen lokale Angreifer bereits niedrige Nutzerrechte, Angriffe sind also nicht ohne Weiteres möglich. In beiden Fällen kann Schadcode auf Systeme gelangen und diese kompromittieren (CVE-2025-38742 „mittel„, CVE-2025-38743 „hoch„).

Weiterführende Details zu möglichen Angriffsszenarien gibt es derzeit nicht. Unbekannt bleibt auch, ob Angreifer die Lücken bereits ausnutzen. Um Attacken vorzubeugen, sollten Server-Admins sicherstellen, dass iDRAC auf dem aktuellen Stand ist.

Anfang August hat Dell Sicherheitslücken in der Backuplösung PowerProtect geschlossen.

(des)