OpenSSL-Update auf Ubuntu: ein langes Changelog, keine neue Heartbleed-Geschichte

Wer in diesen Tagen auf Ubuntu 24.04 LTS ein Systemupdate einspielt, bekommt mit openssl 3.0.13-0ubuntu3.12 ein Sicherheitsupdate serviert, dessen Changelog spürbar länger ausfällt als sonst. Ein Blick auf die letzten Versionssprünge der 3.0.13-Reihe und auf den aktuellen Streit um die sogenannte HollowByte-Schwachstelle zeigt, was dahintersteckt und warum lange Changelogs nicht automatisch Alarmstufe Rot bedeuten.

Was in der 3.0.13-Reihe zuletzt gepatcht wurde

Ubuntu pflegt OpenSSL 3.0.13 nicht durch große Versionssprünge, sondern durch fortlaufend nummerierte Sicherheits-Patches auf derselben Basis. Die letzten öffentlich dokumentierten Updates dieser Reihe zeigen ein wiederkehrendes Muster aus zwei Fehlerklassen:

Heap-Buffer-Probleme: Speicherfehler, bei denen ein Programm über die Grenzen eines reservierten Speicherbereichs hinausliest oder -schreibt. Version 3.0.13-0ubuntu3.11 (veröffentlicht am 9. Juni 2026) behob etwa CVE-2026-34180, einen Heap-Buffer-Over-read beim Parsen von ASN.1-Daten, sowie CVE-2026-7383, einen möglichen Heap-Buffer-Overflow bei der ASN.1-Multibyte-String-Konvertierung.

Fehler bei CMS-, PKCS#7- und ASN.1-Verarbeitung: Dieselbe Version korrigierte CVE-2026-34182 (CMS AuthEnvelopedData-Nachrichten konnten unter bestimmten Bedingungen gefälscht werden), CVE-2026-42766 und CVE-2026-42767 (NULL-Pointer-Dereferenzierungen bei passwortbasierter CMS- bzw. CRMF-Entschlüsselung), CVE-2026-45447 (Use-after-free in PKCS7_verify()) sowie weitere Fixes rund um AES-OCB und AES-SIV.

Diese Fehlerklassen betreffen typischerweise Anwendungen und Server, die kryptografisch codierte Daten von Dritten entgegennehmen und verarbeiten, etwa Mailserver, die signierte oder verschlüsselte S/MIME-Nachrichten prüfen, oder Dienste, die Zertifikate und PKCS#12-Dateien verarbeiten. Für einen normalen Desktop-Arbeitsplatz ist das Risiko entsprechend gering.

Hinweis zur Quellenlage: Zum Zeitpunkt der Recherche war das Changelog für die konkrete Version 3.0.13-0ubuntu3.12 in den öffentlichen Ubuntu-Paketindizes noch nicht veröffentlicht (das Paket war erst am selben Tag erschienen). Die oben beschriebenen Fixes stammen aus der dokumentierten Vorgängerversion 3.0.13-0ubuntu3.11 und stehen exemplarisch für das Muster, dem die Reihe seit Monaten folgt. Für die exakte Liste der in .12 enthaltenen CVEs empfiehlt sich ein Blick in apt changelog openssl auf dem eigenen System oder in die offizielle Ubuntu Security Notice, sobald sie veröffentlicht ist.

Die HollowByte-Geschichte

Die zweite, medial deutlich lautere Geschichte der letzten Wochen heißt HollowByte. Das Okta Red Team veröffentlichte Mitte Juli 2026 einen Bericht über eine Denial-of-Service-Schwäche in OpenSSLs TLS-Handshake: Ältere OpenSSL-Versionen lasen zunächst nur den vierbytigen Header einer Handshake-Nachricht (ein Byte Nachrichtentyp, drei Byte Länge) und reservierten daraufhin sofort Speicher in der angegebenen Größe, noch bevor der eigentliche Nachrichteninhalt eintraf. Ein Angreifer konnte mit einem elf Byte großen Datensatz eine Nachricht von rund 128 KB ankündigen und den Server so dazu bringen, entsprechend viel Speicher zu reservieren, ohne die Nachricht je zu senden.

OpenSSL hat den Bericht in einem eigenen Blogbeitrag vom 21. Juli 2026 eingeordnet und dabei zwei Dinge auseinandergezogen, die der ursprüngliche Bericht zusammen betrachtet hatte:

Die Speicherreservierung selbst war real, aber begrenzt und pro Verbindung gedeckelt, weil OpenSSL eine maximale Handshake-Nachrichtengröße von rund 128 KiB erzwingt. Eine einzelne Verbindung konnte also nie beliebig viel Speicher binden.

Die eigentlichen Server-Ausfälle, die der Bericht beschreibt, entstehen laut OpenSSL nicht durch die Größe der Reservierung, sondern durch das klassische Slowloris-Muster: Verbindungen, die einen TLS-Handshake beginnen und dann verstummen, während der Server ohne Timeout auf weitere Daten wartet und dabei einen Worker-Prozess blockiert. Das ist ein seit Langem bekanntes Problem der Verbindungsverwaltung, unabhängig von der angekündigten Nachrichtengröße.

Auf dieser Grundlage hat OpenSSL bewusst keine CVE-Nummer für HollowByte vergeben und die Änderung als Hardening-Fix statt als Sicherheitslücke eingestuft. Begründung: Der Speicherverbrauch wächst nicht unbegrenzt, plateaut in eigenen Tests auf einem wiederverwendeten Höchststand, und das eigentliche Risiko liegt in unzureichend konfigurierten Verbindungs-Timeouts, also außerhalb der Bibliothek selbst. Zum Vergleich verweist OpenSSL auf CVE-2026-34183, eine QUIC-PATH_CHALLENGE-Schwachstelle aus demselben Zeitraum, die sehr wohl eine CVE erhielt, weil sie unbegrenzt wächst und ausschließlich durch einen Bibliotheks-Fix behoben werden konnte.

Trotz der Nicht-Einstufung als Schwachstelle hat OpenSSL die Pufferreservierung geändert: Der Handshake-Puffer wird jetzt inkrementell in Schritten von maximal einem TLS-Record (16 KB) aufgebaut, statt der angekündigten Gesamtlänge sofort zu vertrauen. Die Änderung ist in den Releases 4.0.1, 3.6.3, 3.5.7, 3.4.6 und 3.0.21 enthalten. Weil die ursprüngliche Einstufung als reiner Bugfix ohne Sicherheitshinweis in der Berichterstattung kritisiert wurde, hat OpenSSL nachträglich einen CHANGES.md-Eintrag ergänzt, der die Änderung und die betroffenen Releases dokumentiert.

Praktische Einordnung

Für Ubuntu-Systeme, auf denen OpenSSL läuft, bleibt die Empfehlung unverändert einfach: Sicherheitsupdates zeitnah einspielen, unabhängig davon, ob im Einzelfall eine CVE-Nummer vergeben wurde oder nicht. Für Serverbetreiber, die TLS-Verbindungen von außen annehmen, ist der zweite Teil von OpenSSLs eigener Empfehlung mindestens genauso wichtig wie das Update selbst: Handshake- und Idle-Timeouts setzen, die Zahl gleichzeitiger Verbindungen pro Quelle begrenzen und nicht-blockierendes I/O verwenden, damit eine einzelne verzögerte Gegenstelle keinen Worker-Prozess dauerhaft belegen kann. Diese Absicherung betrifft jeden internetzugänglichen Dienst und ist nicht spezifisch für OpenSSL.

Fazit

Ein langes Changelog ist selten ein Grund zur Sorge, meistens ist es das Gegenteil: ein Beleg dafür, dass ein Projekt seine bekannten Schwachstellen konsequent abarbeitet. Die HollowByte-Debatte zeigt zusätzlich, wie unterschiedlich Sicherheitsteams und externe Forscher dieselbe Beobachtung einordnen können, und dass eine fehlende CVE-Nummer nicht automatisch bedeutet, dass ein Thema irrelevant ist. Für den laufenden Betrieb zählt am Ende beides: die Bibliothek aktuell halten und die eigene Serverkonfiguration nicht vergessen.

Quellen

• OpenSSL Library: On the “HollowByte” denial-of-service report
• The Hacker News: OpenSSL HollowByte Flaw Could Freeze Server Memory with 11-Byte TLS Requests
• Okta Red Team: OpenSSL HollowByte – A DoS Hiding in 11 Bytes
• UbuntuUpdates.org: Changelog-Historie des Pakets openssl (noble)
• Ubuntu Security Notices – Übersicht openssl