Ist das up2date?

Warum man sich nicht Versionsnummern in HTTP-Antwort-Headern verwenden kann, um fehlende Sicherheitsupdates zu identifizieren

Dies ist eine übersetzte Version. Das englische Original finden Sie hier.

In den letzten Wochen musste ich mehrfach erklären, warum man sich nicht auf Versionsnummern in HTTP-Headern verlassen kann, um den Patch-Level eines Systems zu bestimmen. Ich ging davon aus, dass dies allgemein bekannt ist – aber jeden Tag wird jemand geboren, der noch nie „die Feuersteins“ gesehen hat.

Dieser Beitrag verwendet Ubuntu als Beispiel, aber das Prinzip gilt für alle Linux-Distributionen, die Long Term Support (LTS)-Versionen anbieten. Der Fokus liegt hier auf dem Patchen; auf weitere Faktoren, die darüber entscheiden können, ob ein System verwundbar ist (zum Beispel eine bestimmte Konfiguration), wird nicht eingegangen.

Das Problem

Nehmen wir an, wir führen einen Penetrationstest durch. Beim Mapping der externen Angriffsfläche stößt du auf einen Webserver, auf dem ein typischer LAMP-Stack (Linux, Apache, MySQL, PHP) läuft. Du überprüfst den Server-Header in der HTTP-Antwort und kannst aufgrund der Standardeinstellungen leicht die verwendeten Apache- und PHP-Versionen identifizieren. Hinweis: Die Ausgabe der PHP-Version wurde für dieses Beispiel bewusst aktiviert.

1curl -I http://lamphost/
2HTTP/1.1 200 OK
3Date: Thu, 11 Sep 2025 20:17:23 GMT
4Server: Apache/2.4.52 (Ubuntu)
5X-Powered-By: PHP/8.1.2-1ubuntu2.22
6Content-Type: text/html; charset=UTF-8

Jetzt überprüfen wir die Liste bekannter Schwachstellen des Apache HTTP Servers 2.4 – und das sieht nicht gut aus. Die Version 2.4.52 wurde 2021 veröffentlicht, daher scheint es wahrscheinlich, dass das System von mehreren Schwachstellen betroffen ist, die Orange Tsai im Jahr 2024 veröffentlichte, darunter einige, die von den Apache-Entwicklern als “important” eingestuft wurden.

Bei PHP sieht die Situation ähnlich aus. Laut dem PHP ChangeLog wurde die verwendete Version am 20. Januar 2022 veröffentlicht, was darauf schließen lässt, dass mehrere kritische Sicherheitsupdates fehlen. Richtig?

Natürlich ist es nicht ganz so einfach 😉.

Um zu verstehen warum muss man sich ansehen, wie Linux-Distributionen Software paketieren und Sicherheitsupdates bereitstellen.

Semantische Versionierung und Distributions-Forks

Die meisten Open-Source-Projekte, darunter Apache und PHP, verwenden Semantic Versioning (SemVer), das sich wie folgt zusammenfassen lässt:

Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Beispielsweise bedeutet der Wechsel von Version 2.4.52 zu 2.4.57, dass fünf Versionen veröffentlicht wurden (wahrscheinlich einschließlich Sicherheitspatches), aber die Gesamtfunktionalität und die API kompatibel bleiben.

Auf dieser Basis gehen viele Sicherheitsanalysten (und einige Schwachstellenscanner) davon aus, dass ein System veraltet ist, wenn die PATCH-Versionsnummer nicht mit der neuesten Upstream-Version übereinstimmt. Die Logik ist einfach: Wenn das System vollständig gepatcht wäre, müsste sich das in der Versionsnummer widerspiegeln.

Diese Annahme ist jedoch in der Regel falsch.

In der Praxis kompilieren und installieren die meisten Menschen Software wie Apache oder PHP nicht selbst, sondern verlassen sich stattdessen auf Pakete, die von ihrer Linux-Distribution bereitgestellt werden.

Wenn eine Linux-Distribution ein Paket für ihr Repository erstellt, wird das Upstream-Projekt effektiv geforkt. Dieser Prozess beinhaltet oft Änderungen am Quellcode, um die Kompatibilität mit den unterstützten Architekturen und die ordnungsgemäße Integration mit anderen Systemkomponenten (beispielsweise systemd) sicherzustellen.

Das Ubuntu-Projekt unterhält ein eigenes Versionskontrollsystem und einen Bug-Tracker, die von den Upstream-Projekten getrennt sind. Zum Beispiel hat Apache httpd einen eigenen Bereich im Bug-Tracker von Ubuntu, in dem bekannte Probleme gelistet sind, welche die von Ubuntu gepflegte Version betreffen.

Gemäß Semantic Versioning könnte eine Distribution Metadaten an die Versionsnummer anhängen (z. B. 2.4.52+ubuntu1), um eigene Patches zu kennzeichnen, dies ist jedoch nicht zwingend erforderlich. Manchmal gibt es Gründe, diese Informationen nicht anzugeben.

Beispielsweise erlaubt Apache httpd über die Direktive ServerTokens die Konfiguration der Informationen, die im „server” Feld einer HTTP-Antwort ausgegeben werden. Je nach Einstellung kann dieser Header Informationen über das verwendete Betriebssystem enthalten. Wenn Ubuntu der Version ein „PATCH”-Label hinzufügen würde, könnte das System das verwendete Betriebssystem unabhängig von der ServerTokens-Einstellung preisgeben.

Long Term Support (LTS) Releases

Systemadministratoren legen Wert auf Stabilität, weshalb sie in der Regel Long Term Support (LTS)-Versionen einer Linux-Distribution verwenden. LTS-Versionen erlauben es ihnen, Systeme über längere Zeiträume ohne größere Upgrades zu pflegen.

Um die Ubuntu Release Cycle Website zu zitieren:

LTS or ‘Long Term Support’ releases are published every two years in April. LTS releases are the ‘enterprise grade’ releases of Ubuntu and are used the most. An estimated 95% of all Ubuntu installations are LTS releases.

Auf derselben Seite finden Sie auch Details zum Wartungsfenster für LTS-Versionen:

Ubuntu LTS releases receive 5 years of standard security maintenance for all packages in the ‘Main’ repository. With an Ubuntu Pro subscription, you get access to Expanded Security Maintenance (ESM) covering security fixes for packages in both the ‘Main’ and ‘Universe’ repositories for 10 years.
…
Add on optional Legacy Support to Ubuntu Pro and expand security maintenance and support for an additional 2 years, resulting in 12 years of coverage overall.

Zehn Jahre sind ein langer Supportzeitraum (daher der Name LTS), insbesondere wenn dies Software mit kürzeren Supportzyklen umfasst.

Nehmen wir als Beispiel PHP: Das PHP-Entwicklungsteam stellt für eine bestimmte Version etwa vier Jahre lang Sicherheitsupdates bereit. Danach erreicht die Version das Ende ihrer Lebensdauer (End of Life, EoL) und erhält keine Patches oder Sicherheitsupdates mehr.

In unserem Beispiel verwendet der Webserver PHP 8.1, für das der offizielle Sicherheitssupport am 31. Dezember 2025 endet. Ubuntu (Jammy Jellfish) stellt jedoch bis April 2027 kostenlose Sicherheitsupdates zur Verfügung. Wenn man ein Ubuntu Pro-Abonnement abgeschlossen hat, erhält man bis April 2032 Updates.

Dies wirft eine wichtige Frage auf: Wie kann Ubuntu Sicherheitsupdates für PHP bereitstellen, wenn diese Updates nicht von den PHP-Entwicklern veröffentlicht werden?

Backporting von Sicherheitsupdates

Wenn eine neue Haupt-/Nebenversion einer Software veröffentlicht wird, handelt es sich in der Regel nicht um eine umfassende Neuentwicklung. Stattdessen teilt die neue Version einen Großteil des Codes mit der vorherigen Version. Daher ist die Wahrscheinlichkeit hoch, dass Schwachstellen, die in der aktuell unterstützten Version entdeckt werden, auch in nicht länger unterstützten Versionen vorhanden sind. Daher muss der Paketverwalter für die Linux-Distribution Sicherheitsupdates auf die Forks „zurückportieren”, für die er Support anbietet. Dies umfasst:

  1. Identifizieren des anfälligen/gepatchten Codes
  2. Überprüfen, ob der anfällige Code auch in der von der Distribution verwendeten Version vorhanden ist
  3. Migrieren des eigentlichen Patches
  4. Testen

Je nach Schwachstelle und geänderter Codebasis kann dies eine einfache oder recht komplexe Aufgabe sein. Backporting ist nicht auf Linux-Distributionen beschränkt. Spezialisierte Unternehmen wie herodevs bieten ebenfalls erweiterte Wartungsfenster an, indem sie Sicherheitsupdates auf End-of-Life-Versionen zurückportieren.

Dank Backporting können Sie auch dann noch über eine „gewartete” Softwareversion verfügen, wenn die ursprünglichen Entwickler keine Updates mehr bereitstellen.

Welches Paket ist installiert?

Wenn man also herausfinden möchte, ob man es mit einem potenziell verwundbaren System zu tun hat, muss man das verwendete Paket identifizieren. Am einfachsten ist es, das System direkt zu fragen, beispielsweise per apt-cache. Eine hervorragende Beschreibung des Ubuntu-Paketnamensschemas findet sich hier.

1apt-cache policy apache2
2apache2:
3  Installed: 2.4.52-1ubuntu4.16
4  Candidate: 2.4.52-1ubuntu4.16
5...

Es ist auch möglich, eine Liste aller installierten Pakete mit dpkg abrufen:

1dpkg -l

Mit diesen Informationen können wir nun zu Launchpad gehen und das Änderungsprotokoll dieses Pakets auf behobene CVEs überprüfen.

Natürlich kann man diese Informationen nur in einem White-Box-Test erhalten. Wenn man danach fragt, würde ich auch empfehlen, die Apache-/PHP-Konfiguration zu holen.

In einigen Fällen ist die Paketversion tatsächlich in der Versionsausgabe enthalten. Beispielsweise enthält der HTTP-Antwortheader „X-Powered-By“ von PHP die installierte Paketversion. Sie ist auch in der Ausgabe der Funktion phpinfo() enthalten.

X-Powered-By: PHP/8.1.2-1ubuntu2.22

Ubuntus Fork von OpenSSH gibt die verwendete Packetversion ebenfalls im SSH-Banner zurück:

 1nmap xxx.xxx.xxx.xxx -sV -p 22 
 2Starting Nmap 7.95 ( https://nmap.org ) at 2025-09-16 01:47 EDT
 3Nmap scan report for xxx.xxx.xxx.xxx
 4Host is up (0.0031s latency).
 5
 6PORT   STATE SERVICE VERSION
 722/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.13 (Ubuntu Linux; protocol 2.0)
 8Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
 9
10Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
11Nmap done: 1 IP address (1 host up) scanned in 0.46 seconds

Schwachstellenscanner

In der Vergangenheit war ein Großteil der Probleme Schwachstellenscanner verursacht, die sich ausschließlich auf Versionsnummern in HTTP-Headern verließen. Dies führte häufig zu False Positives, die unnötigen Aufwand für Sicherheitsteams verursachten.

Glücklicherweise hat sich die Situation verbessert. Tools wie Tenable Nessus bieten nun einen klareren Kontext, indem sie auf die Möglichkeit von Backport-Sicherheitspatches in Software wie Apache httpd und PHP hinweisen.

Vielen Dank an Diana Polekhina bei Unsplash für das Titelbild.