Diese Woche kamen die Meldungen über zwei Sicherheitsmeldungen kurz nacheinander. Debian hat eine PHP-Lücke mit DSA-6574-1 geschlossen.Das hat mich nicht getroffen, da ich im Ausenbereich kein php verwende. Das Node.js-Projekt hat am 21. Oktober 2026 Security Releases für die Linien 22, 24 und 26 veröffentlicht, darunter einen Fehler im Brotli-Decoder, der laut Advisory Remote Code Execution erlaubt.
Um die Lücken selbst geht es hier nicht. Es geht darum, was beim Einspielen passiert und woran Sie merken, dass der Patch wirkt.
Was ich bei mir gemessen habe#
Eigenmessung auf einem System, Erhebung vom 21. bis 23. Oktober 2026.
Ein Update-Lauf kann grün sein, ohne zu patchen. Zwei meiner Ansible-Rollen installieren Node mit state: present. Läuft die Rolle erneut, meldet sie changed=0, auch wenn das Repository längst eine gepatchte Version anbietet. Der Lauf bestätigt das Soll “Paket vorhanden”, nicht den Sicherheitsstand.
Das Paket ist neu, der Prozess ist alt. Nach dem Einspielen des Updates hielten auf einem Entwicklungsrechner 11 laufende Prozesse noch das alte Binary. Nach dem Neustart der Dienste waren es 3, alle in einem Editor, der noch offen war. Ohne gezielte Suche hätte kein Bericht diese Prozesse gezeigt.
Bestandsliste und die Wirklichkeit wichen ab. Zwei Inventar-Einträge waren dieselbe Maschine, und eine Konfigurationsdatei nannte eine Node-Version, die auf dem Host nicht lief. Die Debian-Lücke habe ich außerdem nur gefunden, weil ich nachgefragt habe, nicht weil ein Prozess sie gemeldet hat.
Die Ursache#
Der Sollwert sitzt am falschen Ort. “Paket in Version X installiert” ist leicht zu messen und wird deshalb gemessen. Verwundbar ist aber der laufende Prozess. Zwischen beiden liegt ein Neustart, und für den war bei mir niemand zuständig.
Die Prüfung der Ursache#
Wenn die Ursache ist, dass der Patchstand am Paket statt am laufenden Prozess gemessen wird, dann beseitigt ein Update-Lauf mit anschließendem Dienstneustart und Prüfung auf gelöschte Binaries das Symptom “als gepatcht gemeldet, noch verwundbar”. Messbar ist das am Anteil der Prozesse auf gelöschtem Binary, Soll 0, innerhalb der Zeit T nach dem Lauf. T legen Sie vor dem Lauf fest.
So sieht die Prüfung aus, als root ausgeführt:
for p in /proc/[0-9]*; do
exe=$(readlink "$p/exe" 2>/dev/null) || continue
case "$exe" in
*"(deleted)") echo "${p#/proc/} $exe" ;;
esac
doneJeder Treffer ist ein Prozess, dessen Programmdatei durch ein Update ersetzt wurde und der noch mit der alten läuft.
Messgrößen, Baseline, Abbruch#
Zwei Größen können Sie selbst erheben und gegen Ihren bisherigen Stand vergleichen:
- Anteil der Prozesse auf gelöschtem Binary nach dem Update-Lauf. Soll: 0.
- Zeit vom Release bis zum letzten gepatchten laufenden Prozess. Die Baseline rekonstruieren Sie aus dem letzten Release oder erheben sie ab jetzt.
Abbruchkriterium: Bleibt der Anteil nach dem Neustart aller zuständigen Dienste über 0, ist das Gefälle zwischen Paket und Prozess nicht die ganze Ursache. Dann kommen Container, eigene Mount-Namespaces oder nicht verwaltete Installationen in Frage, und es geht zurück in die Diagnose.(Container sind bei mir nicht vorhanden - alles native Bare Metal)
Wer es umsetzt#
Wer den Patchprozess verantwortet, in kleineren Betrieben meist Geschäftsführung oder IT-Leitung. Dort fallen zwei Entscheidungen: Wer startet nach einem Update die Dienste neu, und gilt ein Host erst dann als gepatcht, wenn die Prozesssuche leer ist?
Der Preis des Unterlassens: Der Host steht im Bericht auf “gepatcht”, die Lücke ist offen, und niemand sieht es. Eine Zahl dazu nenne ich nicht, weil ich außerhalb meines eigenen Systems nichts gemessen habe.
Grenzen#
Die Prüfung findet ersetzte Programmdateien. Wurde nur eine Bibliothek ersetzt, die ein Dienst dynamisch lädt, bleibt sie leer. Dafür braucht es zusätzlich needrestart oder eine Prüfung der geladenen Bibliotheken. Bei Node ist OpenSSL im Binary enthalten, deshalb reicht die Prüfung dort.
Quellen: