TL;DR. In diesem Artikel untersuchen wir die Hardening-Schemata, die standardmäßig in fünf beliebten Linux-Distributionen funktionieren. Für jede haben wir die Standard-Kernel-Konfiguration verwendet, alle Pakete installiert und die Schutzmechanismen in den eingebetteten Binärdateien 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.

Die Ergebnisse bestätigen, dass selbst grundlegende Schemata wie Stack Canary und position-unabhängiger 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öffentlichung im Januar in den Fokus gerieten von Schwachstellen in systemd. Aber es ist nicht alles hoffnungslos. Ein erheblicher Teil der Binärdateien implementiert grundlegende Schutzmethoden, und ihre Anzahl wächst von Version zu Version.

Die Überprüfung 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ägt ist.

Einführung

Es ist schwierig, eine hohe Softwarequalität zu gewährleisten. Trotz der Vielzahl an fortgeschrittenen Werkzeugen für 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ändig von Angreifern ausgenutzt werden. Die Situation ist in Ökosystemen, die veralteten Code enthalten, noch schlimmer. In solchen Fällen stehen wir nicht nur vor dem immerwährenden Problem der Suche nach potenziell exploitable Bugs, sondern sind auch durch strenge Vorgaben zur Rückwärtskompatibilität eingeschränkt, die häufig verlangen, dass wir rudimentären, noch schlimmer, verwundbaren oder fehlerhaften Code beibehalten.

Hier kommen Schutz- oder Hardening-Methoden ins Spiel. Einige Arten von Fehlern können wir nicht verhindern, aber wir können das Leben der Angreifer erschweren und das Problem teilweise lösen, indem wir die Ausnutzung verhindern oder behindern der Ausnutzung diese Fehler. Dieser Schutz wird in allen modernen Betriebssystemen verwendet, jedoch unterscheiden sich die Methoden stark in Bezug auf Komplexität, Effizienz und Leistung: von Stack Canary und ASLR bis hin zu umfassenden Schutzmaßnahmen CFI und ROP. In diesem Artikel werden wir die Schutzmethoden untersuchen, die in den beliebtesten Linux-Distributionen in der Standardkonfiguration verwendet werden, und die Eigenschaften der Binärdateien analysieren, die über die Paketverwaltungssysteme jeder Distribution verteilt werden.

CVE und Sicherheit

Wir haben alle Artikel mit Titeln wie „Die anfälligsten Anwendungen des Jahres“ oder „Die anfälligsten Betriebssysteme“ gesehen. Üblicherweise wird dort die Statistik zu den Gesamtzahlen der Schwachstellendaten veröffentlicht, die vom Typ CVE (Common Vulnerability and Exposures), die aus der National Vulnerability Database (NVD) ab NIST und anderen Quellen stammen. Anschließend werden diese Anwendungen oder Betriebssysteme nach der Anzahl der CVEs eingestuft. Leider sind CVEs, obwohl sie sehr nützlich sind, um Probleme zu verfolgen und Anbieter und Benutzer zu informieren, wenig aussagekräftig über die tatsächliche Sicherheit der Software.

Zum Beispiel betrachten wir die Gesamtzahl der CVEs der letzten vier Jahre für den Linux-Kernel und fünf der beliebtesten Server-Distributionen, nämlich Ubuntu, Debian, Red Hat Enterprise Linux und OpenSUSE.

Abb. 1

Was sagt uns dieses Diagramm? Bedeutet eine höhere Anzahl an CVEs, dass eine Distribution anfälliger 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ächt ist: Selbst das Vorhandensein von CVEs sagt nicht aus, ob die Schwachstelle ausnutzbar. Die Schwerepunkte geben einen Hinweis darauf, wie wahrscheinlich eine Ausnutzung der Schwachstelle ist, aber letztendlich hängt die Ausnutzbarkeit stark vom Schutz in den betroffenen Systemen sowie von den Ressourcen und Fähigkeiten der Angreifer ab. Darüber hinaus sagt das Fehlen von CVE-Berichten nichts über andere nicht registrierte oder unbekannte Sicherheitsanfälligkeiten. Der Unterschied in CVE kann nicht durch die Qualität der Software erklärt werden, sondern durch andere Faktoren, einschließlich der Ressourcen, die für Tests bereitgestellt werden, oder der Größe der Benutzerbasis. In unserem Beispiel könnte die höhere Anzahl an CVEs in Debian einfach darauf hinweisen, dass Debian mehr Softwarepakete bereitstellt.

Natürlich bietet das CVE-System nützliche Informationen, die es ermöglichen, entsprechende Schutzmaßnahmen zu entwickeln. Je besser wir die Ursachen von Programmfehlern verstehen, desto einfacher ist es, mögliche Ausnutzungsarten zu identifizieren und entsprechende Mechanismen zu entwickeln, um zu erkennen und zu reagieren.. In Abb. 2 sind die Kategorien von Sicherheitsanfälligkeiten für alle Distributionen in den letzten vier Jahren dargestellt (Quelle). Es ist sofort ersichtlich, dass die meisten CVEs in die folgenden Kategorien fallen: Denial of Service (DoS), Codeausführung, Pufferüberlauf, Speicherbeschädigung, Datenlecks (Exfiltration) und Privilegieneskalation. Obwohl viele CVEs mehrfach in verschiedenen Kategorien erfasst sind, zeigen sich insgesamt dieselben Probleme Jahr für Jahr. Im nächsten Teil des Artikels werden wir den Einsatz verschiedener Schutzmechanismen bewerten, um die genannten Sicherheitsanfälligkeiten zu verhindern.

Abb. 2

Aufgaben

In diesem Artikel beabsichtigen wir, die folgenden Fragen zu beantworten:

• Wie sicher sind die verschiedenen Linux-Distributionen? Welche Schutzmechanismen existieren im Kern und in den Anwendungen des Benutzerraums?
• Wie hat sich die Akzeptanz von Schutzmechanismen im Laufe der Zeit für verschiedene Distributionen verändert?
• Wie sehen die durchschnittlichen Abhängigkeiten von Paketen und Bibliotheken für jede Distribution aus?
• Welche Schutzmaßnahmen sind für jede Binärdatei implementiert?

Auswahl der Distributionen

Es stellt sich heraus, dass es schwierig ist, genaue Statistiken über Installationen von Distributionen zu finden, da in den meisten Fällen die Anzahl der Downloads nicht die Anzahl der tatsächlichen Installationen angibt. Dennoch bilden Unix-Varianten die Mehrheit der Serversysteme (auf Webservern 69,2%, laut Statistik W3techs und anderen Quellen), und ihr Anteil wächst ständig. Daher haben wir uns für unsere Untersuchung auf Distributionen konzentriert, die „out of the box“ auf der Plattform Google Cloudverfügbar sind. Insbesondere wählten wir die folgenden Betriebssysteme:

Distribution/Version
Kern
Build

OpenSUSE 12.4
4.12.14-95.3-default
#1 SMP Wed Dec 5 06:00:48 UTC 2018 (63a8d29)

Debian 9 (stretch)
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018-10-27)

CentOS 6.10
2.6.32-754.10.1.el6.x86_64
#1 SMP Tue Jan 15 17:07:28 UTC 2019

CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP Fri Feb 1 14:54:57 UTC 2019

Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP Wed Nov 21 15:08:21 EST 2018

Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP Thu Nov 15 17:36:42 UTC 2018

Ubuntu 14.04 (Trusty Tahr)
4.4.0–140-generic

#166~14.04.1-Ubuntu SMP Sat Nov 17 01:52:43 UTC 20…

Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP Fri Dec 7 09:59:47 UTC 2018

Ubuntu 18.04 (Bionic Beaver)
4.15.0–1026-gcp
#27-Ubuntu SMP Thu Dec 6 18:27:01 UTC 2018

Tabelle 1

Analyse

Wir werden die Standardkernelkonfiguration sowie die Eigenschaften der Pakete untersuchen, die über den Paketmanager jeder Distribution standardmäßig verfügbar sind. Dadurch konzentrieren wir uns ausschließlich auf Pakete aus den Standardspiegeln jeder Distribution und ignorieren Pakete aus instabilen Repositories (z. B. aus den ‘testing’-Spiegeln in Debian) sowie Drittanbieterpakete (z. B. Nvidia-Pakete aus den Standardspiegeln). Außerdem betrachten wir keine benutzerdefinierten Kernels oder Konfigurationen mit erhöhtem Schutz.

Analyse der Kernelkonfiguration

Wir haben ein Analyse-Skript basierend auf dem freien Kconfig-Checkerangewendet. Wir betrachten die Standard-Schutzparameter der genannten Distributionen und vergleichen sie mit der Liste von dem Kernel Self-Protection Project (KSPP). Für jeden Konfigurationsparameter beschreibt Tabelle 2 die gewünschte Einstellung: Ein Häkchen steht für Distributionen, die den Empfehlungen des KSSP entsprechen (eine Erklärung der Begriffe siehe hier; in zukünftigen Artikeln werden wir erläutern, wie viele dieser Schutzmaßnahmen entstanden sind und wie man das System in deren Abwesenheit kompromittiert).

Im Allgemeinen verfügen neue Kernel über strengere Standardkonfigurationen. Zum Beispiel haben CentOS 6.10 und RHEL 6.10 auf Kernel 2.6.32 die meisten kritischen Funktionen, die in neuen Kerneln implementiert wurden, nicht, wie SMAP, strikte RWX-Berechtigungen, Adressrandomisierung oder der Schutz von copy2usr. Es ist anzumerken, dass viele der Konfigurationsoptionen aus der Tabelle in älteren Kernelversionen fehlen und in der Realität nicht anwendbar sind – in der Tabelle wird das trotzdem als fehlender angemessener Schutz angegeben. Ebenso wird, wenn ein Konfigurationsparameter in dieser Version fehlt und für die Sicherheit deaktiviert werden muss, dies als sinnvolle Konfiguration angesehen.

Ein weiterer Punkt bei der Interpretation der Ergebnisse: Einige Kernel-Konfigurationen, die die Angriffsfläche erhöhen, können gleichzeitig für die Sicherheit verwendet werden. Solche Beispiele umfassen uprobes und kprobes, Kernel-Module und BPF/eBPF. Unsere Empfehlung ist, die oben genannten Mechanismen zur Gewährleistung des tatsächlichen Schutzes zu nutzen, da sie nicht trivial in der Anwendung sind und deren Ausnutzung voraussetzt, dass böswillige Akteure bereits im System Fuß gefasst haben. Aber wenn diese Optionen aktiviert sind, sollte der Systemadministrator aktiv die Missbräuche überwachen.

Wenn wir die Einträge in Tabelle 2 weiter untersuchen, sehen wir, dass moderne Kernel mehrere Optionen zum Schutz vor der Ausnutzung solcher Schwachstellen wie Informationsleck und Stack-/Heap-Overflow bieten. Allerdings stellen wir fest, dass selbst die neuesten beliebten Distributionen noch keinen komplexeren Schutz implementiert haben (z. B. mit Patches grsecurity) oder modernen Schutz gegen Code-Reuse-Angriffe (wie die Kombination von Randomisierung mit R^X-Schemata für Code). Noch schlimmer ist, dass selbst diese fortschrittlicheren Schutzmaßnahmen nicht vor dem gesamten Spektrum von Angriffen schützen. Daher ist es für Systemadministratoren von größter Bedeutung, sinnvolle Konfigurationen mit Lösungen zu ergänzen, die die Erkennung und Verhinderung von Exploits zur Laufzeit anbieten.

Anwendungsanalyse

Es ist nicht verwunderlich, dass verschiedene Distributionen unterschiedliche Paketmerkmale, Compiler-Optionen, Bibliotheksabhängigkeiten usw. aufweisen. Unterschiede bestehen sogar bei verwandten Distributionen und Paketen mit wenigen Abhängigkeiten (z. B. coreutils in Ubuntu oder Debian). Um die Unterschiede zu bewerten, haben wir alle verfügbaren Pakete heruntergeladen, ihren Inhalt extrahiert und die Binärdateien sowie Abhängigkeiten analysiert. Für jedes Paket haben wir andere Pakete verfolgt, von denen es abhängt, und für jede Binärdatei die Abhängigkeiten nachverfolgt. In diesem Abschnitt fassen wir die Ergebnisse kurz zusammen.

Distributionen

Insgesamt haben wir 361 556 Pakete für alle Distributionen heruntergeladen, indem wir nur Pakete von den Standard-Servern extrahiert haben. Pakete ohne ausführbare ELF-Dateien, wie Quellcodes, Schriftarten usw., wurden ignoriert. Nach der Filterung blieben 129 569 Pakete übrig, die insgesamt 584 457 Binärdateien enthielten. Die Verteilung der Pakete und Dateien auf die Distributionen ist in Abbildung 3 dargestellt.

Abbildung 3

Es ist zu erkennen, dass neuere Distributionen mehr Pakete und Binärdateien enthalten, was sinnvoll ist. Dabei enthalten die Pakete von Ubuntu und Debian deutlich mehr Binärdateien (sowohl ausführbare Dateien als auch dynamische Module und Bibliotheken) als CentOS, SUSE und RHEL, was potenziell die Angriffsfläche von Ubuntu und Debian erhöht (es sei angemerkt, dass die Zahlen alle Binärdateien aller Versionen eines Pakets widerspiegeln, d.h. einige Dateien werden mehrere Male analysiert). Dies ist insbesondere wichtig, wenn man die Abhängigkeiten zwischen den Paketen berücksichtigt. Eine Schwachstelle in der Binärdatei eines Pakets kann zahlreiche Teile des Ökosystems betreffen, da eine verwundbare Bibliothek alle Binärdateien beeinflussen kann, die sie importieren. Lassen Sie uns als Ausgangspunkt die Verteilung der Anzahl der Abhängigkeiten pro Paket in verschiedenen Betriebssystemen betrachten:

Abbildung 4

Fast alle Distributionen haben bei 60 % der Pakete mindestens 10 Abhängigkeiten. Darüber hinaus haben einige Pakete deutlich mehr Abhängigkeiten (über 100). Das Gleiche gilt für die umgekehrten Abhängigkeiten der Pakete: Wie erwartet werden mehrere Pakete von vielen anderen Paketen in der Distribution verwendet, sodass Schwachstellen in diesen wenigen ausgewählten Paketen ein hohes Risiko darstellen. Als Beispiel sind in der folgenden Tabelle 20 Pakete mit den meisten umgekehrten Abhängigkeiten in SLES, CentOS 7, Debian 9 und Ubuntu 18.04 aufgeführt (in jeder Zelle ist das Paket und die Anzahl der umgekehrten Abhängigkeiten angegeben).

Tabelle 3

Eine interessante Tatsache. Obwohl alle analysierten Betriebssysteme für die Architektur x86_64 entwickelt wurden und die meisten Pakete die Architektur als x86_64 und x86 definiert haben, enthalten Pakete oft Binärdateien für andere Architekturen, wie in Abbildung 5 dargestellt.

Abbildung 5

Im nächsten Abschnitt werden wir uns eingehender mit den Eigenschaften der analysierten Binärdateien befassen.

Statistik zur Sicherheit von Binärdateien

Als absolutes Minimum sollten Sie die grundlegenden Schutzoptionen für vorhandene Binärdateien untersuchen. Einige Linux-Distributionen werden mit Skripten geliefert, die solche Überprüfungen durchführen. Zum Beispiel gibt es in Debian/Ubuntu ein solches Skript. Hier ist ein Beispiel für seine Funktionsweise:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: ja
 Stack protected: ja
 Fortify Source-Funktionen: nein, nur ungeschützte Funktionen gefunden!
 Read-only relocations: ja
 Immediate binding: ja

Das Skript überprüft fünf Schutzfunktionen:

• Position Independent Executable (PIE): Gibt an, ob der Textabschnitt des Programms im Speicher verschoben werden kann, um Randomisierung zu erreichen, wenn ASLR im Kernel aktiviert ist.
• Stack Protected: Sind Stack-Canarys aktiviert, um vor Stack-Kollision-Angriffen zu schützen?
• Fortify Source: Werden unsichere Funktionen (z. B. strcpy) durch ihre sichereren Pendants ersetzt, und werden zur Laufzeit geprüfte Aufrufe durch nicht geprüfte Pendants (z. B. memcpy anstelle von __memcpy_chk) ersetzt?
• Read-only relocations (RELRO): Sind die Einträge in der Relocation-Tabelle als "nur lesbar" gekennzeichnet, wenn sie vor dem Beginn der Ausführung wirksam wurden?
• Immediate binding (sofortige Bindung): Erlaubt der Laufzeitlinker alle Relocation vor Beginn der Programmausführung (das entspricht vollem RELRO).

Reichen die oben genannten Mechanismen aus? Leider nicht. Es sind Umgehungsmethoden für alle oben genannten Schutzmaßnahmen bekannt, aber je strenger der Schutz ist, desto höher ist die Hürde für den Angreifer. Zum Beispiel sind Umgehungsmethoden für RELRO schwieriger anzuwenden, wenn PIE und sofortige Bindung aktiv sind. Entsprechend erfordert vollständiges ASLR zusätzliche Arbeit, um einen funktionierenden Exploit zu erstellen. Allerdings sind raffinierte Angreifer bereits gewappnet, um solche Schutzmaßnahmen zu überwinden: deren Fehlen beschleunigt im Grunde den Bruch. Daher ist es von äußerst wichtiger Bedeutung, dass diese Maßnahmen als notwendig betrachtet werden. Mindestsatz.

Wir wollten untersuchen, wie viele Binärdateien in den betrachteten Distributionen durch diese und drei weitere Methoden geschützt sind:

• Der nicht ausführbare Bit (NX) verhindert die Ausführung in einem Bereich, der nicht ausführbar sein sollte, beispielsweise im Stack usw.
• RPATH/RUNPATH bezeichnet den Ausführungspfad, der vom dynamischen Loader verwendet wird, um die entsprechenden Bibliotheken zu finden. Der erste ist obligatorisch Für jedes moderne System: Das Fehlen davon ermöglicht es Angreifern, willkürlich den Payload in den Speicher zu schreiben und ihn unverändert auszuführen. Für den zweiten Fall helfen falsche Ausführungswegkonfigurationen, unsicheren Code einzufügen, was zu verschiedenen Problemen führen kann (zum Beispiel, Privilegieneskalation, sowie andere Probleme).
• Der Schutz vor Stack-Kollisionen bietet Schutz vor Angriffen, die den Stack in andere Speicherbereiche (wie den Heap) übertragen. Angesichts der jüngsten Exploits, die sich auf Heap-Kollisionsanfälligkeiten in systemd, hielten wir es für angebracht, diesen Mechanismus in unser Datenset aufzunehmen.

Also, ohne weitere Umschweife, kommen wir zu den Zahlen. Die Tabellen 4 und 5 enthalten eine Zusammenfassung der Analyse ausführbarer Dateien und Bibliotheken verschiedener Distributionen.

• Wie man erkennen kann, ist der NX-Schutz überall implementiert, mit wenigen Ausnahmen. Besonders auffällig ist der etwas niedrigere Einsatz in den Distributionen Ubuntu und Debian im Vergleich zu CentOS, RHEL und OpenSUSE.
• Stack-Canary sind vielerorts nicht vorhanden, insbesondere in Distributionen mit alten Kernen. Ein gewisser Fortschritt ist in den letzten Distributionen von CentOS, RHEL, Debian und Ubuntu zu beobachten.
• Mit Ausnahme von Debian und Ubuntu 18.04 ist die Unterstützung für PIE in den meisten Distributionen schlecht.
• Der Schutz vor Stack-Kollisionen ist in OpenSUSE, CentOS 7 und RHEL 7 schwach implementiert und praktisch nicht vorhanden in den anderen.
• Alle Distributionen mit modernen Kernen haben eine gewisse Unterstützung für RELRO, wobei Ubuntu 18.04 an der Spitze steht, gefolgt von Debian.

Wie bereits erwähnt, sind die Metriken in dieser Tabelle Durchschnittswerte über alle Versionen der Binärdatei. Betrachtet man nur die letzten Versionen der Dateien, werden die Zahlen anders sein (zum Beispiel siehe Fortschritt von Debian bei der Einführung von PIE). Außerdem prüfen die meisten Distributionen bei der Statistikberechnung in der Regel nur den Schutz einiger Funktionen im Binärcode, während unsere Analyse den tatsächlichen Prozentsatz der gehärteten Funktionen angibt. Daher, wenn im Binärcode 5 von 50 Funktionen geschützt sind, geben wir ihm eine Bewertung von 0,1, was 10% gehärtete Funktionen entspricht.

Tabelle 4. Schutzmerkmale für ausführbare Dateien, die in Abb. 3 gezeigt werden (Umsetzung der entsprechenden Funktionen in Prozent der Gesamtzahl der ausführbaren Dateien)

Tabelle 5. Eigenschaften des Schutzes für Bibliotheken, die in Abb. 3 gezeigt werden (Implementierung der entsprechenden Funktionen in Prozent der Gesamtzahl der Bibliotheken)

Gibt es Fortschritt? Definitiv: Das zeigt sich in der Statistik zu einzelnen Distributionen (zum Beispiel, Debian), sowie in den oben genannten Tabellen. Als Beispiel wird in Abb. 6 die Implementierung von Schutzmechanismen in drei aufeinanderfolgenden Ubuntu LTS 5 Distributionen gezeigt (wir haben die Statistiken zum Schutz vor Stack-Kollisionen ausgeschlossen). Wir stellen fest, dass von Version zu Version immer mehr Dateien Stack-Canaries unterstützen und außerdem zunehmend mehr Binärdateien mit umfassendem RELRO-Schutz geliefert werden.

Abb. 6

Leider verfügen einige ausführbare Dateien in verschiedenen Distributionen nach wie vor über keinen der oben genannten Schutzmechanismen. Wenn man sich beispielsweise Ubuntu 18.04 anschaut, fallen die Binärdatei ngetty (Ersatz für getty), die Shells mksh und lksh, der Interpreter picolisp sowie die Pakete nvidia-cuda-toolkit (ein beliebtes Paket für GPU-beschleunigte Anwendungen wie Machine-Learning-Frameworks) und klibc-utils auf. Ebenso werden die Binärdatei mandos-client (ein Verwaltungstool, das automatisch Maschinen mit verschlüsselten Dateisystemen neu starten kann) und der rsh-redone-client (eine Neuimplementierung von rsh und rlogin) ohne NX-Schutz geliefert, obwohl sie SUID-Rechte haben. Darüber hinaus fehlen in mehreren SUID-Binärdateien grundlegende Schutzmaßnahmen wie Stack-Canaries (zum Beispiel die Binärdatei Xorg.wrap aus dem Xorg-Paket).

Zusammenfassung und abschließende Anmerkungen

In diesem Artikel haben wir mehrere Sicherheitsmerkmale moderner Linux-Distributionen hervorgehoben. Die Analyse hat gezeigt, dass in der neuesten Version von Ubuntu LTS (18.04) im Durchschnitt der stärkste Schutz auf Betriebssystem- und Anwendungsebene unter den Distributionen mit relativ neuen Kernen implementiert ist, wie z.B. Ubuntu 14.04, 12.04 und Debian 9. Die betrachteten Distributionen CentOS, RHEL und OpenSUSE bieten in unserem Datensatz standardmäßig ein dichteres Paketangebot, und die neuesten Versionen (CentOS und RHEL) weisen einen höheren Implementierungsanteil für Stack-Kollision-Schutz im Vergleich zu Debians Wettbewerbern (Debian und Ubuntu) auf. Beim Vergleich der Versionen CentOS und RedHat stellen wir fest, dass es von Version 6 zu 7 erhebliche Verbesserungen bei der Implementierung von Stack-Cookies und RELRO gibt, aber insgesamt enthält CentOS mehr Funktionen als RHEL. Insgesamt sollten alle Distributionen der PIE-Schutz (Position Independent Executable) besondere Aufmerksamkeit schenken, der, mit Ausnahme von Debian 9 und Ubuntu 18.04, in weniger als 10 % der Binärdateien unseres Datensatzes implementiert ist.

Abschließend ist zu beachten: Obwohl wir die Untersuchung manuell durchgeführt haben, gibt es zahlreiche Sicherheitswerkzeuge (z.B. Lynis, Tiger, Hubble), die Analysen durchführen und helfen, unsichere Konfigurationen zu vermeiden. Leider garantiert selbst ein starker Schutz in angemessenen Konfigurationen nicht die Abwesenheit von Exploits. Deshalb sind wir fest davon überzeugt, dass es von entscheidender Bedeutung ist, zuverlässiges Monitoring und Echtzeit-Angriffsschutz sicherzustellen, dabei den Fokus auf Ausbeutungsmuster zu richten und diese zu verhindern.

Quelle: habr.com