Ping of Death: Milliarden Linux-Geräte sind abschussgefährdet

So mancher ältere Windows-Nutzer wird sich noch weniger gut an die frühen Jahre des Webs erinnern, als Besitzer des Microsoft-Betriebssystems gern mal mit einem "Ping of Death" aus dem Netz geworfen wurden. Wie sich nun herausstellt, haben auch ... mehr... Logo, Linux, Maskottchen, Pinguin Bildquelle: Linux Foundation Logo, Linux, Maskottchen, Pinguin Logo, Linux, Maskottchen, Pinguin Linux Foundation

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
"bis ein gepatchter Kernel zur Verfügung steht."

Ein gepatchter Kernel steht bereits zur Verfügung. Die gepatchten Versionen (aktuelle und LTS) sind jeweils 5.1.11, 4.19.52, 4.14.127, 4.9.182, und 4.4.182 . Habe es gerade mit einem Packetupgrade gekriegt.

"/proc/sys/net/ipv4/tcp_sack to 0" erkenne ich übrigens nicht als Terminal-Befehl. Wahrscheinlich steht in der Quelle, dass man "/proc/sys/net/ipv4/tcp_sack" auf 0 setzen soll. Die Befehle auf meinem Server dafür waren z.B.
als Root:
echo 'net.ipv4.tcp_sack = 0' >> /etc/sysctl.conf
um die Konfigurationsdatei zu ändern und
sysctl -p
um die Konfiguration ohne Reboot zu übernehmen.

EDIT: Oder auch "echo 0 > /proc/sys/net/ipv4/tcp_sack" um selektiv diesen einen Wert zu ändern, ohne die Konfiguration neuzuladen (falls man das aus irgendeinem Grund gerade nicht tun möchte). So steht es als ein Workaround auf der Red Hat Webseite zu dieser Sicherheitslücke.

Und
sysctl net.ipv4.tcp_sack
um zu sehen, wie der aktuelle Wert gesetzt ist.
 
@dpazra: Danke für die Info
 
@dpazra: Mal wieder typisch Linux.... 1000 konfuse Terminnalbefehle um etwas simples in Gang zu setzen.... vllt. sollte Linux mal im Jahr 2019 ankommen wo jedes andere Betriebssystem dafür einen hübschen Button bietet ;)
 
@Wasserkopf3000: Ich nehme mal an, du trollst. Aber falls hier jemand drüber stolpert, der sich das tatsächlich fragt:

1. net.ipv4.tcp_sack ist einer von einer locker vierstelligen Anzahl an Parametern (wenn ich mal gucke, wieviel Dateien bei mir unter /proc/sys/ liegen). Eine GUI-Lösung ist für soetwas nicht praktikabel.

2. Solche feine Kontrollmöglichkeiten für das detaillierte Verhalten des Netzwerkstacks findest du auch z.B. unter Windows nicht in der Systemsteuerungs-GUI. Wenn du soetwas abschalten könntest, dann über die Registry, was auch darauf hinausläuft, dass du den vollen Schlüssel der Einstellung in eine Suchmaske tippen musst, Fakt ist aber:

3. Unter Windows Server lässt sich TCP SACK überhaupt nicht manuell abschalten, aber

4. wenn man es unter Windows Server abschalten könnte, würde der Admin es trotzdem nicht über einen Knopf machen, sondern vermutlich über die Power-Shell, denn Server sind üblicherweise headless.

Das ganze normale Systemsteuerungszeug (Auflösung, Desktophintergrund, Nutzereinstellungen, etc.) kann man unter GNOME oder KDE uach per GUI erledigen.

Aber für sysctl kenne ich keine GUI-Anwendung, vermutlich weil es keinen Menschen gibt, der den Bedarf hat, sysctl zu benutzen und sich dabei eine Bedienung über GUI wünscht.
 
@dpazra: ich finde deine Antwort gut... Muss aber auch @wasserkopf3000 zustimmen... Gefühlt 99, 9% wollen das weder eingeben noch wissen was es bedeutet
 
@Wolfi_by: Um diesen Widerspruch vielleicht aufzulösen: für 99,9% der User ist das Problem ja auch egal. Die können ihre Endusertätigkeiten weiterhin fortführen, terminalfrei unter Windows, Mac oder GNU/Linux. Diese Schwachstelle betrifft sie nicht.

Und für die 0,1%, die es zwangsweise interessieren muss (was meinst du, wann ich das erste mal von tcp_sack gehört habe? Gestern, als das Problem bekannt wurde), weil sie dafür verantwortlich sind, dass irgendwo ein Server unterbrechungsfrei läuft, ist es auch kein Problem. Das sind ohnehin gleichzeitig die Leute, die von GUI-Konfiguration nichts wissen wollen, weil das für ihre Workflows zu ineffizient, zu unflexibel und zu unautomatisierbar wäre.

In diesem Sinne gibt es letztlich keinen Interessenskonflikt zwischen den Usern, die keine Terminalbefehle eingeben wollen. aber auch keinen Button brauchen um Kernel-Parameter zu verändern (die man in anderen Systemen ohnehin nicht verändern könnte, da müsste man dann auf den Hotfix warten), und den Usern, die Kernelparameter anpassen müssen und das auch von sich aus bevorzugt über ein Textinterface erledigen möchten.
 
@dpazra: Das schöne an Windows ist hier ja einfach, dass es beides gibt. Powershell und Klick. Unter Tux bist du halt IMMER an das Terminal gebunden.
 
@Bautz: Was ja auch ziemlicher Blödsinn ist. Wie dpazra oben schon geschrieben hat, gibt es für einfacherere Sachen genau wie unter Windows GUI-basierte Tools und bei komplizierten Sachen eben nicht, weil es eher ein Nachteil ist, sowas dort zu verwenden. Möchtest du ggf. einen Registry-Editor verwenden, der für jeden Parameter einen Button, eine Spinbox oder eine Combobox verwendet? Oder doch lieber die übliche Baumansicht, die zwar nicht komfortabel, aber dafür der Sache dienlich ist?
 
@Mordy: regedit ist aber grafisch. Alternativ kann ich werte über Powershell setzen. Wie ich möchte. Unter Tux muss ich das Terminal nehmen.
 
@Bautz: Um es nochmal ganz klar zu machen:

Unter GNU/Linux musst du nicht (!) das Terminal dafür nutzen. Du kannst deinen grafischen Dateibrowser nehmen (das Äquivalent zu Windows Explorer), zu der Datei /proc/sys/net/ipv4/tcp_sack gehen, sie mit einem Texteditor öffnen und eine 0 reinschreiben.

Dann ist die UX wie unter Windows mit zwei Unterschieden

1. Du musst regedit öffnen, weil unter Linux alle Dateisysteme inkl. solcher virtuellen Dateien in einem einzigen Baum liegen, d.h. regedit und Windows Explorer sind bei GNU/Linux in einem Dateibrowser vereint.

2. Unter GNU/Linux funktioniert das Abschalten dann auch, unter Windows 7/der entsprechenden Windows Server Version kannst du den Registryeintrag für TCP SACK auf 0 setzen, es läuft aber trotzdem weiter, zumindest laut Rechnet Forum und kA ob sich das in späteren Versionen geändert hat.

Warum habe ich oben den Terminal-Weg beschrieben? Weil kein normaler GNU/Linux-Admin einen grafischen Dateibrowser auf seinem Server aufruft um einen Laufzeitparameter zu ändern. Aber ja, er kann es exakt so grafisch machen wie unter Windows mit Regedit und dann funktioniert es sogar.
 
@Bautz: Und welcher Unterschied besteht z.B. darin, einen Befehl ins Terminal oder alternativ ins Powershell-Fenster einzutippern? So ziemlich keiner, oder? Außer vielleicht, dass die Befehle anders aussehen.

Edit: Ah so... übrigens habe ich auch nicht bezweifelt, dass regedit eine GUI hat. Nur ist sie eben sehr minimal, quasi wie ein Dateibrowser Light. Das reicht aber auch für den Zweck. Wie ich geschrieben habe... "der Sache dienlich".
 
@Mordy: Ich meinte auch nicht dass es nen Unterschied zwischen PS und Terminal gibt - aber einen einen zwischen "klickbar" und "nicht klickbar". Ich mag eben gerne beides, je nach dem was ich grade mache.
 
@Bautz: Unter Windows gibt es für die überwältigende Anzahl von Detail-Konfigurationen überhaupt keine Möglichkeit zur Änderung der selbigen. Für das meiste, das man ändern kann, braucht man Regedit/die Powershell. Beides kein nenneswerter Vorteil zu einem Terminal. Dafür ist Ersteres meist wesentlich langsamer und umständlich, zweites selten dokumentiert und durch die Syntax/Objekt-Modell alles andere als eine angenehm zu benutzende Shell.

Und für eine Handvoll Optionen gibt es die GUI. Mit dem Effekt, dass das Gros der selbsternannten "PC-Profis" von nix wissen, was nicht über eine GUI erreichbar ist und sich nach 10 Minuten rumklicken für der aller Weisheit Schluss halten.

Das Windows-Szenario zu diesem konkreten TCP-SACK Setting nur als Beispiel: https://social.technet.microsoft.com/Forums/windows/en-US/a0bfba52-5f75-4c7e-b954-ac59fb631ee7/windows-7-tcpip-tuning-sack-and-tcp1323-options?forum=w7itpronetworking

"If the situations are true, then the SACK option will be automatically disabled. If not, the option cannot be disabled manually."

Also weder Powershell, Regedit *noch* GUI. Ganz großes Kino.
 
@Wasserkopf3000: Btw. (Sorry für doppelte Antwort), wenn diese Befehle wirklich konfus erscheinen, kann ich ja kurz sagen, was sie tun:
echo 'net.ipv4.tcp_sack = 0' >> /etc/sysctl.conf
schreibt einfach "net.ipv4.tcp_sack = 0" ans Ende der Datei /etc/sysctl.conf . Man könnte auch einen Texteditor mit Adminrechten starten, die Datei öffnen, die Zeile eintippen, auf ein Speichern Icon klicken und auf ein Schließen Icon klicken, aber das erschiene mir umständlich.
sysctl -p
Lädt die Konfigurationsdatei neu. Man könnte aber auch den Windows-Weg nehmen und nach einer wichtigen Einstellung das System neustarten.

echo 0 > /proc/sys/net/ipv4/tcp_sack
schreibt "0" in die Datei "/proc/sys/net/ipv4/tcp_sack" . Das könnte man auch mit einem Texteditor mit Admin-Rechten tun, wäre aber (wie oben beschrieben) eher umständlich. Bestimmt 10 Mausklicks inkl. Datei aus dem Dateisystem suchen, das dauert fünfmal solange, wie die "0" einfach mit "echo" in die Datei zu schicken.
 
@dpazra: Danke. Diejenigen, die es wissen müssen, verstehen diese "1000 konfuse Terminnalbefehle" sehr wahrscheinlich bereits. Und der Rest ... naja... :-)
 
@Wasserkopf3000: Ich glaube, mit "jedes andere Betriebssystem" meinst du selbiges, worauf ein IT-Profi wie du seine Zertifizierung im Fortnite starten erworben hat und seitdem glaubt, ausgelernt zu haben.
 
@dpazra: und wie verschicke ich den "Test"-Ping? Natürlich nur zum Prüfen ob mein System nicht mehr gefährdet ist? ^^
 
Ich hätte es schön gefunden im Artikel zumindest kurz zu erläutern, wofür dieses Feature gut ist, welches man als Workaround deaktivieren soll. Ich persönlich halte es für suboptimal einfach mal Empfehlungen rauszugeben, bestimmte Dinge zu deaktivieren, ohne dass derjenige eine Idee davon hat, was er da jetzt abstellt.
 
@KarstenS: Ich verstehe es ganz grob so: Bei einer TCP-Übertragung gibt es eine gewisse Menge an Paketen, die übertragen werden, bis die Gegenseite bestätigen muss. Gehen dabei Pakete verloren, müssen die Pakete neu übertragen werden. tcp_sack ist eine Erweiterung, die dafür sorgt, dass nur die verlorenen Pakete neu übertragen werden müssen. Dementsprechend wäre vermutlich die Konsequenz des Workarounds eine etwas erhöhte Bandbreitennutzung im Falle von Übertragungen mit Paketverlusten (aber näher quantifizieren könnte ich das jetzt nicht).
 
ich glaub, das ist ein heftiger fail, gerade für die embedded systeme.
 
@mditsch: Wer nicht Update-fähige Geräte im Internet hat oder Update-fähige Geräte im Internet hat und diese halt nie updated, hat neben diesem Problem auch recht viele andere Probleme.
 
@mditsch: Um das ein bisschen zu relativieren, ohne das Problem kleinzureden und mit einem Disclaimer, weil ich mich hier auch täuschen könnte:

So, wie ich das Problem verstehe, betrifft es in erster Linie Geräte, die mit einer öffentlich einsehbaren IPv4 am Internet hängen, damit du ihnen direkt diese Pakete zuschicken kannst. In einem Privathaushalt z.B. ist das Gerät mit der öffentlichen IPv4 Adresse normalerweise der Router und der kriegt Firmware-Upgrades.

Generell ist es so, wenn du eine globale IPv4-Adresse hast, dann hast du ein dauerhaftes Grundrauschen an automatisierten Angriffen, solche Geräte sind also wie bisher höchstgradig gefährdet. Da kann man eigentlich bei jedem Webserver in die Logs gucken und findet mit absoluter Sicherheit folgendes:

Endlose gescheiterte Login-Versuche von nichtexistierenden Usern namens "pi" (Standarduser beim Raspberry Pi), "ts" (oder irgendetwas anderes Teamspeak-bezogenes, vielleicht hat das mit dem Erfolg von Discord ja inzwischen nachgelassen), "admin", "joe", "john", "root" (ok, der existiert zwar schon, erlaubt aber hoffentlich keine direkten SSH-Logins), usw.

Wenn der Server noch ein E-Mail-Server ist, dann endlose Login-Versuche von info@, facebook@, support@, admin@ usw. und hinter dem @ jede Domain, deren Seite auf dem Server gehostet wird oder mal gehostet wurde.

Wenn der Server auch noch Webseiten über HTTP ausliefert, finden sich in den Logs endlose gescheiterte Zugriffe auf [domainname.tld]/wp-admin/irgendetwas oder [domainname.tld]/index.php?id=[irgendetwas, was vermutlich eine SQL-Injection sein soll]

usw. usf. Was ich damit sagen will: Eine Denial-Of-Service-Vulnerability über manipulierte TCP-Pakete reiht sich ein unter endlose automatisierte Angriffe, denen ungepatchte Geräte schon heute ausgesetzt sind.
 
@dpazra: Das Problem ist leider etwas weitreichender:

Router: Für die meisten Geräte, welche im professionellen Bereich genutzt werden, wird es Updates des Kernels (Firmware) geben, dort steht meistens auch eine SHELL zur Verfügung, unter welcher der Kernel Parameter zum Deaktivieren von TCP_SACK gesetzt werden kann.
Für manche Geräte wird es aber keinen Patch geben, und das meistens bei günstigen Home Routern, wo es auch 0 Möglichkeiten gibt, ein Terminal zu erreichen und den Parameter zu ersetzen.

IoT und Kameras: Da sehe ich das größte Risiko. Wenn es jemandem gelungen ist in ein Netzwerk einzudringen, kann er mit einem (relativ) einfachen Befehl sämmtliche Kameras und IoT Geräte lahmlegen. Selbst professionelle Sicherheitskameras erhalten selten Updates. Normalerweise muss man für so etwas einen expliziten Exploit haben, oder die Login Daten, jetzt gibt es einen generellen KILL-SWITCH.
Ganz davon abgesehen von öffentlich erreichbaren Kameras und IoT Devices, mach mal eine Suche über Shodan.
 
@mditsch: Das Problem betrifft alle Geräte, welche direkt am Internet hängen oder via NAT oder andere Mittel von öffentlichen/halböffentlichen aus Netzen erreichbar sind. Das schirmt aber die überwältigende Mehrheit aller betroffenen Geräte schon ab, weil diese eben nie von der öffentlichen Seite des Internets erreichbar sind. Bei den öffentlich erreichbaren Geräte sollte der Admin nun aber spuren.
Kommentar abgeben Netiquette beachten!
Einloggen

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.