TL; DR. In diesem Artikel untersuchen wir die Härtungsschemata, die auf fünf beliebten Linux-Distributionen sofort funktionieren. Für jedes haben wir die Standard-Kernel-Konfiguration übernommen, alle Pakete geladen und die Sicherheitsschemata in den angehängten Binärdateien analysiert. Berücksichtigt 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 das Stapeln von Kanarienvögeln und ortsunabhängiger Code noch nicht von allen übernommen werden. Noch schlimmer sieht es für Compiler aus, wenn es um den Schutz vor Schwachstellen wie Stack Clash geht, die im Januar nach der Veröffentlichung ins Rampenlicht gerieten . Aber nicht alles ist so aussichtslos. Eine beträchtliche Anzahl von Binärdateien implementiert grundlegende Schutzmethoden und ihre Zahl 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 implementieren OpenSUSE 12.4, CentOS 7 und RHEL 7 auch grundlegende Schutzschemata und Stapelkollisionsschutz wird noch häufiger mit einem viel dichteren Satz an Standardpaketen verwendet.
Einführung
Es ist schwierig, qualitativ hochwertige Software sicherzustellen. Trotz der Vielzahl fortschrittlicher Tools für die statische Codeanalyse und dynamische Laufzeitanalyse sowie erheblicher Fortschritte bei der Entwicklung von Compilern und Programmiersprachen weist moderne Software immer noch Schwachstellen auf, die ständig von Angreifern ausgenutzt werden. Noch schlimmer ist die Situation in Ökosystemen, die Legacy-Code enthalten. In solchen Fällen stehen wir nicht nur vor dem ewigen Problem, mögliche ausnutzbare Fehler zu finden, sondern sind auch durch strenge Abwärtskompatibilitäts-Frameworks eingeschränkt, die oft von uns verlangen, begrenzten oder noch schlimmer anfälligen oder fehlerhaften Code beizubehalten.
Hier kommen Methoden zum Schutz oder zur Härtung von Programmen ins Spiel. Wir können einige Arten von Fehlern nicht verhindern, aber wir können dem Angreifer das Leben erschweren und das Problem teilweise lösen, indem wir sie verhindern oder verhindern Betriebs diese Fehler. Ein solcher Schutz wird in allen modernen Betriebssystemen verwendet, die Methoden unterscheiden sich jedoch stark in Komplexität, Effizienz und Leistung: von Stack Canaries und bis hin zum Vollschutz и . In diesem Artikel schauen wir uns an, welche Schutzmethoden in den gängigsten Linux-Distributionen in der Standardkonfiguration verwendet werden, und untersuchen auch die Eigenschaften der Binärdateien, die über die Paketverwaltungssysteme jeder Distribution verteilt werden.
CVE und Sicherheit
Wir alle haben Artikel mit Titeln wie „Die anfälligsten Anwendungen des Jahres“ oder „Die anfälligsten Betriebssysteme“ gesehen. Normalerweise stellen sie Statistiken über die Gesamtzahl der Datensätze zu Schwachstellen bereit , erhalten von aus und andere Quellen. Anschließend werden diese Anwendungen oder Betriebssysteme nach der Anzahl der CVEs geordnet. 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 der 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, nämlich Ubuntu, Debian, Red Hat Enterprise Linux und OpenSUSE.
Fig. 1
Was sagt uns diese Grafik? Bedeutet eine höhere Anzahl an CVEs, dass eine Distribution anfälliger ist als eine andere? Keine Antwort. In diesem Artikel werden Sie beispielsweise sehen, dass Debian im Vergleich zu beispielsweise OpenSUSE oder RedHat Linux über stärkere Sicherheitsmechanismen verfügt, Debian jedoch über mehr CVEs verfügt. Sie bedeuten jedoch nicht zwangsläufig eine geschwächte Sicherheit: Selbst das Vorhandensein eines CVE weist nicht darauf hin, ob eine Schwachstelle vorliegt ausgebeutet. Schweregrade geben einen Hinweis darauf, wie wahrscheinlich Ausnutzen einer Schwachstelle, aber letztendlich hängt die Ausnutzbarkeit stark von den in den betroffenen Systemen vorhandenen Schutzmaßnahmen sowie den Ressourcen und Fähigkeiten der Angreifer ab. Darüber hinaus sagt das Fehlen von CVE-Berichten nichts über andere aus nicht registriert oder unbekannt Schwachstellen. Der Unterschied im CVE kann auf andere Faktoren als die Softwarequalität zurückzuführen sein, einschließlich der für Tests bereitgestellten Ressourcen oder der Größe der Benutzerbasis. In unserem Beispiel könnte die höhere Anzahl an CVEs von Debian einfach darauf hindeuten, dass Debian mehr Softwarepakete ausliefert.
Natürlich stellt das CVE-System nützliche Informationen bereit, die es Ihnen ermöglichen, entsprechende Schutzmaßnahmen zu erstellen. Je besser wir die Gründe für das Scheitern von Programmen verstehen, desto einfacher ist es, mögliche Ausbeutungsmethoden zu identifizieren und entsprechende Mechanismen zu entwickeln Erkennung und Reaktion. In Abb. 2 zeigt die Schwachstellenkategorien für alle Distributionen der letzten vier Jahre (). Es ist sofort klar, dass die meisten CVEs in die folgenden Kategorien fallen: Denial of Service (DoS), Codeausführung, Überlauf, Speicherbeschädigung, Informationsleck (Exfiltration) und Rechteausweitung. Obwohl viele CVEs mehrfach in verschiedenen Kategorien gezählt werden, bestehen im Allgemeinen Jahr für Jahr dieselben Probleme. Im nächsten Teil des Artikels werden wir den Einsatz verschiedener Schutzmaßnahmen bewerten, um die Ausnutzung dieser Schwachstellen zu verhindern.
Fig. 2
Aufgaben
In diesem Artikel wollen wir die folgenden Fragen beantworten:
- Wie hoch ist die Sicherheit verschiedener Linux-Distributionen? Welche Schutzmechanismen gibt es im Kernel und in User-Space-Anwendungen?
- Wie hat sich die Einführung von Sicherheitsmechanismen im Laufe der Zeit in den verschiedenen Distributionen verändert?
- Was sind die durchschnittlichen Abhängigkeiten von Paketen und Bibliotheken für jede Distribution?
- Welche Schutzmaßnahmen sind für jede Binärdatei implementiert?
Auswahl an Distributionen
Es stellt sich heraus, dass es schwierig ist, genaue Statistiken über Distributionsinstallationen zu finden, da die Anzahl der Downloads in den meisten Fällen keinen Rückschluss auf die Anzahl der tatsächlichen Installationen gibt. Allerdings machen Unix-Varianten den Großteil der Serversysteme aus (auf Webservern 69,2 %). W3techs und andere Quellen) und ihr Anteil wächst ständig. Daher haben wir uns bei unserer Recherche auf Distributionen konzentriert, die sofort auf der Plattform verfügbar sind . Insbesondere haben wir das folgende Betriebssystem ausgewählt:
Verteilung/Version
Kern
Bauen
OpenSUSE 12.4
4.12.14-95.3-Standard
#1 SMP Mi 5. Dezember 06:00:48 UTC 2018 (63a8d29)
Debian 9 (Stretch)
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018)
6.10 CentOS
2.6.32-754.10.1.el6.x86_64
#1 SMP Di, 15. Jan. 17:07:28 UTC 2019
7 CentOS
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 21. Nov. 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. Nov. 17:36:42 UTC 2018
Ubuntu 14.04 (Trusty Tahr)
4.4.0–140-generisch
#166~14.04.1-Ubuntu SMP Sa 17. Nov. 01:52:43 UTC 20…
Ubuntu 16.04 (XenialXerus)
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
Schauen wir uns die Standard-Kernel-Konfiguration sowie die Eigenschaften der Pakete an, die über den Paketmanager jeder Distribution standardmäßig verfügbar sind. Daher berücksichtigen wir nur Pakete aus den Standardspiegeln jeder Distribution und ignorieren Pakete aus instabilen Repositorys (z. B. Debian-Testspiegel) und Pakete von Drittanbietern (z. B. Nvidia-Pakete aus Standardspiegeln). Darüber hinaus berücksichtigen wir keine benutzerdefinierten Kernel-Kompilierungen oder sicherheitsgehärteten Konfigurationen.
Kernel-Konfigurationsanalyse
Wir haben ein Analyseskript basierend auf angewendet . Schauen wir uns die standardmäßigen Schutzparameter der genannten Distributionen an und vergleichen sie mit der Liste von (KSPP). Tabelle 2 beschreibt für jede Konfigurationsoption die gewünschte Einstellung: Das Kontrollkästchen gilt für Distributionen, die den KSSP-Empfehlungen entsprechen (eine Erläuterung der Begriffe finden Sie im Folgenden). ; In zukünftigen Artikeln werden wir erklären, wie viele dieser Sicherheitsmethoden entstanden sind und wie man ein System hackt, wenn sie nicht vorhanden sind.
Im Allgemeinen verfügen die neuen Kernel standardmäßig über strengere Einstellungen. Beispielsweise fehlen CentOS 6.10 und RHEL 6.10 auf dem 2.6.32-Kernel die meisten kritischen Funktionen, die in neueren Kerneln implementiert sind, wie z , strenge RWX-Berechtigungen, Adress-Randomisierung oder Copy2usr-Schutz. Zu beachten ist, dass viele der Konfigurationsmöglichkeiten in der Tabelle in älteren Versionen des Kernels nicht verfügbar sind und in der Realität nicht anwendbar sind – dies wird in der Tabelle immer noch als mangelnder Schutz angezeigt. Wenn eine Konfigurationsoption in einer bestimmten Version nicht vorhanden ist und aus Sicherheitsgründen die Deaktivierung dieser Option erforderlich ist, wird dies ebenfalls als sinnvolle Konfiguration angesehen.
Ein weiterer Punkt, der bei der Interpretation der Ergebnisse berücksichtigt werden sollte: Einige Kernel-Konfigurationen, die die Angriffsfläche erhöhen, können auch aus Sicherheitsgründen verwendet werden. Zu diesen Beispielen gehören uprobes und kprobes, Kernelmodule und BPF/eBPF. Wir empfehlen, die oben genannten Mechanismen zu nutzen, um einen echten Schutz zu bieten, da ihre Verwendung nicht trivial ist und ihre Ausnutzung davon ausgeht, dass böswillige Akteure bereits im System Fuß gefasst haben. Wenn diese Optionen jedoch aktiviert sind, muss der Systemadministrator aktiv auf Missbrauch überwachen.
Wenn wir uns die Einträge in Tabelle 2 genauer ansehen, sehen wir, dass moderne Kernel mehrere Optionen zum Schutz vor der Ausnutzung von Schwachstellen wie Informationslecks und Stack-/Heap-Überläufen bieten. Wir stellen jedoch fest, dass selbst die neuesten gängigen Distributionen noch keinen komplexeren Schutz (z. B. durch Patches) implementiert haben ) oder modernen Schutz vor Code-Reuse-Angriffen (z. B. ). Erschwerend kommt hinzu, dass selbst diese fortschrittlicheren Abwehrmaßnahmen nicht vor der gesamten Bandbreite an Angriffen schützen. Daher ist es für Systemadministratoren von entscheidender Bedeutung, intelligente Konfigurationen durch Lösungen zu ergänzen, die die Erkennung und Verhinderung von Exploits zur Laufzeit ermöglichen.
Anwendungsanalyse
Es überrascht nicht, dass verschiedene Distributionen unterschiedliche Paketeigenschaften, Kompilierungsoptionen, Bibliotheksabhängigkeiten usw. haben. Auch für gibt es Unterschiede Distributionen und Pakete mit wenigen Abhängigkeiten (z. B. Coreutils unter Ubuntu oder Debian). Um die Unterschiede zu bewerten, haben wir alle verfügbaren Pakete heruntergeladen, ihren 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. In diesem Abschnitt fassen wir die Schlussfolgerungen kurz zusammen.
Verteilungen
Insgesamt haben wir 361 Pakete für alle Distributionen heruntergeladen und dabei nur Pakete von Standardspiegeln extrahiert. Wir haben Pakete ohne ausführbare ELF-Dateien wie Quellen, Schriftarten usw. ignoriert. Nach dem Filtern blieben 556 Pakete übrig, die insgesamt 129 Binärdateien enthielten. Die Verteilung von Paketen und Dateien auf verschiedene Distributionen ist in Abb. dargestellt. 569.
Fig. 3
Möglicherweise stellen Sie fest, dass je moderner die Distribution ist, desto mehr Pakete und Binärdateien enthält sie, was logisch ist. Allerdings enthalten Ubuntu- und Debian-Pakete viel mehr Binärdateien (sowohl ausführbare Dateien 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 ist zu beachten, dass die Zahlen alle Binärdateien aller Versionen widerspiegeln). Paket, d. h. einige Dateien werden mehrmals analysiert). Dies ist besonders wichtig, wenn Sie Abhängigkeiten zwischen Paketen berücksichtigen. Daher kann eine Schwachstelle in einer einzelnen Paketbinärdatei viele Teile des Ökosystems betreffen, genauso wie eine anfällige Bibliothek alle Binärdateien betreffen kann, die sie importieren. Schauen wir uns zunächst die Verteilung der Anzahl der Abhängigkeiten zwischen Paketen in verschiedenen Betriebssystemen an:
Fig. 4
In fast allen Distributionen haben 60 % der Pakete mindestens 10 Abhängigkeiten. Darüber hinaus verfügen einige Pakete über eine deutlich größere Anzahl an Abhängigkeiten (mehr als 100). Das Gleiche gilt für umgekehrte Paketabhängigkeiten: Wie erwartet werden einige Pakete von vielen anderen Paketen in der Distribution verwendet, sodass Schwachstellen in diesen wenigen Paketen ein hohes Risiko darstellen. Als Beispiel listet die folgende Tabelle die 20 Pakete mit der maximalen Anzahl umgekehrter Abhängigkeiten in SLES, Centos 7, Debian 9 und Ubuntu 18.04 auf (jede Zelle gibt das Paket und die Anzahl umgekehrter Abhängigkeiten an).
Tabelle 3
Interessante Tatsache. Obwohl alle analysierten Betriebssysteme für die x86_64-Architektur erstellt wurden und die meisten Pakete die Architektur als x86_64 und x86 definiert haben, enthalten Pakete häufig Binärdateien für andere Architekturen, wie in Abbildung 5 dargestellt. XNUMX.
Fig. 5
Im nächsten Abschnitt werden wir uns mit den Eigenschaften der analysierten Binärdateien befassen.
Statistiken zum Schutz binärer Dateien
Als absolutes Minimum müssen Sie einen grundlegenden Satz an Sicherheitsoptionen für Ihre vorhandenen Binärdateien erkunden. Mehrere Linux-Distributionen enthalten Skripte, die solche Prüfungen durchführen. Debian/Ubuntu verfügt beispielsweise über ein solches Skript. Hier 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: yesDas Skript prüft fünf :
- Position Independent Executable (PIE): Gibt an, ob der Textabschnitt eines Programms im Speicher verschoben werden kann, um eine Randomisierung zu erreichen, wenn ASLR im Kernel aktiviert ist.
- Stack Protected: Ob Stack-Canaries zum Schutz vor Stack-Kollisionsangriffen aktiviert sind.
- Quelle verstärken: ob unsichere Funktionen (z. B. strcpy) durch ihre sichereren Gegenstücke ersetzt werden und zur Laufzeit überprüfte Aufrufe durch ihre ungeprüften Gegenstücke ersetzt werden (z. B. memcpy anstelle von __memcpy_chk).
- Schreibgeschützte Verschiebungen (RELRO): Gibt an, ob Verschiebungstabelleneinträge als schreibgeschützt markiert sind, wenn sie vor Beginn der Ausführung ausgelöst werden.
- Sofortige Bindung: Ob der Laufzeitlinker alle Bewegungen zulässt, bevor die Programmausführung beginnt (dies entspricht einem vollständigen RELRO).
Sind die oben genannten Mechanismen ausreichend? Leider gibt es keine. Es gibt bekannte Möglichkeiten, alle oben genannten Verteidigungen zu umgehen, aber je härter die Verteidigung, desto höher ist die Messlatte für den Angreifer. Zum Beispiel, schwieriger anzuwenden, wenn PIE und sofortige Bindung in Kraft sind. Ebenso erfordert die vollständige ASLR zusätzliche Arbeit, um einen funktionierenden Exploit zu erstellen. Erfahrene Angreifer sind jedoch bereits auf solche Schutzmaßnahmen vorbereitet: Ihr Fehlen wird den Hack erheblich beschleunigen. Daher ist es wichtig, dass diese Maßnahmen als notwendig erachtet werden Minimum.
Wir wollten untersuchen, wie viele Binärdateien in den betreffenden Distributionen durch diese und drei weitere Methoden geschützt sind:
- Nicht ausführbares Bit () verhindert die Ausführung in jeder Region, die nicht ausführbar sein sollte, wie z. B. im Stack-Heap usw.
- bezeichnet den Ausführungspfad, den der dynamische Loader verwendet, um passende Bibliotheken zu finden. Der erste ist obligatorisch für jedes moderne System: Seine Abwesenheit ermöglicht es Angreifern, die Nutzdaten willkürlich in den Speicher zu schreiben und sie so auszuführen, wie sie sind. Zweitens tragen falsche Konfigurationen des Ausführungspfads dazu bei, unzuverlässigen Code einzuführen, der zu einer Reihe von Problemen führen kann (z. B. , und auch ).
- Der Stack-Kollisionsschutz bietet Schutz vor Angriffen, die dazu führen, dass der Stack andere Bereiche des Speichers (z. B. den Heap) überlappt. Angesichts der jüngsten Missbrauchstaten hielten wir es für angemessen, diesen Mechanismus in unseren Datensatz aufzunehmen.
Kommen wir also ohne weitere Umschweife zu den Zahlen. Die Tabellen 4 und 5 enthalten jeweils eine Zusammenfassung der Analyse ausführbarer Dateien und Bibliotheken verschiedener Distributionen.
- Wie Sie sehen, ist der NX-Schutz bis auf wenige Ausnahmen überall implementiert. Besonders hervorzuheben ist die etwas geringere Verwendung in Ubuntu- und Debian-Distributionen im Vergleich zu CentOS, RHEL und OpenSUSE.
- Stack-Canaries fehlen vielerorts, insbesondere in Distributionen mit älteren Kerneln. Bei den neuesten Distributionen von Centos, RHEL, Debian und Ubuntu sind einige Fortschritte zu erkennen.
- Mit Ausnahme von Debian und Ubuntu 18.04 verfügen die meisten Distributionen über eine schlechte PIE-Unterstützung.
- Der Stapelkollisionsschutz ist in OpenSUSE, Centos 7 und RHEL 7 schwach und in anderen praktisch nicht vorhanden.
- Alle Distributionen mit modernen Kerneln unterstützen RELRO in gewissem Umfang, wobei Ubuntu 18.04 an der Spitze steht und Debian an zweiter Stelle steht.
Wie bereits erwähnt, handelt es sich bei den Metriken in dieser Tabelle um den Durchschnitt für alle Versionen der Binärdatei. Wenn Sie sich nur die neuesten Dateiversionen ansehen, werden die Zahlen unterschiedlich sein (siehe zum Beispiel ). Darüber hinaus testen die meisten Distributionen bei der Berechnung von Statistiken normalerweise nur die Sicherheit einiger weniger Funktionen in der Binärdatei. Unsere Analyse zeigt jedoch den tatsächlichen Prozentsatz der Funktionen, die gehärtet sind. Wenn also 5 von 50 Funktionen in einer Binärdatei geschützt sind, geben wir ihr einen Wert von 0,1, was einer Verstärkung von 10 % der Funktionen entspricht.
Tabelle 4. Sicherheitsmerkmale für die in Abb. gezeigten ausführbaren Dateien. 3 (Implementierung relevanter Funktionen in Prozent der Gesamtzahl der ausführbaren Dateien)
Tabelle 5. Sicherheitsmerkmale für die in Abb. gezeigten Bibliotheken. 3 (Umsetzung relevanter Funktionen in Prozent der Gesamtzahl der Bibliotheken)
Gibt es also Fortschritte? Ja, das ist auf jeden Fall der Fall: Dies lässt sich anhand der Statistiken zu den einzelnen Verteilungen (z. B. ), sowie aus den obigen Tabellen. Als Beispiel in Abb. Abbildung 6 zeigt die Implementierung von Schutzmechanismen in drei aufeinanderfolgenden Distributionen von Ubuntu LTS 5 (wir haben die Statistiken zum Stapelkollisionsschutz weggelassen). Wir stellen fest, dass von Version zu Version immer mehr Dateien Stack-Canaries unterstützen und auch immer mehr Binärdateien mit vollständigem RELRO-Schutz ausgeliefert werden.
Fig. 6
Leider verfügen einige ausführbare Dateien in verschiedenen Distributionen immer noch nicht über einen der oben genannten Schutzmaßnahmen. Wenn Sie sich beispielsweise Ubuntu 18.04 ansehen, werden Sie die Binärdatei ngetty (einen Getty-Ersatz) sowie die Shells mksh und lksh, den Picolisp-Interpreter und die Pakete nvidia-cuda-toolkit (ein beliebtes Paket für GPU-beschleunigte Anwendungen) bemerken wie Frameworks für maschinelles Lernen) und klibc -utils. Ebenso werden die mandos-client-Binärdatei (ein Verwaltungstool, mit dem Sie Maschinen mit verschlüsselten Dateisystemen automatisch neu starten können) sowie rsh-redone-client (eine Neuimplementierung von rsh und rlogin) ohne NX-Schutz ausgeliefert, obwohl sie über SUID-Rechte verfügen: (Außerdem mangelt es mehreren suid-Binärdateien an grundlegendem Schutz wie Stack-Canaries (z. B. der Xorg.wrap-Binärdatei aus dem Xorg-Paket).
Zusammenfassung und Schlussbemerkungen
In diesem Artikel haben wir mehrere 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. Die untersuchten Distributionen CentOS, RHEL und OpenSUSE in unserem Satz erzeugt standardmäßig einen dichteren Satz an Paketen und verfügt in den neuesten Versionen (CentOS und RHEL) über einen höheren Prozentsatz an Stapelkollisionsschutz im Vergleich zu Debian-basierten Konkurrenten (Debian und Ubuntu). Beim Vergleich der CentOS- und RedHat-Versionen stellen wir große Verbesserungen bei der Implementierung von Stack Canaries und RELRO von Version 6 bis 7 fest, aber im Durchschnitt sind in CentOS mehr Funktionen implementiert als in RHEL. Generell sollten alle Distributionen besonderes Augenmerk auf den PIE-Schutz legen, der mit Ausnahme von Debian 9 und Ubuntu 18.04 in weniger als 10 % der Binärdateien in unserem Datensatz implementiert ist.
Abschließend ist anzumerken, dass wir die Recherche zwar manuell durchgeführt haben, aber viele Sicherheitstools verfügbar sind (z. B. , , ), die Analysen durchführen und dabei helfen, unsichere Konfigurationen zu vermeiden. Leider ist selbst ein starker Schutz in vernünftigen Konfigurationen keine Garantie für die Abwesenheit von Exploits. Deshalb sind wir fest davon überzeugt, dass es wichtig ist, sicherzustellen , wobei der Schwerpunkt auf Ausbeutungsmustern und deren Verhinderung liegt.
Source: habr.com