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 Standardkernel-Konfiguration verwendet, alle Pakete geladen und die Schutzmechanismen in den eingebetteten Binärdateien 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.
Die Ergebnisse bestätigen, 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öffentlichung . Aber es ist nicht alles hoffnungslos. In einem erheblichen Teil der Binärdateien sind grundlegende Schutzmethoden implementiert, und ihre Anzahl steigt von Version zu Version.
Die Überprüfung hat ergeben, dass die meisten Schutzmaßnahmen 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.
Einführung
Die Gewährleistung hochwertiger Software ist eine Herausforderung. Trotz einer Vielzahl fortschrittlicher Werkzeuge zur statischen Codeanalyse und dynamischen Ausführungstests sowie erheblichem Fortschritt in der Compiler- und Programmierungsspracheentwicklung leidet moderne Software nach wie vor unter Schwachstellen, die von Angreifern ständig ausgenutzt werden. Die Situation ist besonders kritisch in Ökosystemen, die veralteten Code enthalten. In solchen Fällen stehen wir nicht nur vor dem ständigen Problem, potenzielle exploitable Fehler zu finden, sondern sind auch durch strenge Rückwärtskompatibilitätsanforderungen eingeschränkt, die oft erfordern, dass begrenzter, noch schlimmer, vulnerabler oder fehlerbehafteter Code erhalten bleibt.
Hier kommen Methoden zum Einsatz, die Schutz bieten oder Programme absichern (Hardening). Bei einigen Fehlertypen können wir nicht verhindern, dass sie auftreten, aber wir können es den Angreifern erschweren und das Problem teilweise lösen, indem wir es verhindern oder stören. Betriebsführung Solche Schutzmaßnahmen werden in allen modernen Betriebssystemen verwendet, unterscheiden sich jedoch stark in Bezug auf Komplexität, Effektivität und Leistung: von Stack-Canaries und bis hin zu vollständigen Sicherheitssystemen. und In diesem Artikel betrachten wir, welche Schutzmethoden in den beliebtesten Linux-Distributionen in der Standardkonfiguration verwendet werden, und untersuchen die Eigenschaften der Binärdateien, die über die Paketverwaltungssysteme jeder Distribution vertrieben werden.
CVE und Sicherheit
Wir alle haben Artikel mit Titeln wie „Die anfälligsten Anwendungen des Jahres“ oder „Die unsichersten Betriebssysteme“ gesehen. Normalerweise werden dort Statistiken über die Gesamtzahl der Einträge zu Schwachstellen vom Typ angeführt, die aus der ab und andere Quellen. In der Folge werden diese Anwendungen oder Betriebssysteme nach der Anzahl der CVE eingestuft. Leider sagen CVE, obwohl sie sehr nützlich sind, um Probleme nachzuverfolgen und Anbieter sowie Benutzer zu informieren, wenig über die tatsächliche Sicherheit der Software aus.
Um ein Beispiel zu nennen, betrachten wir die Gesamtzahl der CVE in den letzten vier Jahren für den Linux-Kernel sowie 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 von CVE, dass eine Distribution anfälliger 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äufig eine verringerte Sicherheit: Selbst das Vorhandensein von CVE sagt nicht aus, ob die Schwachstelle ausnutzbar. Schweregrade bieten eine Vorstellung davon, wie wahrscheinlich Die Ausnutzung einer Schwachstelle hängt letztlich stark von der vorhandenen Sicherheit 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. Die Unterschiede in den CVEs können durch verschiedene Faktoren erklärt werden, die nicht unbedingt mit der Softwarequalität zusammenhängen, einschließlich der Ressourcen, die für Tests bereitgestellt werden, oder der Größe der Benutzerbasis. In unserem Beispiel könnte eine höhere Anzahl von CVEs bei Debian einfach darauf hinweisen, dass Debian mehr Softwarepakete bereitstellt.
Natürlich bietet das CVE-System nützliche Informationen, die helfen, entsprechende Schutzmaßnahmen zu entwickeln. Je besser wir die Ursachen von Programmfehlern verstehen, desto einfacher ist es, mögliche Ausbeutungsarten zu identifizieren und geeignete Erkennungs- und Reaktionsmechanismen. Abbildung 2 zeigt die Kategorien von Schwachstellen für alle Distributionen in den letzten vier Jahren (). Es ist sofort ersichtlich, dass die meisten CVEs in folgende Kategorien fallen: Denial of Service (DoS), Codeausführung, Pufferüberlauf, Speicherbeschädigung, Datenexfiltration und Privilegieneskalation. Obwohl viele CVEs mehrfach in verschiedenen Kategorien aufgeführt sind, bestehen im Großen und Ganzen dieselben Probleme von Jahr zu Jahr. Im nächsten Abschnitt des Artikels werden wir die Verwendung verschiedener Schutzmechanismen zur Verhinderung der Ausnutzung der genannten Schwachstellen bewerten.
Abb. 2
Aufgaben
In diesem Artikel möchten wir die folgenden Fragen beantworten:
- Wie sicher sind verschiedene Linux-Distributionen? Welche Schutzmechanismen existieren im Kernel und in den Anwendungen des Benutzers?
- Wie hat sich die Akzeptanz von Schutzmechanismen im Laufe der Zeit für verschiedene Distributionen verändert?
- Was sind die durchschnittlichen Abhängigkeiten von Paketen und Bibliotheken jeder Distribution?
- Welche Schutzmaßnahmen sind für jede Binärdatei implementiert?
Auswahl der Distributionen
Es ist tatsächlich schwierig, genaue Statistiken zu Installationen von Distributionen zu finden, da in den meisten Fällen die Anzahl der Downloads nicht die tatsächlichen Installationen widerspiegelt. Dennoch machen Unix-basierte Systeme den Großteil der Serversysteme aus (auf Webservern 69,2% laut W3techs und anderen Quellen), und ihr Anteil wächst kontinuierlich. Für unsere Untersuchung konzentrierten wir uns auf Distributionen, die sofort auf der Plattform verfügbar sind. Dabei wählten wir die folgenden Betriebssysteme aus:
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 Standardkernel-Konfiguration sowie die Eigenschaften der Pakete, die jeder Distribution über den Paketmanager standardmäßig zur Verfügung stehen, untersuchen. So betrachten wir nur Pakete aus den Standardspiegeln jeder Distribution und ignorieren Pakete aus instabilen Repositories (zum Beispiel aus den 'testing'-Spiegeln in Debian) sowie Drittanbieter-Pakete (wie Nvidia-Pakete aus den Standardspiegeln). Zudem berücksichtigen wir keine benutzerdefinierten Kernel-Kompilationen oder Konfigurationen mit erhöhter Sicherheit.
Analyse der Kernel-Konfiguration
Wir haben ein Analyse-Skript basierend auf . Wir betrachten die standardmäßigen Sicherheitseinstellungen der genannten Distributionen und vergleichen sie mit der Liste von (KSPP). Für jede Konfigurationsoption beschreibt Tabelle 2 die gewünschte Einstellung: ein Haken steht für Distributionen, die den Empfehlungen des KSSP entsprechen (eine Erläuterung der Begriffe finden Sie unter ; in zukünftigen Artikeln werden wir erläutern, wie viele dieser Schutzmethoden entstanden sind und wie man ein System in ihrer Abwesenheit angreifen kann).
Insgesamt bieten die neuen Kernel strengere Voreinstellungen. Beispielsweise fehlen in CentOS 6.10 und RHEL 6.10, die auf Kernel 2.6.32 basieren, viele kritische Funktionen, die in neueren Kernen implementiert sind, wie , strenge RWX-Berechtigungen, Adressrandomisierung oder der Schutz von copy2usr. Es ist zu beachten, dass viele der in der Tabelle aufgeführten Konfigurationsoptionen in älteren Kernel-Versionen nicht verfügbar sind und in der Praxis nicht anwendbar sind – in der Tabelle wird dies dennoch als mangelnder Schutz aufgeführt. Ebenso wird ein Konfigurationsparameter, der in dieser Version nicht vorhanden ist und für die Sicherheit deaktiviert werden sollte, als sinnvolle Konfiguration angesehen.
Ein weiterer Aspekt bei der Interpretation der Ergebnisse ist, dass einige Kernel-Konfigurationen, die die Angriffsfläche vergrößern, gleichzeitig auch für die Sicherheit genutzt werden können. Beispiele hierfür sind uprobes und kprobes, Kernel-Module und BPF/eBPF. Unsere Empfehlung ist, die oben genannten Mechanismen für eine echte Absicherung zu verwenden, da sie nicht trivial zu handhaben sind und ihre Nutzung voraussetzt, dass bösartige Akteure bereits im System sind. Sind diese Optionen aktiviert, sollte der Systemadministrator aktiv auf Missbrauch achten.
Bei der weiteren Untersuchung der Einträge in Tabelle 2 sehen wir, dass moderne Kernels mehrere Optionen zum Schutz vor der Ausnutzung solcher Schwachstellen wie Informationsleckagen und Stack-/Heapüberläufen bieten. Allerdings stellen wir fest, dass selbst die neuesten beliebten Distributionen noch nicht umfassendere Schutzmaßnahmen (z. B. mit Patches) implementiert haben. ) oder modernen Schutz gegen Code-Reuse-Angriffe (z. B. ). Noch schlimmer ist, dass selbst diese ausgeklügelteren Schutzmaßnahmen nicht vor dem vollständigen Spektrum von Angriffen schützen. Daher ist es für Systemadministratoren von größter Bedeutung, angemessene Konfigurationen mit Lösungen zu ergänzen, die zur Erkennung und Verhinderung von Exploits zur Laufzeit beitragen.
Anwendungsanalyse
Es ist nicht verwunderlich, dass verschiedene Distributionen unterschiedliche Paketmerkmale, Kompilierungsoptionen, Abhängigkeiten von Bibliotheken usw. haben. Unterschiede bestehen sogar für Distributionen und Pakete 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 die Abhängigkeiten analysiert. Für jedes Paket haben wir andere Pakete verfolgt, von denen es abhängt, und für jede Binärdatei dessen Abhängigkeiten nachvollzogen. In diesem Abschnitt fassen wir die Ergebnisse zusammen.
Distributionen
Insgesamt haben wir 361.556 Pakete für alle Distributionen heruntergeladen, wobei wir nur Pakete von Standard-Servern extrahiert haben. Wir haben Pakete ohne ausführbare ELF-Dateien, wie z. B. Quellcodes, Schriftarten usw., ignoriert. Nach der Filterung blieben 129.569 Pakete mit insgesamt 584.457 Binärdateien übrig. Die Verteilung von Paketen und Dateien auf die Distributionen ist in Abb. 3 dargestellt.
Abb. 3
Es ist zu beachten, dass moderne Distributionen in der Regel eine größere Anzahl an Paketen und Binärdateien enthalten, was logisch ist. Dabei beinhalten 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 beeinflusst (zu beachten ist, dass die Zahlen alle Binärdateien aller Paketversionen widerspiegeln, also einige Dateien mehrfach analysiert werden). Dies ist besonders wichtig, wenn man die Abhängigkeiten zwischen den Paketen berücksichtigt. Eine Schwachstelle in der Binärdatei eines Pakets kann zahlreiche Teile des Ökosystems beeinflussen, da eine verwundbare Bibliothek alle Binärdateien beeinträchtigen kann, die sie importieren. Als Ausgangspunkt betrachten wir die Verteilung der Abhängigkeiten über die Pakete in verschiedenen Betriebssystemen:
Abb. 4
In den meisten Distributionen haben 60 % der Pakete mindestens 10 Abhängigkeiten. Zudem weisen einige Pakete erheblich mehr Abhängigkeiten auf (über 100). Dasselbe gilt für die Rückwärtsabhängigkeiten von Paketen: Wie zu erwarten, werden mehrere Pakete von vielen anderen Paketen in der Distribution genutzt, weshalb Sicherheitsanfälligkeiten in diesen wenigen ausgewählten Paketen ein hohes Risiko darstellen. In der folgenden Tabelle sind 20 Pakete mit der höchsten Anzahl von Rückwärtsabhängigkeiten in SLES, CentOS 7, Debian 9 und Ubuntu 18.04 aufgeführt (in jeder Zelle steht das Paket und die Anzahl der Rückwärtsabhängigkeiten).
Tabelle 3
Interessante Tatsache: Obwohl alle analysierten Betriebssysteme für die Architektur x86_64 erstellt wurden und die meisten Pakete die Architektur als x86_64 und x86 definiert haben, enthalten die Pakete oft Binärdateien für andere Architekturen, wie in Abb. 5 gezeigt.
Abb. 5
Im nächsten Abschnitt vertiefen wir uns in die Merkmale der analysierten Binärdateien.
Statistik zum Schutz 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. Beispielsweise gibt es in Debian/Ubuntu ein solches Skript. Hier ist ein Beispiel für seine Ausführung:
$ hardening-check $(which docker)
/usr/bin/docker:
Position Independent Executable: ja
Stack geschützt: ja
Fortify Source-Funktionen: nein, nur ungeschützte Funktionen gefunden!
Schreibgeschützte Relokation: ja
Sofortbindung: jaDas Skript überprüft fünf :
- Position Independent Executable (PIE): gibt an, ob der Textbereich des Programms im Speicher verschoben werden kann, um Zufälligkeit zu erreichen, wenn ASLR im Kernel aktiviert ist.
- Stack Protected: sind Stack-Kanäle aktiviert, um Angriffe auf den Stack zu verhindern.
- Fortify Source: werden unsichere Funktionen (z. B. strcpy) durch sicherere Alternativen ersetzt, während zur Laufzeit geprüfte Aufrufe durch ihre nicht geprüften Alternativen ersetzt werden (z. B. memcpy anstelle von __memcpy_chk).
- Schreibgeschützte Relokationen (RELRO): sind die Einträge in der Relokationstabelle als "nur lesbar" gekennzeichnet, wenn sie vor Beginn der Ausführung wirksam wurden.
- Sofortige Bindung: Erlaubt der Laufzeit-Linker alle Verschiebungen vor der Ausführung des Programms (was dem vollständigen RELRO entspricht).
Reichen die oben genannten Mechanismen aus? Leider nein. Es sind Methoden bekannt, die alle oben genannten Schutzmaßnahmen zu umgehen, aber je strenger der Schutz, desto höher ist die Hürde für den Angreifer. Zum Beispiel, schwieriger anzuwenden, wenn PIE und sofortige Bindung aktiv sind. Ebenso erfordert vollständiger ASLR zusätzliche Anstrengungen, um einen funktionierenden Exploit zu erstellen. Dennoch sind raffinierte Angreifer bereits darauf vorbereitet, solche Schutzmaßnahmen zu umgehen: Ihre Abwesenheit beschleunigt letztlich den Angriff. Daher ist es äußerst wichtig, diese Maßnahmen als notwendig zu betrachten. mindestens.
Wir wollten untersuchen, wie viele Binärdateien in den betrachteten Distributionen durch diese und drei weitere Methoden geschützt sind:
- Das Nicht-Ausführungs-Bitverhindert die Ausführung in jedem Bereich, der nicht ausführbar sein sollte, beispielsweise im Heap, Stack usw.
- bezeichnet den Ausführungspfad, den der dynamische Loader verwendet, um die entsprechenden Bibliotheken zu finden. Der erste ist obligatorisch für jedes moderne System: sein Fehlen ermöglicht Angreifern, beliebige Nutzlasten in den Speicher zu schreiben und diese unverändert auszuführen. Bei der zweiten Möglichkeit tragen falsche Ausführungspfadkonfigurationen zur Einführung unsicheren Codes bei, was zu einer Reihe von Problemen führen kann (zum Beispiel, , sowie ).
- Der Schutz vor Stack-Kollisionen bietet Schutz vor Angriffen, die dazu führen, dass der Stack in andere Speicherbereiche (zum Beispiel in den Heap) übergreift. Angesichts der jüngsten Exploits, die ausgenutzt haben , hielten wir es für sinnvoll, diesen Mechanismus in unser Datenset aufzunehmen.
Kommen wir ohne weitere Umschweife zu den Zahlen. Die Tabellen 4 und 5 enthalten eine Zusammenfassung der Analyse von ausführbaren Dateien und Bibliotheken verschiedener Distributionen.
- Wie zu erkennen ist, ist der NX-Schutz überall implementiert, mit wenigen Ausnahmen. Insbesondere fällt auf, dass dessen Nutzung in den Distributionen Ubuntu und Debian im Vergleich zu CentOS, RHEL und OpenSUSE etwas geringer ist.
- Stack Canary sind in vielen Distributionen rar, insbesondere in älteren Kernels. Einige Fortschritte sind in den neuesten Distributionen wie CentOS, RHEL, Debian und Ubuntu zu beobachten.
- Abgesehen von Debian und Ubuntu 18.04 bieten die meisten Distributionen eine unzureichende Unterstützung für PIE.
- Der Schutz vor Stack-Kollisionen ist in OpenSUSE, CentOS 7 und RHEL 7 schlecht implementiert und praktisch nicht vorhanden in anderen Distributionen.
- Alle Distributionen mit modernen Kernels bieten eine gewisse Unterstützung für RELRO, wobei Ubuntu 18.04 die Führung übernimmt und Debian den zweiten Platz einnimmt.
Wie bereits erwähnt, sind die Metriken in dieser Tabelle Durchschnittswerte über alle Versionen der Binärdatei. Wenn man sich nur die neuesten Versionen der Dateien anschaut, können die Zahlen anders ausfallen (siehe z.B. ). Darüber hinaus überprüfen die meisten Distributionen bei der Berechnung der Statistiken nur den Schutz einiger Funktionen im Binärcode, während in unserer Analyse der tatsächliche Prozentsatz der gesicherten Funktionen angegeben ist. Wenn also im Binärfile 5 von 50 Funktionen geschützt sind, weisen wir ihm eine Bewertung von 0,1 zu, was 10 % der gesicherten Funktionen entspricht.
Tabelle 4. Eigenschaften des Schutzes für ausführbare Dateien, die in Abb. 3 dargestellt sind (Implementierung der entsprechenden Funktionen in Prozent der Gesamtzahl an ausführbaren Dateien)
Tabelle 5. Eigenschaften des Schutzes für Bibliotheken, die in Abb. 3 dargestellt sind (Implementierung der entsprechenden Funktionen in Prozent der Gesamtzahl an Bibliotheken)
Gibt es Fortschritte? Definitiv: Dies zeigt sich in der Statistik zu einzelnen Distributionen (zum Beispiel, ), sowie in den oben genannten Tabellen. Als Beispiel zeigt Abb. 6 die Implementierung von Schutzmechanismen in drei aufeinanderfolgenden Ubuntu LTS 5 Distributionen (wir haben die Statistik zum Stack-Kollisionsschutz weggelassen). Wir stellen fest, dass von Version zu Version immer mehr Dateien Stack-Cookies unterstützen und zudem immer mehr Binärdateien mit vollständigem RELRO-Schutz geliefert werden.
Abb. 6
Leider verfügen einige ausführbare Dateien in verschiedenen Distributionen weiterhin über keinen der oben genannten Schutzmechanismen. Ein Beispiel ist der Binärdatei ngetty (eine Alternative zu getty) in Ubuntu 18.04, sowie die Shells mksh und lksh, der Interpreter picolisp, die Pakete nvidia-cuda-toolkit (ein beliebtes Paket für GPU-beschleunigte Anwendungen wie Machine-Learning-Frameworks) und klibc-utils. Zudem werden der Binärdatei mandos-client (ein Administrationswerkzeug, das das automatische Neustarten von Maschinen mit verschlüsselten Dateisystemen ermöglicht) und der rsh-redone-client (eine Neuimplementierung von rsh und rlogin) ohne NX-Schutz geliefert, obwohl sie SUID-Rechte besitzen :(. Darüber hinaus fehlt bei mehreren SUID-Binärdateien der grundlegende Schutz, wie z.B. Stack-Cookies (z.B. die Binärdatei Xorg.wrap aus dem Paket Xorg).
Zusammenfassung und abschließende Bemerkungen
In diesem Artikel haben wir mehrere Sicherheitsmerkmale moderner Linux-Distributionen hervorgehoben. Die Analyse hat gezeigt, dass die neueste LTS-Version von Ubuntu (18.04) im Durchschnitt den stärksten Schutz auf Betriebssystem- und Anwendungsebene unter den Distributionen mit relativ neuen Kernen bietet, wie zum Beispiel Ubuntu 14.04, 12.04 und Debian 9. Allerdings zeigen die betrachteten Distributionen CentOS, RHEL und OpenSUSE in unserem Datensatz standardmäßig ein dichteres Paketangebot und haben in den neuesten Versionen (CentOS und RHEL) einen höheren Prozentsatz an Implementierungen des Stack-Kollisionsschutzes im Vergleich zu Debian-basierten Mitbewerbern (Debian und Ubuntu). Beim Vergleich der Versionen von CentOS und RedHat stellen wir erhebliche Verbesserungen bei der Einführung von Stack Canaries und RELRO von Version 6 auf 7 fest; jedoch weist CentOS im Durchschnitt mehr Funktionen auf als RHEL. Insgesamt sollten alle Distributionen besonderen Wert auf den PIE-Schutz legen, der, mit Ausnahme von Debian 9 und Ubuntu 18.04, in weniger als 10% der Binärdateien unseres Datensatzes implementiert ist.
Abschließend sei erwähnt: Obwohl wir die Untersuchung manuell durchgeführt haben, gibt es viele Sicherheitswerkzeuge (z. B. , , ), 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 entscheidend ist, , indem wir uns auf Nutzungsmuster konzentrieren und diese verhindern.
Quelle: habr.com
