GHOST-Glibc-Sicherheitsanfälligkeit (CVE-2015-0235): Ist ein Neustart eines Servers nach einem Glibc-Upgrade erforderlich?

3822
Michael

Ich möchte glibc gemäß RedHat aktualisieren: https://rhn.redhat.com/errata/RHSA-2015-0090.html

Ist ein Neustart des Servers nach dem glibc-Upgrade erforderlich?

13

3 Antworten auf die Frage

23
gowenfawr

Ein Neustart ist technisch nicht erforderlich, da nur Programme, die glibc verwenden, neu gestartet werden müssen und der Kernel keine glibc verwendet.

Der Neustart von allem, was glibc verwendet, ist jedoch so breit, dass Sie möglicherweise auch nur einen Neustart durchführen .

Zum Beispiel /sbin/initverwendet glibc. Ein Neustart ist jedoch trivial ( init uals root ausgeführt).

OTOH Ich bezweifle ernsthaft, dass "init" aufgrund der CVE anfällig ist :) Erbureth vor 9 Jahren 3
@Erbureth, ich stimme zu, aber ich denke "Ich denke, _dieses Programm_ ist anfällig, ich denke, _Das Programm_ ist nicht" ist "ein seltsames Spiel. Der einzige Gewinnzug ist nicht zu spielen." gowenfawr vor 9 Jahren 11
sysvinit ist sicher (keine DNS-Anrufe und oft auch nicht immer statisch verlinkt). "systemd" scheint einen eigenen Resolver zu haben. Nach meiner Erfahrung kann das Ersetzen von Bibliotheken, die von lang laufenden Prozessen verwendet werden, Instabilitäten verursachen. Starten Sie neu und seien Sie glücklich. mr.spuratic vor 9 Jahren 0
sysvinit kann neu gestartet werden. Setzen Sie den Befehl init u ab und es wird / sbin / init ausgeführt. Joshua vor 9 Jahren 2
FYI: [Neustart von init ohne Neustart des Systems] (http://unix.stackexchange.com/questions/181782/restarting-init-without-restarting-the-system) Gilles vor 9 Jahren 0
@gowenfawr Jemand hat gestern gefragt, wie er das Spiel spielen soll: http://superuser.com/questions/870805/determine-vulnerable-programs-affected-by-glibcs-ghost-bug Barmar vor 9 Jahren 0
@Barmar setzt die Filmzitate fort: "Sehen Sie, das Traurige an einem Kerl wie diesem ist, dass er in 50 Jahren noch einige Gedanken auf eigene Faust machen wird und er wird auf die Tatsache kommen müssen, dass es zwei bestimmte Personen im Leben gibt. tu das nicht. Und zweitens, er verschwendete viel Zeit und Energie damit, nach jemandem Ausschau zu halten, der ihm Antworten gab und ihm ausgefallene Shell-Skripte gab, um ihm etwas zu versichern, das er umsonst bekommen würde, wenn er es nur werfen würde ein Neustart." gowenfawr vor 9 Jahren 0
9
deed02392

Wenn Sie mit dem manuellen Neustart einzelner Dienste, die die verwundbare Bibliothek verwenden, zufrieden sind, können Sie diesen Befehl ausführen und die aufgelisteten Prozesse erneut starten:

# lsof | awk '/libc-/ ' | sort -u 

Sie werden wahrscheinlich feststellen, dass es einfacher ist, die Maschine vollständig neu zu starten.

"lsof | awk '/DEL.*libc/' | sortiere -u`, um nur diejenigen zu finden, die mit der jetzt gelöschten (nach dem Update) libc verknüpft sind. sch vor 9 Jahren 9
Hat jemand die Ausgabe von `lsof | tatsächlich überprüft? grep libc`? Es passt zu einer Menge von Bibliotheken, einschließlich libcurl, libcups, libcairo usw. Das Erstellen von `libc-` scheint die richtigen Ergebnisse zu erzielen. vor 9 Jahren 2
Das ist eine ziemlich umständliche und ungenaue Methode. [Wie erkenne ich laufende Prozesse mithilfe eines Bibliothekspakets?] (Http://unix.stackexchange.com/questions/181697/how-do-i-detect-running-processes-using-a-library-package) Anyway, Für glibc ist die Antwort so ziemlich jeder Prozess. Was nützlich wäre, wäre zu wissen, welche Prozesse in der alten Kopie übrig sind, und dieser Befehl sagt Ihnen nichts. Gilles vor 9 Jahren 0
7
Ohnana

Ja, die Prozesse, die von der alten Version von Glibc abhängen, beginnen wieder mit der neuen Version der Bibliothek. Statisch verknüpfte Programme müssen aus diesem Grund ebenfalls neu kompiliert werden.

Statische Verknüpfungen sind jedoch wahrscheinlich selten, angesichts der Wechselwirkungen von DNS-Funktionen mit NSS, glibc und den [historischen Neigungen des früheren glibc-Betreuers] (http://www.akkadia.org/drepper/no_static_linking.html). mr.spuratic vor 9 Jahren 0