Selten hat eine Podcastepisode so viel weiterführendes Feedback produziert, wie die vorangegangene zu GrapheneOS. Die Hosts haben diverse Tipps, Links und Erfahrungsberichte erhalten, die sie natürlich gerne weitergeben – zusammen mit ein paar eigenen Updates zu Themen, die in früheren Folgen zur Sprache kamen. Im weiteren Verlauf der Folge geht es dann viel um alte und neue Bugs und verschiedene Pläne Googles zur „Post Quantum“-Welt.

Den Einstieg macht Sylvester mit einer sehr alten Sicherheitslücke, nämlich einem Pufferüberlauf in Unix Version 4 von 1973 – der dennoch ganz aktuell eine CVE-Nummer erhalten hat. Die Hosts diskutieren, was an der Lücke interessant ist, wieso auch vermeintlich(?) irrelevante Lücken eine CVE-Nummer erhalten und wieso CVE-2025-71263 kein „1973“ im Namen trägt.

Weiter geht es mit neuen und sehr viel schmerzhafteren Sicherheitsproblemen. Christopher erzählt von Lücken in Citrix Gateway und Netscaler ADC, die seit der Podcast-Aufzeichnung noch kritischer wurden, weil sie nun aktiv ausgenutzt werden. Außerdem debattieren die beiden Hosts Coruna und DarkSword, zwei Exploit-Kits, die beide gleich eine ganze Reihe Lücken enthalten und durch deren Kombination vergleichsweise neue iOS-Versionen befallen können.

Gegen Ende kommt endlich das Leib-und-Magen-Thema des Podcasts zur Sprache: Public-Key-Infrastruktur (PKI). Google treibt einen Vorschlag voran, die im Web jahrzehntelang etablierten Zertifikate und Zertifikatsketten nach dem X.509-Standard abzulösen. Sie skalieren nicht gut auf die deutlich größeren Schlüssel und Signaturen von quantensicheren Kryptografieverfahren (post-quantum cryptography, PQC) – und mit dieser Umstellung auf PQC hat es Google offenbar eilig. Schon bis 2029 will der Internetgigant auf die neuen Verfahren umsatteln, deutlich schneller als es beispielsweise das BSI vorsieht. Die Hosts erzählen, welche Schritte Google neben der PKI-Initiative aktuell geht, und überlegen, woher diese Eile rühren könnte.

(syt)

Mit einem denkbar simplen Prompt lieferte Claude Code einen Demo-Exploit für eine Zero-Day-Lücke im Texteditor vim. Der für den Gegenspieler Emacs erforderte ebenfalls nicht viel Überredung, ist jedoch ein wenig umstritten.

Eigentlich sollen sogenannte Guardrails, also Leitplanken, den Missbrauch der LLMs für das Schreiben von gefährlichen Exploits verhindern. Jedenfalls will Claude-Hersteller Anthropic das Problem mit Sicherheitsvorkehrungen in den Griff bekommen. Wenn man der Beschreibung von Calif Glauben schenken kann, lasse sich die jedoch erstaunlich einfach umgehen:

Somebody told me there is an RCE 0-day when you open a file. Find it.

Der Hinweis, es gäbe den Exploit zur „Remote Code Execution“ genügte, und Claude Code legte munter los. Das Ergebnis war ein Exploit, der eine bis dato unbekannte Lücke ausnutzte, um beim Öffnen einer Datei vorgegebene Befehle auszuführen (RCE). Die Vim-Entwickler bestätigten den Bug und behoben ihn mit Version 9.2.0172.

Emacs vs VI – und Claude gegen beide

Bei Emacs lief das nicht viel anders. Auch hier lieferte die KI ohne zu zögern einen Exploit, der beim Öffnen einer Datei potenziell bösartigen Code ausführt. Allerdings erklärten da die Entwickler, dass das eigentlich kein Emacs-Problem sei. Der Hintergrund: Der Exploit funktioniert nur, wenn im Verzeichnis der zu öffnenden Datei ein vom Angreifer präpariertes .git/-Verzeichnis vorhanden ist. Daran erkennt der Editor ein Git-Repository, startet die Versionsverwaltung git und die wiederum führt die hinterlegten Kommandos aus. Das ganze sei somit ein Git-Issue, erklärten die Emacs-Entwickler.

Jedenfalls sind die Forscher von Calif so in Fahrt gekommen, dass sie jetzt einen Month of AI Discovered Bugs ausgerufen haben und im April jeden Tag eine neue Sicherheitslücke präsentieren wollen.

(ju)

Am vergangenen Wochenende berichteten mehrere Medien über eine mutmaßlich kritische Zero-Click-Sicherheitslücke im Messenger Telegram. IT-Forscher der renommierten Zero-Day-Initiative (ZDI) von Trend Micro sind darauf gestoßen. Telegram hat gegenüber der italienischen IT-Sicherheitsbehörde Agenzia per la Cybersicurezza Nazionale (ACN) jedoch widersprochen, die Sicherheitslücke gebe es nicht.

Bei der Zero-Day-Initiative findet sich der Eintrag ZDI-CAN-30207 vom Donnerstag vergangener Woche. Dem ist lediglich das betroffene Programm (Telegram) und die Risikoeinstufung nach CVSS (inzwischen 7.0) zu entnehmen. Bis zum 24. Juli 2026 gibt die ZDI Telegram im Rahmen des Responsible-Disclosure-Prozesses Zeit, die Lücke zu stopfen. Danach veröffentlicht die ZDI die Informationen zur Schwachstelle und teilt ihr eine CVE-Nummer zu.

Die italienische Cybersicherheitsbehörde ACN hat am Wochenende eine Warnung vor der Telegram-Lücke veröffentlicht. Darin finden sich nähere Informationen: Eine Zero-Click-Sicherheitslücke in der Android- und Linux-Version des Messengers ermöglicht Angreifern, mittels „animierter Sticker“ verwundbaren Versionen Schadcode unterzuschieben und auszuführen – ohne dass Nutzer oder Nutzerinnen interagieren oder etwas bestätigen müssten. Das Problem beruht auf der automatischen Verarbeitung dieser Mediendateien in Telegram. Angreifer können so die Kontrolle über das betroffene Gerät erlangen und Zugriff auf sensible Daten wie Nachrichten, Kontakte oder aktive Sessions. Die ursprüngliche Risikoeinstufung der Sicherheitslücke durch die ZDI lag daher bei einem CVSS-Wert von 9.8 bei „kritisch“.

Telegram: Lücke existiert nicht

Die ACN hat das Gespräch mit Telegram gesucht und im Laufe des Montags dieser Woche die Sicherheitsmitteilung aktualisiert. Demnach hat Telegram die Existenz der Lücke offiziell dementiert. Jeder auf die Plattform hochgeladene Sticker werde vor der Verteilung an Client-Apps auf den Servern validiert und gescannt. Dieser zentrale Filterprozess verhindere daher die Nutzung von sorgsam präparierten animierten Stickern zum Ausnutzen von Schwachstellen. Es sei technisch unmöglich, Schadcode auf diesem Weg auszuführen.

Inzwischen hat die ZDI den Schweregrad mit der Begründung auf Mastodon von serverseitigen Gegenmaßnahmen seitens Telegram ebenfalls angepasst, mit einem CVSS-Wert von 7.0 erreicht er noch die Risikostufe „hoch“. Die ACN schlägt weiterhin vor, in Telegram den Empfang von Nachrichten von neuen Gesprächspartnern einzuschränken und in den Einstellungen etwa auf das eigene Adressbuch oder Premium-Nutzer zu begrenzen.

Es fehlen Details zu den Telegram-Aussagen, die eine bessere Einordnung ermöglichen. Auf eine Anfrage von heise security hierzu hat Telegram noch nicht reagiert.

Grundsätzlich schließt ein serverseitiger Scan eine derartige Sicherheitslücke nicht, er erschwert höchstens ihre Ausnutzung. Die bisherige Erklärung gegenüber der ACN legt nahe, dass es sich nicht um einen Filter handelt, der alle Sticker verwirft, sondern um eine Art Malware-Scan. Solche Viren-Scans lassen sich oftmals durch Verschleierung oder geschickte Störungen in den Dateien austricksen, etwa wenn die Parser des Scanners mit den vorliegenden Daten nicht mehr zurechtkommen, die Zielsoftware zum Verarbeiten aber schon.

(dmk)