{"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 Binarys 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 Standardkernel-Konfiguration verwendet, alle Pakete geladen und die Schutzmechanismen in den eingebetteten Bin\u00e4rdateien analysiert. Die betrachteten Distributionen sind 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-independent Code noch nicht von allen verwendet werden. Die Situation bei Compilern ist noch schlimmer, wenn es um den Schutz vor Schwachstellen wie Stack Clash geht, die im Januar nach der Ver\u00f6ffentlichung von Informationen \u00fcber Schwachstellen in systemd<\/a><\/noindex>. Aber es ist nicht alles hoffnungslos. In einem erheblichen Teil der Bin\u00e4rdateien sind grundlegende Schutzmethoden implementiert, und ihre Anzahl steigt von Version zu Version. <\/p>\n

Die \u00dcberpr\u00fcfung hat ergeben, dass die meisten Schutzma\u00dfnahmen in Ubuntu 18.04 auf Betriebssystem- und Anwendungsebene implementiert sind, gefolgt von Debian 9. Andererseits sind auch in OpenSUSE 12.4, CentOS 7 und RHEL 7 grundlegende Sicherheitsmechanismen vorhanden, wobei der Schutz vor Stack-Kollisionen in einem viel dichteren Standardpaketangebot sogar noch breiter angewendet wird.
\n<\/a><\/noindex><\/p>\n

Einf\u00fchrung<\/h1>\n

\nDie Gew\u00e4hrleistung hochwertiger Software ist eine Herausforderung. Trotz einer Vielzahl fortschrittlicher Werkzeuge zur statischen Codeanalyse und dynamischen Ausf\u00fchrungstests sowie erheblichem Fortschritt in der Compiler- und Programmierungsspracheentwicklung leidet moderne Software nach wie vor unter Schwachstellen, die von Angreifern st\u00e4ndig ausgenutzt werden. Die Situation ist besonders kritisch in \u00d6kosystemen, die veralteten Code enthalten. In solchen F\u00e4llen stehen wir nicht nur vor dem st\u00e4ndigen Problem, potenzielle exploitable Fehler zu finden, sondern sind auch durch strenge R\u00fcckw\u00e4rtskompatibilit\u00e4tsanforderungen eingeschr\u00e4nkt, die oft erfordern, dass begrenzter, noch schlimmer, vulnerabler oder fehlerbehafteter Code erhalten bleibt.<\/p>\n

Hier kommen Methoden zum Einsatz, die Schutz bieten oder Programme absichern (Hardening). Bei einigen Fehlertypen k\u00f6nnen wir nicht verhindern, dass sie auftreten, aber wir k\u00f6nnen es den Angreifern erschweren und das Problem teilweise l\u00f6sen, indem wir es verhindern oder st\u00f6ren. Betriebsf\u00fchrung<\/i> Solche Schutzma\u00dfnahmen werden in allen modernen Betriebssystemen verwendet, unterscheiden sich jedoch stark in Bezug auf Komplexit\u00e4t, Effektivit\u00e4t und Leistung: von Stack-Canaries und ASLR<\/a><\/noindex> bis hin zu vollst\u00e4ndigen Sicherheitssystemen. CFI<\/a><\/noindex> und ROP<\/a><\/noindex>In diesem Artikel betrachten wir, welche Schutzmethoden in den beliebtesten Linux-Distributionen in der Standardkonfiguration verwendet werden, und untersuchen die Eigenschaften der Bin\u00e4rdateien, die \u00fcber die Paketverwaltungssysteme jeder Distribution vertrieben werden.<\/p>\n

CVE und Sicherheit<\/h3>\n

\nWir alle haben Artikel mit Titeln wie \u201eDie anf\u00e4lligsten Anwendungen des Jahres\u201c oder \u201eDie unsichersten Betriebssysteme\u201c gesehen. Normalerweise werden dort Statistiken \u00fcber die Gesamtzahl der Eintr\u00e4ge zu Schwachstellen vom Typ CVE (Common Vulnerability and Exposures)<\/a><\/noindex>angef\u00fchrt, die aus der National Vulnerability Database (NVD) stammen.<\/a><\/noindex> ab NIST<\/a><\/noindex> und andere Quellen. In der Folge werden diese Anwendungen oder Betriebssysteme nach der Anzahl der CVE eingestuft. Leider sagen CVE, obwohl sie sehr n\u00fctzlich sind, um Probleme nachzuverfolgen und Anbieter sowie Benutzer zu informieren, wenig \u00fcber die tats\u00e4chliche Sicherheit der Software aus.<\/p>\n

Um ein Beispiel zu nennen, betrachten wir die Gesamtzahl der CVE in den letzten vier Jahren f\u00fcr den Linux-Kernel sowie 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 von CVE, dass eine Distribution anf\u00e4lliger ist als eine andere? Die Antwort lautet nein. Zum Beispiel werden Sie in diesem Artikel sehen, dass Debian im Vergleich zu OpenSUSE oder RedHat Linux striktere Sicherheitsmechanismen implementiert hat, und dennoch hat Debian mehr CVE. Das bedeutet jedoch nicht zwangsl\u00e4ufig eine verringerte Sicherheit: Selbst das Vorhandensein von CVE sagt nicht aus, ob die Schwachstelle ausnutzbar<\/i>. Schweregrade bieten eine Vorstellung davon, wie wahrscheinlich<\/i> Die Ausnutzung einer Schwachstelle h\u00e4ngt letztlich stark von der vorhandenen Sicherheit der betroffenen Systeme 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> Schwachstellen aus. Die Unterschiede in den CVEs k\u00f6nnen durch verschiedene Faktoren erkl\u00e4rt werden, die nicht unbedingt mit der Softwarequalit\u00e4t zusammenh\u00e4ngen, einschlie\u00dflich der Ressourcen, die f\u00fcr Tests bereitgestellt werden, oder der Gr\u00f6\u00dfe der Benutzerbasis. In unserem Beispiel k\u00f6nnte eine h\u00f6here Anzahl von CVEs bei Debian einfach darauf hinweisen, dass Debian mehr Softwarepakete bereitstellt. <\/p>\n

Nat\u00fcrlich bietet das CVE-System n\u00fctzliche Informationen, die helfen, entsprechende Schutzma\u00dfnahmen zu entwickeln. Je besser wir die Ursachen von Programmfehlern verstehen, desto einfacher ist es, m\u00f6gliche Ausbeutungsarten zu identifizieren und geeignete Erkennungs- und Reaktionsmechanismen<\/i>. Abbildung 2 zeigt die Kategorien von Schwachstellen f\u00fcr alle Distributionen in den letzten vier Jahren (Quelle<\/a><\/noindex>). Es ist sofort ersichtlich, dass die meisten CVEs in folgende Kategorien fallen: Denial of Service (DoS), Codeausf\u00fchrung, Puffer\u00fcberlauf, Speicherbesch\u00e4digung, Datenexfiltration und Privilegieneskalation. Obwohl viele CVEs mehrfach in verschiedenen Kategorien aufgef\u00fchrt sind, bestehen im Gro\u00dfen und Ganzen dieselben Probleme von Jahr zu Jahr. Im n\u00e4chsten Abschnitt des Artikels werden wir die Verwendung verschiedener Schutzmechanismen zur Verhinderung der Ausnutzung der genannten Schwachstellen bewerten.<\/p>\n

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

Aufgaben<\/h3>\n

\nIn diesem Artikel m\u00f6chten wir die folgenden Fragen beantworten:<\/p>\n