{"id":29880,"date":"2019-10-31T21:32:27","date_gmt":"2019-10-31T18:32:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/milliony-binarnikov-spustya-kak-ukreplyalsya-linux\/"},"modified":"2019-10-31T21:32:27","modified_gmt":"2019-10-31T18:32:27","slug":"milliony-binarnikov-spustya-kak-ukreplyalsya-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/milliony-binarnikov-spustya-kak-ukreplyalsya-linux","title":{"rendered":"Millionen von Bin\u00e4rdateien sp\u00e4ter. Wie Linux gest\u00e4rkt wurde","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MillionenTL;DR<\/b>. In diesem Artikel untersuchen wir die Hardening-Schemata, die standardm\u00e4\u00dfig in f\u00fcnf beliebten Linux-Distributionen funktionieren. F\u00fcr jede haben wir die Standard-Kernel-Konfiguration verwendet, alle Pakete installiert und die Schutzmechanismen in den eingebetteten Bin\u00e4rdateien analysiert. Betrachtet werden die Distributionen OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 und 7 sowie Ubuntu 14.04, 12.04 und 18.04 LTS. <\/p>\n

Die Ergebnisse best\u00e4tigen, dass selbst grundlegende Schemata wie Stack Canary und position-unabh\u00e4ngiger Code noch nicht von allen verwendet werden. Die Situation ist bei Compilern noch schlimmer, wenn es um den Schutz gegen Schwachstellen wie Stack Clash geht, die nach der Ver\u00f6ffentlichung im Januar in den Fokus gerieten von Schwachstellen in systemd<\/a><\/noindex>. Aber es ist nicht alles hoffnungslos. Ein erheblicher Teil der Bin\u00e4rdateien implementiert grundlegende Schutzmethoden, und ihre Anzahl w\u00e4chst von Version zu Version. <\/p>\n

Die \u00dcberpr\u00fcfung zeigte, dass die meisten Schutzmethoden in Ubuntu 18.04 auf Betriebssystem- und Anwendungsebene umgesetzt sind, gefolgt von Debian 9. Andererseits haben auch OpenSUSE 12.4, CentOS 7 und RHEL 7 grundlegende Schutzmechanismen implementiert, wobei der Schutz vor Stack Clash bei einem viel dichteren Standardpaketangebot noch umfassender ausgepr\u00e4gt ist.
\n<\/a><\/noindex><\/p>\n

Einf\u00fchrung<\/h1>\n

\nEs ist schwierig, eine hohe Softwarequalit\u00e4t zu gew\u00e4hrleisten. Trotz der Vielzahl an fortgeschrittenen Werkzeugen f\u00fcr die statische Code-Analyse und die dynamische Analyse zur Laufzeit sowie des erheblichen Fortschritts bei der Entwicklung von Compilern und Programmiersprachen leidet moderne Software weiterhin unter Schwachstellen, die st\u00e4ndig von Angreifern ausgenutzt werden. Die Situation ist in \u00d6kosystemen, die veralteten Code enthalten, noch schlimmer. In solchen F\u00e4llen stehen wir nicht nur vor dem immerw\u00e4hrenden Problem der Suche nach potenziell exploitable Bugs, sondern sind auch durch strenge Vorgaben zur R\u00fcckw\u00e4rtskompatibilit\u00e4t eingeschr\u00e4nkt, die h\u00e4ufig verlangen, dass wir rudiment\u00e4ren, noch schlimmer, verwundbaren oder fehlerhaften Code beibehalten.<\/p>\n

Hier kommen Schutz- oder Hardening-Methoden ins Spiel. Einige Arten von Fehlern k\u00f6nnen wir nicht verhindern, aber wir k\u00f6nnen das Leben der Angreifer erschweren und das Problem teilweise l\u00f6sen, indem wir die Ausnutzung verhindern oder behindern der Ausnutzung<\/i> diese Fehler. Dieser Schutz wird in allen modernen Betriebssystemen verwendet, jedoch unterscheiden sich die Methoden stark in Bezug auf Komplexit\u00e4t, Effizienz und Leistung: von Stack Canary und ASLR<\/a><\/noindex> bis hin zu umfassenden Schutzma\u00dfnahmen CFI<\/a><\/noindex> und ROP<\/a><\/noindex>. In diesem Artikel werden wir die Schutzmethoden untersuchen, die in den beliebtesten Linux-Distributionen in der Standardkonfiguration verwendet werden, und die Eigenschaften der Bin\u00e4rdateien analysieren, die \u00fcber die Paketverwaltungssysteme jeder Distribution verteilt werden.<\/p>\n

CVE und Sicherheit<\/h3>\n

\nWir haben alle Artikel mit Titeln wie \u201eDie anf\u00e4lligsten Anwendungen des Jahres\u201c oder \u201eDie anf\u00e4lligsten Betriebssysteme\u201c gesehen. \u00dcblicherweise wird dort die Statistik zu den Gesamtzahlen der Schwachstellendaten ver\u00f6ffentlicht, die vom Typ CVE (Common Vulnerability and Exposures)<\/a><\/noindex>, die aus der National Vulnerability Database (NVD)<\/a><\/noindex> ab NIST<\/a><\/noindex> und anderen Quellen stammen. Anschlie\u00dfend werden diese Anwendungen oder Betriebssysteme nach der Anzahl der CVEs eingestuft. Leider sind CVEs, obwohl sie sehr n\u00fctzlich sind, um Probleme zu verfolgen und Anbieter und Benutzer zu informieren, wenig aussagekr\u00e4ftig \u00fcber die tats\u00e4chliche Sicherheit der Software.<\/p>\n

Zum Beispiel betrachten wir die Gesamtzahl der CVEs der letzten vier Jahre f\u00fcr den Linux-Kernel und f\u00fcnf der beliebtesten Server-Distributionen, n\u00e4mlich Ubuntu, Debian, Red Hat Enterprise Linux und OpenSUSE.<\/p>\n

\"Millionen
\nAbb. 1<\/i><\/p>\n

Was sagt uns dieses Diagramm? Bedeutet eine h\u00f6here Anzahl an CVEs, dass eine Distribution anf\u00e4lliger ist als eine andere? Die Antwort ist nein. Beispielsweise werden Sie in diesem Artikel sehen, dass in Debian strengere Schutzmechanismen implementiert sind im Vergleich zu OpenSUSE oder RedHat Linux, und dennoch hat Debian mehr CVEs. Das bedeutet jedoch nicht unbedingt, dass die Sicherheit geschw\u00e4cht ist: Selbst das Vorhandensein von CVEs sagt nicht aus, ob die Schwachstelle ausnutzbar<\/i>. Die Schwerepunkte geben einen Hinweis darauf, wie wahrscheinlich<\/i> eine Ausnutzung der Schwachstelle ist, aber letztendlich h\u00e4ngt die Ausnutzbarkeit stark vom Schutz in den betroffenen Systemen sowie von den Ressourcen und F\u00e4higkeiten der Angreifer ab. Dar\u00fcber hinaus sagt das Fehlen von CVE-Berichten nichts \u00fcber andere nicht registrierte oder unbekannte<\/i> Sicherheitsanf\u00e4lligkeiten. Der Unterschied in CVE kann nicht durch die Qualit\u00e4t der Software erkl\u00e4rt werden, sondern durch andere Faktoren, einschlie\u00dflich der Ressourcen, die f\u00fcr Tests bereitgestellt werden, oder der Gr\u00f6\u00dfe der Benutzerbasis. In unserem Beispiel k\u00f6nnte die h\u00f6here Anzahl an CVEs in Debian einfach darauf hinweisen, dass Debian mehr Softwarepakete bereitstellt. <\/p>\n

Nat\u00fcrlich bietet das CVE-System n\u00fctzliche Informationen, die es erm\u00f6glichen, entsprechende Schutzma\u00dfnahmen zu entwickeln. Je besser wir die Ursachen von Programmfehlern verstehen, desto einfacher ist es, m\u00f6gliche Ausnutzungsarten zu identifizieren und entsprechende Mechanismen zu entwickeln, um zu erkennen und zu reagieren.<\/i>. In Abb.\u00a02 sind die Kategorien von Sicherheitsanf\u00e4lligkeiten f\u00fcr alle Distributionen in den letzten vier Jahren dargestellt (Quelle<\/a><\/noindex>). Es ist sofort ersichtlich, dass die meisten CVEs in die folgenden Kategorien fallen: Denial of Service (DoS), Codeausf\u00fchrung, Puffer\u00fcberlauf, Speicherbesch\u00e4digung, Datenlecks (Exfiltration) und Privilegieneskalation. Obwohl viele CVEs mehrfach in verschiedenen Kategorien erfasst sind, zeigen sich insgesamt dieselben Probleme Jahr f\u00fcr Jahr. Im n\u00e4chsten Teil des Artikels werden wir den Einsatz verschiedener Schutzmechanismen bewerten, um die genannten Sicherheitsanf\u00e4lligkeiten zu verhindern.<\/p>\n

\"Millionen
\nAbb. 2<\/i><\/p>\n

Aufgaben<\/h3>\n

\nIn diesem Artikel beabsichtigen wir, die folgenden Fragen zu beantworten:<\/p>\n