Vor ziemlich genau drei Wochen wurde Debian 13 mit dem Codenamen "trixie" veröffentlicht. Da Debian einen wichtigen Architekturzweig unter Linux bildet, von dem viele Derivate wie z. B. Ubuntu abzweigen, werfen wir heute einen kleinen Blick auf die Veränderungen.

Zahlen, Daten, Fakten

Schaut man in die Veröffentlichungsmeldung, bekommt man einen Überblick, was sich in diesem Release getan hat:

Das Release umfasst nach gut zwei Jahren Entwicklung 69.830 Pakete, wobei 14.100 Zugänge, 8.840 Abgänge und 44.326 Aktualisierungen zu verzeichnen sind. Als Kernel kommt Linux 6.12 LTS zum Einsatz. Gebaut wird mit GCC 14.2 und LLVM 19. Systemd wird in Version 257 genutzt. Bei den Desktopumgebungen sind wir bei GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1.0 und Xfce 4.20 angekommen. Python wird in Version 3.13, Rust in Version 1.85, OpenSSL in Version 3.5 und PHP in Version 8.4 ausgeliefert. Das gesamte Paketarchiv umfasst 403 GB, wovon auf den meisten Systemen nur ein Bruchteil installiert sein sollte.

Zu den Architekturen:

• Die offizielle 32-Bit-Unterstützung (i386) entfällt ab diesem Release. Verbleibende i386-Pakete für Anwendungen sind nur zur Nutzung auf einem 64-Bit-System mit entsprechendem 64-Bit-Kernel vorgesehen, Stichwort multiarch.
• Für ARM-Nutzer alter Architekturen vor Arm v7, die auf die armel (ARM …

Kurz notiert: Die GNU C Library (glibc) wurde in Version 2.42 veröffentlicht. Der Fokus lag besonders auf Mathefunktionen aus neueren C-Standards, der Einführung von SFrame und der Entfernung des alten termio.h-Headers. Hier eine Auswahl neuer Features in aller Kürze:

• Neue Mathefunktionen, darunter:
  • Einige Funktionen aus der neuen ISO C23 werden nun von math.h unterstützt. In dieser Version kommen konkret Funktion für Potenzen und absolute Werte hinzu.
  • unsigned Abstandfunktionen wie uabs() werden unterstützt.
  • Neue Funktionen wie tanpif() wurden aus dem CORE-MATH-Projekt eingeführt.
• Die Unterstützung für die SFrame ist neu. Sofern mit den ebenfalls frisch veröffentlichten Binuntils 2.45 und dem Flag --enable-sframe gebaut wird, kann das neue Stack-Frame-Information-Format genutzt werden.
• Auf Linux gibt es nun die Funktion pthread_gettid_np() zum Anzeigen der Kernel Thread ID für einen Thread, siehe auch Diskussion.
• termios.h unterstützt nun beliebige Baud-Raten.
• Der tcache von malloc() unterstützt nun das Caching großer Blöcke.
• Die S390-Architektur erhält Unterstützung für die z17-Plattform.

Folgende Features werden entfernt oder betreffen die Kompatibilität:

• termio.h, das seit POSIX.1 aus 1988 veraltet galt, wird entfernt. termios.h ist der Ersatz.
• glibc.rtld.execstack unterstützt nun einen Kompatibilitätsmodus, mit dem Programme einen ausführbaren Stack mittels dynamisch geladener Bibliotheken anfordern können.
• Unterstützung für die TX Lock Elision von pthread …

Kurz notiert: Let's Encrypt hat Anfang des Monats am 4. Juni 2025 den Dienst für die E-Mail-Benachrichtigungen abgeschaltet. Zertifikatsinhaber werden fortan nicht mehr per E-Mail auf ein Auslaufen der Zertifikate hingewiesen. Diese Änderung wurde bereits im Januar angekündigt.

Begründet wird die Entscheidung durch die Kosten für den E-Mail-Versand, die Speicherung der E-Mail-Adressen sowie die Komplexität der Infrastruktur. In der Tat ist der Versand der Benachrichtigungen in einer Größenordnung wie bei Let's Encrypt sehr kostenintensiv, zumal dies über externe Dienstleister abgewickelt werden muss.

Die Speicherung der E-Mail-Adressen ist ein interessanter Punkt, weil insbesondere bei certbot die Adressen standardmäßig immer abgefragt wurden, während man die Angabe bei acme.sh schon länger vermeiden konnte. Dies soll, so mein Verständnis, nun der Standard werden, da Let's Encrypt nicht mehr die E-Mail-Adressen der Zertifikatsinhaber speichern möchte. Für andere Zwecke wurden die E-Mail-Adressen offenbar auch nicht gespeichert, da z. B. das Zurückziehen eines Zertifikates (Revocation) über andere Wege wie den Private Key oder DNS-Verifikation läuft, wie in der Dokumentation beschrieben wird.

Bleibt noch ein letzter Punkt, der im Blogartikel zur Abschaltung angeführt wird: Ein integraler Bestandteil von Let's Encrypt ist Automatisierung. Schon von Anfang an wurden automatisierte Verfahren wie ACME statt einer manuellen Verifikation eingesetzt, …

Zum Ende des Monats wollte ich euch noch im Blog von der aktuellen Risikozone-Episode 74 „SIP Happens: No Contact, No Service“ berichten, in der wir uns endlich mal dem Session Initiation Protocol (SIP) widmen konnten. Unsere Gäste von sipgate arbeiten im Infrastrukturteam und sind damit die richtigen Ansprechpartner.

SIP war insbesondere in den 2000ern ein Ding, als VoIP aufkam und ist dann in meinen Augen immer mehr in den Hintergrund verschwunden. Unter der Haube wird die Rolle von SIP in den nächsten Jahren jedoch immer wichtiger, da SIP die technische Grundlage für Anrufe im Mobilfunk darstellt. Anrufe werden spätestens ab der in 2028 beginnenden GSM-Abschaltung in Deutschland entweder per Mobilfunk über VoLTE oder per WLAN über VoWiFi abgewickelt. Intern kommen dabei immer IPsec und SIP zum Einsatz.

Festnetztelefonie ist seit der All-IP-Umstellung um 2018 herum auch weitestgehend SIP-only. Nur stellt sich hier die Frage, wie lange uns klassische Telefone erhalten bleiben, bis alles in Teams & Co. migriert wird. SIP ist somit so ein wenig die Schnittstelle zwischen der Internetwelt mit der Best-Effort-Mentailität und der klassischen Nachrichtentechnik, wo es auf Qualität der Kanäle ankommt.

Als Bonus berichten wir über eine Lücke in der Firmware einiger Smartphones, die auf MediaTek-Prozessoren setzen. …

Kurz notiert: das Team von Oligo Security berichtet von einer Reihe an Schwachstellen, die sie im AirPlay Protokoll und AirPlay SDK gefunden und "AirBorne" getauft haben. Insgesamt 23 Schwachstellen, die zu 17 CVEs geführt haben, wurden zutage gefördert.

Einer der schwerwiegendsten Lücken umfasst eine Zero-Click RCE, sodass ein erfolgreicher Exploit ohne Interaktion mit dem Nutzer beliebigen Code ausführen kann. Die Lücken wurden spätestens mit iOS 18.4 sowie den aktuellen Versionen der unterstützten macOS-Releases (15.4, 14.7.5, 13.7.5) gefixt.

Wer sich für die Apple-Wireless-Protokolle interessiert, kann gerne auch die Risikozone-Podcastepisoden 60 und 61 hören, wo wir mit Alexander Heinrich über die Findings im AWDL- und AirDrop-Protokoll gesprochen haben.

Kurz notiert, weil ich es ganz spannend finde: Wer kann am besten die Anti-Spam-Mechanismen wie DMARC, SPF und DKIM erfüllen? Genau, Spammer. Damit ist – auch im Lichte der unterschiedlichen Anstrengungen der großen Provider zur Durchsetzung der Einträge – die Spamerkennung anhand Überprüfung der Authentizität des Absenders hinfällig.

Hintergrund ist, dass das E-Mail-System eigentlich wie ein System von Briefkästen aufgebaut ist. Jemand schreibt eine E-Mail und wirft sie in einem „Briefkasten“, der das SMTP spricht, ein. Anschließend findet die E-Mail den Weg zum Ziel, wo sie entweder abgeholt (POP3) oder zwischengespeichert (IMAP) wird. In diesem gesamten Konzept ist der Absender eher informativ und allen Beteiligten ist eigentlich klar, dass dieser gefälscht werden kann.

Offene Briefkästen, in die alle etwas einwerfen können, werden auch als Open Relay bezeichnet und sind heutzutage verpönt. Die wenigsten E-Mail-Server nehmen E-Mails von Open Relays an, weil sie – zu Recht – als Spamschleudern gelten.

DMARC, SPF und DKIM sind aber nicht als Spamschutz gedacht, sondern als Mechanismus, um die Legitimität von Absendern zu beweisen. Es hindert Spammer nicht daran, eigene Domains aufzusetzen, von denen sie legitim E-Mails versenden können. Es hindert nur Spammer, die Spam im Namen eines Anderen versenden.

Die Wirksamkeit ist im Übrigen …

Mozilla hat gestern eine Ankündigung für den Firefox gemacht: Sie führen dort Nutzungsbedingungen ein. Ein Open-Source-Browser, der bislang ganz gut ohne damit auskam, setzt jetzt auf das, was sonst eher in den AGB-Friedhöfen großer Plattformen vor sich hin verstaubt. Grundsätzlich lässt sich das noch mit einem wohlwollenden Achselzucken abtun: Natürlich braucht Mozilla sicherlich eine rechtliche Grundlage für all die interaktiven Dienste, die der moderne Browser so mit sich bringt. Soweit, so juristisch.

Aber das Timing? Es hätte suboptimaler nicht sein können. Fast zeitlich wurden nämlich jene Passagen von der Webseite entfernt, die bisher versprachen, die Nutzerdaten nicht zu verkaufen. Von der Community gab es daraufhin überwiegende kritische Reaktionen wie hier, hier, hier oder hier. Auch einer der zwischenzeitlich ausgeschiednenen Gründer von Mozilla sieht das Verhalten skeptisch.

Besonders kritisch wird dieser Absatz hervorgehoben:

When you upload or input information through Firefox, you hereby grant us a nonexclusive, royalty-free, worldwide license to use that information to help you navigate, experience, and interact with online content as you indicate with your use of Firefox.

Es stellt sich die Frage, warum ein Webbrowser überhaupt Nutzungsbedingungen braucht, wenn man als Nutzer doch schon den bestehenden Lizenzbedingungen zustimmen muss. In der …

Mobilfunk ist eine unverzichtbare Technologie unseres Alltags – und gleichzeitig ein faszinierendes Beispiel für moderne Funksysteme. Während wir bei WLAN als Endnutzer oft sowohl das Endgerät als auch die Basisstation, den sogenannten Access Point, betreiben, ist der Mobilfunk weitaus komplexer und auch fachlich schwieriger zugänglich. Die Mobilfunknetze werden von großen Telekommunikationsunternehmen im lizenzierten Spektrum betrieben, und selbst auf unseren Telefonen bleibt die Interaktion mit dem Mobilfunknetz minimal. Meist reicht es, die SIM-Karte einzulegen, und schon funktioniert alles. Was viele nicht wissen: Auch Betriebssysteme wie Android oder iOS kommunizieren nicht direkt mit dem Mobilfunknetz. Diese Aufgabe übernimmt ein spezieller Chip, der sogenannte Baseband-Prozessor.

Open Source und Mobilfunk: Das Osmocom-Projekt

In der Open-Source-Welt gibt es nur wenige Projekte, die diese Funktechnologie zugänglich machen. Eines herausragendes Beispiel ist das Osmocom-Projekt. Schon ein erster Blick auf die Übersicht zeigt, dass es nicht "die eine" Mobilfunksoftware gibt. Vielmehr müssen viele verschiedene Komponenten ineinandergreifen und wie in einem Orchester zusammenspielen, um ein funktionierendes Netz bereitzustellen.

Sicherheitsforschung im Mobilfunk

Der Blick auf die Sicherheit sollte im Mobilfunk nicht vernachlässigt werden. So mag es überraschen, dass ältere GSM-Mobiltelefone deutlich unsicherer sind, als moderne Geräte, die auf LTE und 5G basieren. Hintergrund sind die verbesserten kryptographischen Verfahren. …

Das Jahr 2024 geht zu Ende und ich möchte die Gelegenheit nutzen, mich herzlich bei allen Lesern zu bedanken, die in diesem Jahr meinen Blog verfolgt, meine Artikel gelesen oder ihn durch Kommentare und Zuschriften bereichert haben.

Zu Beginn des Jahres bin ich zum Institut für sichere mobile Kommunikation (ISMK) gewechselt und habe den Podcast Risikozone mitgenommen, sodass ich die Episoden nun im Rahmen meiner Tätigkeit dort produziere. Viele IT-Sicherheitsthemen, die ich im Blog veröffentlicht hätte, fließen nun zwei Mal im Monat in die Episoden dort ein. Über das vergangene Jahr des Podcasts haben wir in Episode 63 gesprochen.

Mein Blog begleitet mich nun schon seit 2016. Im neunten Jahr seines Bestehens habe ich mit 14 Artikeln den Schnitt der vergangenen Jahre gehalten. Wie gewohnt möchte ich zum Jahresende auf einige Highlights und bedeutende Themen des vergangenen Jahres im Blog zurückblicken.

Rückblick auf 2024

Eines der herausragendsten Ereignisse in der IT-Sicherheits- und Open-Source-Welt war zweifellos die xz-Lücke. Über diese Backdoor habe ich sowohl hier im Blog als auch in den Risikozone-Episoden 45 und 46 berichtet.

Ein weiteres bemerkenswertes Sicherheitsproblem war die OpenSSH-Sicherheitslücke RegreSSHion. Zudem wurden in der glibc zwei Lücken entdeckt, deren besondere Bedeutung in ihrem Alter lag: Die …