Amazon Web Services hat für seinen Monitoring-Dienst CloudWatch eine neue Funktion zur automatischen Erstellung von Incident-Reports angekündigt. Laut AWS können Kunden damit innerhalb weniger Minuten umfassende Post-Incident-Analyseberichte generieren. Das Timing der Veröffentlichung ist bemerkenswert: Sie erfolgt kurz nach dem schweren Ausfall der AWS-Infrastruktur, der zahlreiche Dienste auch von anderen Anbietern lahmlegte.

Die neue CloudWatch-Funktion sammelt automatisch Telemetriedaten, Nutzeraktionen während der Fehlersuche sowie Systemkonfigurationen und fügt diese zu einem strukturierten Bericht zusammen. Laut AWS umfassen die generierten Reports Executive Summaries, detaillierte Zeitverläufe der Ereignisse, Impact-Assessments und konkrete Handlungsempfehlungen. Das System korreliert dabei die verschiedenen Datenquellen, um ein möglichst vollständiges Bild des Vorfalls zu zeichnen.

CloudWatch ist Amazons zentrale Plattform für die Echtzeitüberwachung von Cloud-Ressourcen und -Anwendungen. Der Dienst bietet laut AWS-Dokumentation eine systemweite Übersicht über die Anwendungsperformance, operative Systemgesundheit und Ressourcenauslastung. Die neue Incident-Report-Funktion erweitert dieses Monitoring jetzt um eine strukturierte Nachbetrachtung von Störfällen.

Das Versprechen: Automatisch immer besser

Die automatisch erstellten Berichte sollen IT-Teams helfen, wiederkehrende Muster zu erkennen und präventive Maßnahmen zu implementieren. AWS verspricht, dass Kunden durch die strukturierte Post-Incident-Analyse ihre operative Aufstellung kontinuierlich verbessern können. Die Funktion erfasst dabei kritische Betriebstelemetrie, Servicekonfigurationen und Untersuchungsergebnisse automatisch – manuelle Zusammenstellungen entfallen. Inwiefern dies jetzt bereits bei Amazons jüngstem Ausfall intern geholfen haben könnte, bleibt jedoch offen. Nach den versprochenen wenigen Minuten lagen hierbei jedenfalls keine gesicherten Informationen vor.

Die neue CloudWatch-Funktion ergänzt die kürzlich eingeführte KI-gestützte Fehleranalyse in CloudWatch Investigations. Diese nutzt generative KI zur Diagnose und automatischen Ursachenanalyse von Betriebsproblemen. Die Integration mit AWS Systems Manager soll die Komplexität von Cloud-Umgebungen bei der Fehlerbehebung reduzieren. Laut AWS ist der Dienst in mehreren Regionen verfügbar, darunter Europe (Frankfurt). Die Kosten entsprechen denen von CloudWatch Investigations, für die Funktion gelten keine zusätzlichen Aufpreise.

(fo)

In dieser Folge des Videocasts software-architektur.tv sprechen Oliver Zeigermann und Lisa Maria Schäfer über das Thema generative KI. Dabei zeigen sie eine Demo-Applikation.

Im Fokus stehen die Grundlagen von GenAI, aber Oliver wird auch zeigen, wie man KI verstehen kann, ohne jemals einen Computer anzufassen. Die Folge ist bewusst spielerisch ausgelegt.

Da Lisa Maria Schäfer vor der Kamera ist, wird sie diesmal keine Sketchnotes malen.

Livestream am 24. Oktober

Die Ausstrahlung findet am Freitag, 24. Oktober 2025, live von 13 bis 14 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat, Bluesky, Mastodon, Slack-Workspace oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zur Folge finden sich auf der Videocast-Seite.

(rme)

Die Rust-Library async-tar enthält eine Schwachstelle, die es Angreifern ermöglicht, versteckte Inhalte in tar-Archiven einzuschleusen.

Das auf sichere Laufzeitumgebungen spezialisierte Unternehmen Edera hat den Fehler veröffentlicht und ihm den etwas dramatischen Namen TARmageddon gegeben. Das Unternehmen hatte einen eigenen Fork der Library gepflegt, der inzwischen archiviert ist, aber noch einen Patch erhält.

Die Library async-tar dient dazu, tar-Archive asynchron zu lesen und zu schreiben. Sie ist deutlich performanter als die synchron arbeitende tar-Library für Rust.

Der zugehörige CVE-Eintrag (Common Vulnerabilities and Exposures) CVE-2025-62518 hat den Schweregrad „hoch“ mit dem Wert 8,1 von 10.

Fork ohne Patch: Zeit zum Wechseln

Auch wenn sich der CVE-Eintrag auf die Library astral-tokio-tar bezieht, betrifft die Schwachstelle die Library async-tar und deren Forks. Der am weitesten verbreitete Fork tokio-tar, mit über 7 Millionen Downloads im Rust-Paketmanager crates.io, wird seit zwei Jahren nicht mehr gepflegt. Damit bleibt er weiter verwundbar.

Wer tokio-tar nutzt, sollte auf den Fork astral-tokio-tar oder eine andere Alternative wie die nicht asynchrone tar-Library wechseln. Der Fork astral-tokio-tar hat mit Version 0.5.6 ein Update erhalten, das die Schwachstelle behebt.

Verwirrung in den Headern

Der Fehler liegt in der Verarbeitung der Header für die tar-Dateien. async-tar verarbeitet sowohl das ustar- als auch das PAX-Format. Wenn eine Datei Header für beide Formate enthält, kommt es zur Inkonsistenz: Der Parser nutzt die im ustar-Header angegebene Größe, während für andere tar-Werkzeuge die PAX-Werte gelten.

Wenn der PAX-Header die richtige Dateigröße angibt, ustar aber mit der Größe 0 angegeben ist, springt der Parser nicht weiter, sondern verarbeitet den Inhalt verschachtelter Archive, die aber andere tar-Werkzeuge nicht als solche erkennen und damit auch nicht untersuchen.

Der Blogbeitrag zu der Schwachstelle zeigt das in folgendem Kurzbeispiel:

Expected by scanner/validator:
Entry 1: "outer-file.txt"
Entry 2: "inner-tar-file.tar" (0 bytes per ustar, but N bytes in PAX)
Entry 3: "next-file.txt"

Actually extracted by tokio-tar:
Entry 1: "outer-file.txt"
Entry 2: "inner-tar-file.tar" (0 bytes per ustar)
Entry 3: "inner-file1.txt" (from inner TAR)
Entry 4: "inner-file2.txt" (from inner TAR)
Entry 5: "next-file.txt" (continues normally)

Der Parser von async-tar verarbeitet die verschachtelten Dateien als reguläre Inhalte des Archivs.

Als theoretisches Angriffsszenario führt der Beitrag den Python-Paketmanager uv auf, der ebenso von Astral stammt wie der inzwischen gepatchte Fork astral-tokio-tar. Vor dem Patch der in uv genutzten Library hätten Angreifer versteckten Schadcode über ein verschachteltes tar-Archiv einschmuggeln können.

Stabile Patches

Edera hat den Bug vor zwei Monaten entdeckt. Anschließend hat das Team einen Patch erstellt und die Maintainer der Libraries informiert. Die Libraries astral-tokio-tar und krata-tokio-tar haben den Patch erhalten, und der Maintainer von async-tar hat den Fehler selbst behoben. Allerdings finden sich im Paketmanager crates.io für async-tar und krata-tokio-tar nach wie vor etwa ein Jahr alte Versionen ohne Patch.

Dass der Bug erst jetzt veröffentlicht wurde, liegt an dem Embargo von 60 Tagen seit Edera den Maintainern den Bug gemeldet hat.

(rme)