TL; DR . In diesem Artikel untersuchen wir Härtungsschemata, die bei fünf gängigen Linux-Distributionen sofort funktionieren. Für jede haben wir die Standard-Kernel-Konfiguration übernommen, alle Pakete heruntergeladen und die Schutzschemata in den angehängten Binärdateien analysiert. Wir betrachten die Distributionen von 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 Stapelkanarien und positionsunabhängiger Code noch nicht von allen verwendet werden. Für Compiler ist die Situation noch schlimmer, wenn es um den Schutz vor Schwachstellen wie Stack Clash geht, die im Januar nach der Veröffentlichung von Schwachstelleninformationen in systemd ins Rampenlicht gerückt sind . Aber nicht alles ist so hoffnungslos. In einem wesentlichen Teil der Binärdateien sind grundlegende Schutzmethoden implementiert, und ihre Anzahl wächst von Version zu Version.

Die Überprüfung ergab, dass die meisten Schutzmethoden in Ubuntu 18.04 auf Betriebssystem- und Anwendungsebene implementiert sind, gefolgt von Debian 9. Andererseits sind in OpenSUSE 12.4, CentOS 7 und RHEL 7 auch grundlegende Schutzschemata implementiert, und der Schutz vor Stapelkollisionen wird noch weiter angewendet. mit einer viel dichteren Menge von Paketen standardmäßig.

Einführung

Es ist schwierig, qualitativ hochwertige Software bereitzustellen. Trotz der großen Anzahl fortschrittlicher Tools für die statische und dynamische Analyse von Code zur Laufzeit sowie der erheblichen Fortschritte bei der Entwicklung von Compilern und Programmiersprachen leidet moderne Software immer noch an Schwachstellen, die von Cyberkriminellen ständig ausgenutzt werden. In Ökosystemen mit Legacy-Code ist die Situation noch schlimmer. In solchen Fällen stehen wir nicht nur vor dem ewigen Problem, mögliche ausgenutzte Fehler zu finden, sondern sind auch durch starre Abwärtskompatibilitäts-Frameworks eingeschränkt, die häufig die Aufrechterhaltung eines begrenzten und noch schlimmeren anfälligen oder fehlerhaften Codes erfordern.

Hier kommen Härtungsmethoden ins Spiel. Wir können einige Arten von Fehlern nicht verhindern, aber wir können das Leben eines Angreifers erschweren und das Problem teilweise lösen, indem wir den Betrieb dieser Fehler verhindern oder verhindern. Ein solcher Schutz wird in allen modernen Betriebssystemen verwendet. Die Methoden unterscheiden sich jedoch stark in Komplexität, Effizienz und Leistung: von Stapelkanarien und ASLR bis hin zu vollwertigen CFI- und ROP- Schutzmaßnahmen. In diesem Artikel werden wir untersuchen, welche Schutzmethoden in den gängigsten Linux-Distributionen in der Standardkonfiguration verwendet werden, und die Eigenschaften von Binärdateien untersuchen, 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. In der Regel liefern sie Statistiken über die Gesamtzahl der Schwachstellendatensätze wie CVE (Common Vulnerability and Exposures), die aus der National Vulnerability Database (NVD) von NIST und anderen Quellen stammen. Anschließend werden diese Anwendungen oder Betriebssysteme nach der Anzahl der CVEs eingestuft. Obwohl CVEs sehr nützlich sind, um Probleme zu verfolgen und Anbieter und Benutzer zu informieren, sagen sie leider wenig über die tatsächliche Sicherheit von Software aus.

Betrachten Sie als Beispiel die Gesamtzahl der CVEs in den letzten vier Jahren für den Linux-Kernel und die fünf beliebtesten Serverdistributionen Ubuntu, Debian, Red Hat Enterprise Linux und OpenSUSE.


Abb. 1

Was sagt uns diese Tabelle? Bedeutet mehr CVE, dass eine Distribution anfälliger ist als eine andere? Es gibt keine Antwort. In diesem Artikel werden Sie beispielsweise sehen, dass Debian im Vergleich zu OpenSUSE oder RedHat Linux strengere Sicherheitsmechanismen implementiert und Debian dennoch über mehr CVE verfügt. Sie bedeuten jedoch nicht unbedingt eine geschwächte Sicherheit: Selbst ein CVE sagt nicht aus, ob die Sicherheitsanfälligkeit ausnutzbar ist . Die Schweregrade geben eine Vorstellung davon, wie wahrscheinlich die Ausnutzung der Sicherheitsanfälligkeit ist. Letztendlich hängt die Ausnutzbarkeit jedoch weitgehend vom Schutz der betroffenen Systeme 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 Schwachstellen aus. Der Unterschied in der CVE kann nicht durch die Qualität der Software erklärt werden, sondern durch andere Faktoren, einschließlich der für Tests zugewiesenen Ressourcen oder der Größe der Benutzerbasis. In unserem Beispiel können mehr Debian-CVEs einfach darauf hinweisen, dass Debian mehr Softwarepakete bereitstellt.

Natürlich bietet das CVE-System nützliche Informationen, mit denen Sie geeignete Schutzmaßnahmen erstellen können. Je besser wir die Gründe für das Scheitern des Programms verstehen, desto einfacher ist es, mögliche Betriebsmethoden zu identifizieren und geeignete Erkennungs- und Reaktionsmechanismen zu entwickeln. In Abb. Abbildung 2 zeigt die Schwachstellenkategorien für alle Distributionen in den letzten vier Jahren ( Quelle ). Es ist sofort ersichtlich, dass die meisten CVEs in die folgenden Kategorien fallen: Denial-of-Service (DoS), Codeausführung, Überlauf, Speicherbeschädigung, Informationsverlust (Exfiltration) und Eskalation von Berechtigungen. Obwohl viele CVEs mehrmals in verschiedenen Kategorien behandelt werden, bestehen im Allgemeinen von Jahr zu Jahr dieselben Probleme. Im nächsten Teil des Artikels werden wir die Verwendung verschiedener Schutzschemata bewerten, um die Ausnutzung dieser Sicherheitsanfälligkeiten zu verhindern.


Abb. 2

Die Aufgaben

In diesem Artikel möchten wir die folgenden Fragen beantworten:

• Was ist die Sicherheit verschiedener Linux-Distributionen? Welche Abwehrmechanismen gibt es in den Kernel- und User Space-Anwendungen?
  
• Wie hat sich die Einführung von Schutzmechanismen für verschiedene Distributionen im Laufe der Zeit verändert?
  
• Was sind die durchschnittlichen Abhängigkeiten von Paketen und Bibliotheken für jede Distribution?
  
• Welche Schutzfunktionen sind für jede Binärdatei implementiert?

Verteilungen auswählen

Es stellt sich heraus, dass es schwierig ist, genaue Statistiken zu Distributionsinstallationen zu finden, da in den meisten Fällen die Anzahl der Downloads nicht die Anzahl der tatsächlichen Installationen angibt. Unix-Varianten machen jedoch die Mehrheit der Serversysteme aus (69,2% auf Webservern, laut Statistiken von W3techs und anderen Quellen), und ihr Anteil wächst ständig. Daher haben wir uns für unsere Studie auf Distributionen konzentriert, die sofort auf der Google Cloud- Plattform verfügbar sind. Insbesondere haben wir folgendes Betriebssystem gewählt:

Distribution / Version	Der Kern	Bauen
OpenSUSE 12.4	4.12.14-95.3-Standard	# 1 SMP Mi Dez 5 06:00:48 UTC 2018 (63a8d29)
Debian 9 (strecken)	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 Di Jan 15 17:07:28 UTC 2019
CentOS 7	3.10.0-957.5.1.el7.x86_64	# 1 SMP Fr 1. Februar 14:54:57 UTC 2019
Red Hat Enterprise Linux Server 6.10 (Santiago)	2.6.32-754.9.1.el6.x86_64	# 1 SMP Mi 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 Do 15.11. 17:36:42 UTC 2018
Ubuntu 14.04 (Trusty Tahr)	4.4.0–140-generisch	# 166 ~ 04/14/1-Ubuntu SMP Sa Nov 17 01:52:43 UTC 20 ...
Ubuntu 16.04 (Xenial Xerus)	4,15,0-1026-gcp	# 27 ~ 16.04.1-Ubuntu SMP Fr 7. Dezember 09:59:47 UTC 2018
Ubuntu 18.04 (Bionic Beaver)	4,15,0-1026-gcp	# 27-Ubuntu SMP Do 6. Dezember 18:27:01 UTC 2018

Tabelle 1

Analyse

Wir werden die Standard-Kernel-Konfiguration sowie die Eigenschaften von Paketen untersuchen, die über den Paketmanager jedes Distributionspakets sofort verfügbar sind. Daher berücksichtigen wir nur Pakete aus den Standardspiegeln jeder Distribution und ignorieren Pakete aus instabilen Repositorys (z. B. "Testen" von Spiegeln in Debian) und Pakete von Drittanbietern (z. B. Nvidia-Pakete aus Standardspiegeln). Darüber hinaus berücksichtigen wir keine benutzerdefinierten Kernel-Kompilierungen oder erweiterten Sicherheitskonfigurationen.

Analyse der Kernelkonfiguration

Wir haben ein Analyseskript verwendet, das auf dem kostenlosen kconfig-Checker basiert. Wir betrachten die sofort einsatzbereiten Schutzoptionen für die genannten Distributionen und vergleichen sie mit der Liste aus dem Kernel Self-Defense Project (KSPP). In Tabelle 2 wird für jeden Konfigurationsparameter die gewünschte Einstellung beschrieben: Ein Häkchen steht für Verteilungen, die den KSSP-Empfehlungen entsprechen (eine Erläuterung der Begriffe finden Sie hier ; in zukünftigen Artikeln erfahren Sie, wie viele dieser Schutzmethoden aufgetreten sind und wie Sie das System in Abwesenheit hacken können).





Im Allgemeinen haben die neueren Kernel sofort strengere Einstellungen. Beispielsweise verfügen CentOS 6.10 und RHEL 6.10 auf dem 2.6.32-Kernel nicht über die meisten kritischen Funktionen, die in den neuen Kerneln implementiert sind, wie z. B. SMAP , starke RWX-Berechtigungen, Adress-Randomisierung oder copy2usr-Schutz. Es ist zu beachten, dass viele der Konfigurationsoptionen in der Tabelle in älteren Versionen des Kernels fehlen und in der Realität nicht anwendbar sind. Dies wird in der Tabelle immer noch als Mangel an angemessenem Schutz angegeben. Wenn der Konfigurationsparameter in dieser Version nicht verfügbar ist und dieser Parameter aus Sicherheitsgründen deaktiviert werden muss, wird dies als sinnvolle Konfiguration angesehen.

Ein weiterer Punkt bei der Interpretation der Ergebnisse: Einige Kernelkonfigurationen, die die Angriffsfläche vergrößern, können aus Sicherheitsgründen gleichzeitig verwendet werden. Solche Beispiele umfassen Uprobes und kprobes, Kernelmodule und BPF / eBPF. Wir empfehlen, die oben genannten Mechanismen zu verwenden, um einen echten Schutz zu bieten, da sie nicht trivial zu verwenden sind und bei ihrer Funktionsweise davon ausgegangen wird, dass böswillige Akteure bereits im System verankert sind. Wenn diese Optionen aktiviert sind, muss der Systemadministrator den Missbrauch aktiv überwachen.

Wenn wir die Einträge in Tabelle 2 weiter untersuchen, sehen wir, dass moderne Kernel verschiedene Optionen zum Schutz vor der Ausnutzung von Sicherheitslücken wie Informationslecks und Stapel- / Heap-Überlauf bieten. Wir stellen jedoch fest, dass selbst die neuesten populären Distributionen noch keinen ausgefeilteren Schutz (z. B. mit grsecurity- Patches) oder einen modernen Schutz vor Angriffen zur Wiederverwendung von Code (z. B. Kombination von Randomisierung mit R ^ X-Schemata für Code ) implementiert haben. Schlimmer noch, selbst diese fortgeschritteneren Abwehrmechanismen schützen nicht vor einer ganzen Reihe von Angriffen. Daher ist es für Systemadministratoren von entscheidender Bedeutung, intelligente Konfigurationen durch Lösungen zu ergänzen, mit denen Exploits zur Laufzeit erkannt und verhindert werden können.

Anwendungsanalyse

Es ist nicht überraschend, dass verschiedene Distributionen unterschiedliche Eigenschaften von Paketen, Kompilierungsoptionen, Bibliotheksabhängigkeiten usw. aufweisen. Unterschiede bestehen auch für verwandte Distributionen und Pakete mit einer geringen Anzahl von Abhängigkeiten (z. B. Coreutils in Ubuntu oder Debian). Um die Unterschiede zu bewerten, haben wir alle verfügbaren Pakete heruntergeladen, deren Inhalt extrahiert und die Binärdateien und Abhängigkeiten analysiert. Für jedes Paket haben wir die anderen Pakete verfolgt, von denen es abhängt, und für jede Binärdatei haben wir ihre Abhängigkeiten verfolgt. Dieser Abschnitt fasst die Ergebnisse zusammen.

Verteilungen

Insgesamt haben wir 361.556 Pakete für alle Distributionen heruntergeladen und nur Pakete aus den Standardspiegeln extrahiert. Wir haben Pakete ohne ausführbare ELF-Dateien wie Quellcodes, Schriftarten usw. ignoriert. Nach dem Filtern blieben 129 569 Pakete übrig, die insgesamt 584 457 Binärdateien enthielten. Die Verteilung von Paketen und Dateien auf Verteilungen ist in Abb. 2 dargestellt. 3.


Abb. 3

Möglicherweise stellen Sie fest, dass je moderner die Distribution, desto mehr Pakete und Binärdateien enthalten sind, was logisch ist. Gleichzeitig enthalten Ubuntu- und Debian-Pakete viel mehr Binärdateien (sowohl ausführbare als auch dynamische Module und Bibliotheken) als CentOS, SUSE und RHEL, was sich möglicherweise auf die Angriffsfläche von Ubuntu und Debian auswirkt (es sollte beachtet werden, dass die Zahlen alle Binärdateien aller Versionen widerspiegeln Paket, dh einige Dateien werden mehrmals analysiert). Dies ist besonders wichtig, wenn Sie die Abhängigkeiten zwischen Paketen berücksichtigen. Daher kann eine Sicherheitsanfälligkeit in der Binärdatei eines einzelnen Pakets viele Teile des Ökosystems betreffen, ebenso wie eine anfällige Bibliothek alle Binärdateien betreffen kann, die sie importieren. Betrachten wir als Referenz die Verteilung der Anzahl der Abhängigkeiten zwischen Paketen in verschiedenen Betriebssystemen:


Abb. 4

In fast allen Distributionen weisen 60% der Pakete mindestens 10 Abhängigkeiten auf. Darüber hinaus weisen einige Pakete mehr Abhängigkeiten auf (über 100). Gleiches gilt für inverse Paketabhängigkeiten: Wie erwartet werden mehrere Pakete von vielen anderen Paketen in der Distribution verwendet, sodass Schwachstellen in diesen wenigen Favoriten ein hohes Risiko darstellen. In der folgenden Tabelle sind beispielsweise 20 Pakete mit der maximalen Anzahl inverser Abhängigkeiten in SLES, Centos 7, Debian 9 und Ubuntu 18.04 aufgeführt (jedes Feld gibt das Paket und die Anzahl der inversen Abhängigkeiten an).


Tabelle 3

Eine interessante Tatsache. Obwohl alle analysierten Betriebssysteme für die x86_64-Architektur erstellt wurden, während die meisten Pakete die Architektur als x86_64 und x86 definiert haben, enthalten Pakete häufig Binärdateien für andere Architekturen, wie in Abb. 1 dargestellt. 5.


Abb. 5

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

Binärschutzstatistik

Als absolutes Minimum müssen Sie die grundlegenden Schutzoptionen für vorhandene Binärdateien studieren. Einige Linux-Distributionen enthalten Skripte, die solche Überprüfungen durchführen. Zum Beispiel gibt es in Debian / Ubuntu ein solches Skript. Hier ist ein Beispiel seiner Arbeit:

$ hardening-check $(which docker) /usr/bin/docker: Position Independent Executable: yes Stack protected: yes Fortify Source functions: no, only unprotected functions found! Read-only relocations: yes Immediate binding: yes 

Das Skript überprüft fünf Schutzfunktionen :

• Position Independent Executable (PIE): Gibt an, ob der Programmtextabschnitt im Speicher verschoben werden kann, um eine Randomisierung zu erreichen, wenn ASLR im Kernel aktiviert ist.
  
• Stapelgeschützt: Gibt an, ob Stapelkanarien zum Schutz vor Stapelkollisionsangriffen enthalten sind.
  
• Quelle verstärken: Gibt an, ob unsichere Funktionen (z. B. strcpy) durch ihre sichereren Gegenstücke ersetzt werden und in der Laufzeit überprüfte Aufrufe durch ihre nicht verifizierten Gegenstücke (z. B. memcpy anstelle von __memcpy_chk) ersetzt werden.
  
• Schreibgeschützte Verschiebungen (RELRO): Gibt an, ob die Einträge in der Bewegungstabelle als schreibgeschützt markiert sind, wenn sie vor Beginn der Ausführung funktioniert haben.
  
• Sofortige Bindung: Gibt an, ob der Laufzeit-Linker alle Bewegungen vor dem Starten des Programms zulässt (dies entspricht einer vollständigen RELRO).

Reichen die oben genannten Mechanismen aus? Leider gibt es keine. Es sind Möglichkeiten bekannt, alle oben genannten Verteidigungen zu umgehen. Je strenger die Verteidigung, desto höher die Messlatte für den Angreifer. Beispielsweise sind RELRO-Problemumgehungen schwieriger anzuwenden, wenn PIE und sofortige Bindung wirksam sind. Ebenso erfordert eine vollständige ASLR zusätzliche Arbeit, um einen funktionierenden Exploit zu erstellen. Anspruchsvolle Angreifer sind jedoch bereit, solche Abwehrmaßnahmen zu ergreifen: Ihre Abwesenheit beschleunigt das Hacken wesentlich. Daher ist es unbedingt erforderlich, dass diese Maßnahmen als das notwendige Minimum angesehen werden .

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

• Ein nicht ausführbares Bit ( NX ) verhindert die Ausführung in Bereichen, die nicht ausführbar sein sollten, z. B. in einem Stapelheap usw.
• RPATH / RUNPATH gibt den Ausführungspfad an, mit dem der dynamische Loader die entsprechenden Bibliotheken findet. Das erste ist für jedes moderne System obligatorisch : Durch seine Abwesenheit können Angreifer die Nutzdaten willkürlich in den Speicher schreiben und so ausführen, wie sie sind. Zum anderen helfen falsche Konfigurationen des Ausführungspfads bei der Einführung von nicht vertrauenswürdigem Code, was zu einer Reihe von Problemen führen kann (z. B. Eskalation von Berechtigungen sowie andere Probleme ).
• Der Stapelkollisionsschutz bietet Schutz vor Angriffen, die dazu führen, dass sich der Stapel mit anderen Speicherbereichen (z. B. einem Heap) überlappt. Angesichts der jüngsten Exploits, die Schwachstellen bei Heap-Kollisionen in systemd missbrauchen, fanden wir es angemessen, diesen Mechanismus in unseren Datensatz aufzunehmen.

Kommen wir also ohne weiteres zu den Zahlen. Die Tabellen 4 und 5 enthalten einen Überblick über die Analyse ausführbarer Dateien bzw. Bibliotheken verschiedener Distributionen.

• Wie Sie sehen, ist der NX-Schutz mit seltenen Ausnahmen überall implementiert. Insbesondere die geringere Verwendung in Ubuntu- und Debian-Distributionen ist im Vergleich zu CentOS, RHEL und OpenSUSE festzustellen.
  
• Stapelkanarien sind an vielen Orten nicht verfügbar, insbesondere in Distributionen mit alten Kerneln. Bei den jüngsten Distributionen von Centos, RHEL, Debian und Ubuntu wurden einige Fortschritte erzielt.
  
• Mit Ausnahme von Debian und Ubuntu 18.04 haben die meisten Distributionen eine schlechte PIE-Unterstützung.
  
• Der Stapelkollisionsschutz ist in OpenSUSE, Centos 7 und RHEL 7 schlecht implementiert und fehlt im Rest praktisch.
  
• Alle Distributionen mit modernen Kerneln unterstützen RELRO, wobei Ubuntu 18.04 die Nase vorn hat und Debian den zweiten Platz einnimmt.

Wie bereits erwähnt, sind die Metriken in dieser Tabelle über alle Versionen der Binärdatei durchschnittlich. Wenn Sie sich nur die neuesten Versionen von Dateien ansehen, sind die Zahlen unterschiedlich (siehe beispielsweise den Fortschritt von Debian bei der Implementierung von PIE ). Darüber hinaus überprüfen die meisten Verteilungen normalerweise bei der Berechnung von Statistiken den Schutz von nur wenigen Funktionen im Binärcode, und in unserer Analyse wird der wahre Prozentsatz der verstärkten Funktionen angegeben. Wenn also 5 von 50 Funktionen in der Binärdatei geschützt sind, geben wir ihr eine Bewertung von 0,1, was 10% der verstärkten Funktionen entspricht.


Tabelle 4. Schutzmerkmale für ausführbare Dateien gemäß Abb. 3 (Implementierung der entsprechenden Funktionen als Prozentsatz der Gesamtzahl der ausführbaren Dateien)


Tabelle 5. Schutzeigenschaften für die in Abb. 3 (Implementierung der entsprechenden Funktionen als Prozentsatz der Gesamtzahl der Bibliotheken)

Gibt es also Fortschritte? Es gibt definitiv: Es ist aus den Statistiken für einzelne Distributionen (zum Beispiel Debian ) sowie aus den obigen Tabellen ersichtlich. Als Beispiel in Abb. Abbildung 6 zeigt die Implementierung von Abwehrmechanismen in drei aufeinander folgenden Ubuntu LTS 5-Distributionen (wir haben die Statistik zum Schutz vor Stapelkollisionen weggelassen). Wir stellen fest, dass von Version zu Version immer mehr Dateien gestapelte Kanarienvögel unterstützen und dass nacheinander immer mehr Binärdateien über einen vollständigen RELRO-Schutz verfügen.


Abb. 6

Leider haben einige ausführbare Dateien in verschiedenen Distributionen immer noch keinen der oben genannten Schutzfunktionen. Wenn Sie sich beispielsweise Ubuntu 18.04 ansehen, sehen Sie die ngetty-Binärdatei (getty replace) sowie die mksh- und lksh-Shells, den Picolisp-Interpreter, die nvidia-cuda-toolkit-Pakete (ein beliebtes Paket für GPU-beschleunigte Anwendungen wie Frameworks für maschinelles Lernen) und klibc -utils. Ebenso werden die Mandos-Client-Binärdatei (ein Verwaltungstool, mit dem Sie Computer mit verschlüsselten Dateisystemen automatisch neu starten können) sowie der rsh-redone-client (Neuimplementierung von rsh und rlogin) ohne NX-Schutz bereitgestellt, obwohl sie über SUID-Rechte verfügen :(. Einige suid-Binärdateien verfügen nicht über einen grundlegenden Schutz, z. B. Stapelkanarien (z. B. die Binärdatei Xorg.wrap aus dem Xorg-Paket).

Zusammenfassung und abschließende Bemerkungen

In diesem Artikel haben wir einige Sicherheitsfunktionen moderner Linux-Distributionen hervorgehoben. Die Analyse ergab, dass die neueste Ubuntu LTS-Distribution (18.04) im Durchschnitt den stärksten Schutz auf Betriebssystem- und Anwendungsebene unter Distributionen mit relativ neuen Kerneln wie Ubuntu 14.04, 12.04 und Debian 9 implementiert hat. Die in unserem Kit diskutierten CentOS-, RHEL- und OpenSUSE-Distributionen Standardmäßig wird ein dichterer Satz von Paketen ausgegeben, und in neueren Versionen (CentOS und RHEL) haben sie einen höheren Prozentsatz an Stapelkollisionsschutz als Konkurrenten, die auf Debian (Debian und Ubuntu) basieren. Beim Vergleich der Versionen CentOS und RedHat stellen wir große Verbesserungen bei der Implementierung von Stack Canaries und RELRO von Version 6 auf 7 fest, aber CentOS bietet im Durchschnitt mehr Funktionen als RHEL. Im Allgemeinen sollten alle Distributionen dem PIE-Schutz besondere Aufmerksamkeit widmen, der mit Ausnahme von Debian 9 und Ubuntu 18.04 in weniger als 10% der Binärdateien aus unserem Datensatz implementiert ist.

Abschließend sei angemerkt: Obwohl wir die Recherche manuell durchgeführt haben, gibt es viele Sicherheitstools (z. B. Lynis , Tiger , Hubble ), die Analysen durchführen und dabei helfen, unsichere Konfigurationen zu vermeiden. Leider garantiert selbst ein starker Schutz in vernünftigen Konfigurationen nicht das Fehlen von Exploits. Aus diesem Grund sind wir fest davon überzeugt, dass es wichtig ist, Angriffe in Echtzeit zuverlässig zu überwachen und zu verhindern , sich auf Betriebsmodelle zu konzentrieren und diese zu verhindern.