TL; DR. Dans cet article, nous explorons les schémas de renforcement qui fonctionnent immédiatement sur cinq distributions Linux populaires. Pour chacun, nous avons pris la configuration du noyau par défaut, chargé tous les packages et analysé les schémas de sécurité dans les binaires joints. Les distributions considérées sont OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 et 7, ainsi qu'Ubuntu 14.04, 12.04 et 18.04 LTS.
Les résultats confirment que même les schémas de base tels que l'empilement de canaris et le code indépendant de la position ne sont pas encore adoptés par tout le monde. La situation est encore pire pour les compilateurs lorsqu'il s'agit de se protéger contre des vulnérabilités telles que Stack Clash, qui a été mise en lumière en janvier après la publication. . Mais tout n’est pas si désespéré. Un nombre important de binaires implémentent des méthodes de protection de base, et leur nombre augmente de version en version.
L'examen a montré que le plus grand nombre de méthodes de protection est implémenté dans Ubuntu 18.04 au niveau du système d'exploitation et des applications, suivi par Debian 9. D'autre part, OpenSUSE 12.4, CentOS 7 et RHEL 7 implémentent également des schémas de protection de base et une protection contre les collisions de pile. est utilisé encore plus largement avec un ensemble beaucoup plus dense de packages par défaut.
introduction
Il est difficile de garantir un logiciel de haute qualité. Malgré le grand nombre d'outils avancés d'analyse statique du code et d'analyse dynamique de l'exécution, ainsi que les progrès significatifs dans le développement des compilateurs et des langages de programmation, les logiciels modernes souffrent toujours de vulnérabilités constamment exploitées par les attaquants. La situation est encore pire dans les écosystèmes qui incluent du code existant. Dans de tels cas, nous sommes non seulement confrontés à l’éternel problème de trouver d’éventuelles erreurs exploitables, mais nous sommes également limités par des cadres stricts de compatibilité ascendante, qui nous obligent souvent à conserver un code limité, voire pire, vulnérable ou bogué.
C’est là qu’interviennent les méthodes de protection ou de renforcement des programmes. Nous ne pouvons pas empêcher certains types d’erreurs, mais nous pouvons rendre la vie de l’attaquant plus difficile et résoudre partiellement le problème en empêchant ou en empêchant Exploitation ces erreurs. Une telle protection est utilisée dans tous les systèmes d'exploitation modernes, mais les méthodes diffèrent considérablement en termes de complexité, d'efficacité et de performances : des canaris de pile et à une protection complète и . Dans cet article, nous examinerons quelles méthodes de protection sont utilisées dans les distributions Linux les plus populaires dans la configuration par défaut, et examinerons également les propriétés des binaires distribués via les systèmes de gestion de packages de chaque distribution.
CVE et sécurité
Nous avons tous vu des articles portant des titres tels que « Les applications les plus vulnérables de l'année » ou « Les systèmes d'exploitation les plus vulnérables ». Habituellement, ils fournissent des statistiques sur le nombre total d'enregistrements concernant des vulnérabilités telles que , obtenu à partir de à partir de et d'autres sources. Par la suite, ces applications ou OS sont classés selon le nombre de CVE. Malheureusement, même si les CVE sont très utiles pour suivre les problèmes et informer les fournisseurs et les utilisateurs, ils en disent peu sur la sécurité réelle du logiciel.
À titre d'exemple, considérons le nombre total de CVE au cours des quatre dernières années pour le noyau Linux et les cinq distributions de serveurs les plus populaires, à savoir Ubuntu, Debian, Red Hat Enterprise Linux et OpenSUSE.
Fig. 1
Que nous dit ce graphique ? Un nombre plus élevé de CVE signifie-t-il qu’une distribution est plus vulnérable qu’une autre ? Pas de réponse. Par exemple, dans cet article, vous verrez que Debian dispose de mécanismes de sécurité plus solides que, par exemple, OpenSUSE ou RedHat Linux, et pourtant Debian a plus de CVE. Cependant, ils ne signifient pas nécessairement une sécurité affaiblie : même la présence d'un CVE n'indique pas si une vulnérabilité est présente. exploité. Les scores de gravité fournissent une indication de la façon dont probablement l'exploitation d'une vulnérabilité, mais en fin de compte, l'exploitabilité dépend fortement des protections présentes dans les systèmes concernés ainsi que des ressources et capacités des attaquants. De plus, l’absence de rapports CVE ne dit rien des autres non enregistré ou inconnu vulnérabilités. La différence de CVE peut être due à des facteurs autres que la qualité du logiciel, notamment les ressources allouées aux tests ou la taille de la base d'utilisateurs. Dans notre exemple, le nombre plus élevé de CVE de Debian peut simplement indiquer que Debian fournit davantage de paquets logiciels.
Bien entendu, le système CVE fournit des informations utiles qui permettent de créer des protections adaptées. Mieux nous comprenons les raisons de l’échec du programme, plus il est facile d’identifier les méthodes d’exploitation possibles et de développer des mécanismes appropriés. détection et réponse. En figue. 2 montre les catégories de vulnérabilités pour toutes les distributions au cours des quatre dernières années (). Il est immédiatement clair que la plupart des CVE entrent dans les catégories suivantes : déni de service (DoS), exécution de code, débordement, corruption de mémoire, fuite d'informations (exfiltration) et élévation de privilèges. Bien que de nombreux CVE soient comptabilisés plusieurs fois dans différentes catégories, en général, les mêmes problèmes persistent année après année. Dans la prochaine partie de l’article, nous évaluerons l’utilisation de différents schémas de protection pour empêcher l’exploitation de ces vulnérabilités.
Fig. 2
Tâches
Dans cet article, nous avons l’intention de répondre aux questions suivantes :
- Quelle est la sécurité des différentes distributions Linux ? Quels mécanismes de protection existent dans les applications du noyau et de l'espace utilisateur ?
- Comment l’adoption des mécanismes de sécurité a-t-elle évolué au fil du temps dans les distributions ?
- Quelles sont les dépendances moyennes des packages et des bibliothèques pour chaque distribution ?
- Quelles protections sont mises en œuvre pour chaque binaire ?
Sélection des distributions
Il s'avère qu'il est difficile de trouver des statistiques précises sur les installations de distribution, car dans la plupart des cas, le nombre de téléchargements n'indique pas le nombre d'installations réelles. Cependant, les variantes Unix constituent la majorité des systèmes de serveur (sur les serveurs Web 69,2 %, selon W3techs et autres sources), et leur part est en constante augmentation. Ainsi, pour nos recherches nous nous sommes concentrés sur les distributions disponibles prêtes à l'emploi sur la plateforme . Nous avons notamment sélectionné les OS suivants :
Distribution/version
noyau
Construire
OpenSUSE 12.4
4.12.14-95.3-par défaut
#1 SMP mercredi 5 décembre 06:00:48 UTC 2018 (63a8d29)
Debian 9 (étendue)
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018-10-27)
6.10 CentOS
2.6.32-754.10.1.el6.x86_64
#1 SMP mar. 15 janvier 17:07:28 UTC 2019
7 CentOS
3.10.0-957.5.1.el7.x86_64
#1 SMP ven. 1 février 14:54:57 UTC 2019
Serveur Red Hat Enterprise Linux 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP mercredi 21 novembre 15:08:21 HNE 2018
Serveur Red Hat Enterprise Linux 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP jeu. 15 novembre 17:36:42 UTC 2018
Ubuntu 14.04 (TrustyTahr)
4.4.0–140-générique
#166~14.04.1-Ubuntu SMP samedi 17 novembre 01:52:43 UTC 20…
Ubuntu 16.04 (Xenial Xérus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP vendredi 7 décembre 09:59:47 UTC 2018
Ubuntu 18.04 (Castor Bionic)
4.15.0–1026-gcp
#27-Ubuntu SMP jeu. 6 décembre 18:27:01 UTC 2018
Tableau 1
Analyse
Étudions la configuration par défaut du noyau, ainsi que les propriétés des packages disponibles via le gestionnaire de packages de chaque distribution prête à l'emploi. Ainsi, nous considérons uniquement les packages provenant des miroirs par défaut de chaque distribution, en ignorant les packages provenant de référentiels instables (tels que les miroirs de « test » Debian) et les packages tiers (tels que les packages Nvidia provenant de miroirs standards). De plus, nous ne prenons pas en compte les compilations de noyau personnalisées ou les configurations renforcées en matière de sécurité.
Analyse de la configuration du noyau
Nous avons appliqué un script d'analyse basé sur . Examinons les paramètres de protection prêts à l'emploi des distributions nommées et comparons-les avec la liste de (KSPP). Pour chaque option de configuration, le tableau 2 décrit le paramètre souhaité : la case à cocher concerne les distributions conformes aux recommandations KSSP (voir ci-dessous pour une explication des termes). ; Dans les prochains articles, nous expliquerons combien de ces méthodes de sécurité ont vu le jour et comment pirater un système en leur absence).
En général, les nouveaux noyaux ont des paramètres plus stricts par défaut. Par exemple, CentOS 6.10 et RHEL 6.10 sur le noyau 2.6.32 ne disposent pas de la plupart des fonctionnalités critiques implémentées dans les noyaux plus récents tels que , autorisations RWX strictes, randomisation des adresses ou protection copy2usr. Il convient de noter que de nombreuses options de configuration du tableau ne sont pas disponibles dans les anciennes versions du noyau et ne sont pas applicables dans la réalité - cela est toujours indiqué dans le tableau comme un manque de protection appropriée. De même, si une option de configuration n'est pas présente dans une version donnée et que la sécurité nécessite que cette option soit désactivée, cela est considéré comme une configuration raisonnable.
Autre point à considérer lors de l’interprétation des résultats : certaines configurations du noyau qui augmentent la surface d’attaque peuvent également être utilisées pour la sécurité. De tels exemples incluent les uprobes et les kprobes, les modules du noyau et les BPF/eBPF. Notre recommandation est d’utiliser les mécanismes ci-dessus pour assurer une réelle protection, car leur utilisation n’est pas triviale et leur exploitation suppose que des acteurs malveillants aient déjà pris pied dans le système. Mais si ces options sont activées, l'administrateur système doit surveiller activement les abus.
En examinant plus en détail les entrées du tableau 2, nous constatons que les noyaux modernes offrent plusieurs options de protection contre l'exploitation de vulnérabilités telles que les fuites d'informations et les débordements de pile/tas. Cependant, nous remarquons que même les distributions populaires les plus récentes n'ont pas encore implémenté de protection plus complexe (par exemple, avec des correctifs ) ou une protection moderne contre les attaques de réutilisation de code (par ex. ). Pire encore, même ces défenses plus avancées ne protègent pas contre toute la gamme des attaques. Il est donc essentiel que les administrateurs système complètent les configurations intelligentes avec des solutions offrant une détection et une prévention des exploits d'exécution.
Analyse des applications
Sans surprise, différentes distributions ont des caractéristiques de paquetage, des options de compilation, des dépendances de bibliothèque différentes, etc. Des différences existent même pour distributions et packages avec un petit nombre de dépendances (par exemple, coreutils sur Ubuntu ou Debian). Pour évaluer les différences, nous avons téléchargé tous les packages disponibles, extrait leur contenu et analysé les binaires et les dépendances. Pour chaque package, nous avons suivi les autres packages dont il dépend, et pour chaque binaire, nous avons suivi ses dépendances. Dans cette section, nous résumons brièvement les conclusions.
distributions
Au total, nous avons téléchargé 361 556 packages pour toutes les distributions, en extrayant uniquement les packages des miroirs par défaut. Nous avons ignoré les packages sans exécutables ELF, tels que les sources, les polices, etc. Après filtrage, il restait 129 569 packages, contenant un total de 584 457 binaires. La distribution des packages et des fichiers entre les distributions est illustrée à la Fig. 3.
Fig. 3
Vous remarquerez peut-être que plus la distribution est moderne, plus elle contient de packages et de binaires, ce qui est logique. Cependant, les packages Ubuntu et Debian incluent beaucoup plus de binaires (à la fois exécutables et modules et bibliothèques dynamiques) que CentOS, SUSE et RHEL, ce qui affecte potentiellement la surface d'attaque d'Ubuntu et Debian (il convient de noter que les chiffres reflètent tous les binaires de toutes les versions). package, c'est-à-dire que certains fichiers sont analysés plusieurs fois). Ceci est particulièrement important lorsque vous considérez les dépendances entre les packages. Ainsi, une vulnérabilité dans un seul paquet binaire peut affecter de nombreuses parties de l'écosystème, tout comme une bibliothèque vulnérable peut affecter tous les binaires qui l'importent. Pour commencer, examinons la répartition du nombre de dépendances entre les packages dans différents systèmes d'exploitation :
Fig. 4
Dans presque toutes les distributions, 60 % des packages ont au moins 10 dépendances. De plus, certains packages ont un nombre de dépendances nettement plus important (plus de 100). La même chose s'applique aux dépendances inversées des packages : comme prévu, quelques packages sont utilisés par de nombreux autres packages de la distribution, donc les vulnérabilités de ces quelques packages sélectionnés présentent un risque élevé. A titre d'exemple, le tableau suivant répertorie les 20 packages avec le nombre maximum de dépendances inverses dans SLES, Centos 7, Debian 9 et Ubuntu 18.04 (chaque cellule indique le package et le nombre de dépendances inverses).
Tableau 3
Fait intéressant. Bien que tous les systèmes d'exploitation analysés soient construits pour l'architecture x86_64 et que la plupart des packages aient l'architecture définie comme x86_64 et x86, les packages contiennent souvent des binaires pour d'autres architectures, comme le montre la figure 5. XNUMX.
Fig. 5
Dans la section suivante, nous approfondirons les caractéristiques des binaires analysés.
Statistiques de protection des fichiers binaires
Au minimum absolu, vous devez explorer un ensemble d’options de sécurité de base pour vos binaires existants. Plusieurs distributions Linux sont livrées avec des scripts qui effectuent de telles vérifications. Par exemple, Debian/Ubuntu possède un tel script. Voici un exemple de son travail :
$ 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: yesLe script en vérifie cinq :
- Position Independent Executable (PIE) : indique si la section de texte d'un programme peut être déplacée en mémoire pour obtenir une randomisation si ASLR est activé dans le noyau.
- Stack Protected : indique si les canaris de pile sont activés pour se protéger contre les attaques par collision de pile.
- Fortify Source : indique si les fonctions non sécurisées (par exemple, strcpy) sont remplacées par leurs homologues plus sécurisées et si les appels vérifiés au moment de l'exécution sont remplacés par leurs homologues non vérifiés (par exemple, memcpy au lieu de __memcpy_chk).
- Relocalisations en lecture seule (RELRO) : indique si les entrées de la table de relocalisation sont marquées en lecture seule si elles sont déclenchées avant le début de l'exécution.
- Liaison immédiate : indique si l'éditeur de liens d'exécution autorise tous les mouvements avant le début de l'exécution du programme (cela équivaut à un RELRO complet).
Les mécanismes ci-dessus sont-ils suffisants ? Malheureusement non. Il existe des moyens connus pour contourner toutes les défenses ci-dessus, mais plus la défense est solide, plus la barre est haute pour l'attaquant. Par exemple, plus difficile à appliquer si le PIE et la liaison immédiate sont en vigueur. De même, l'ASLR complet nécessite un travail supplémentaire pour créer un exploit fonctionnel. Cependant, les attaquants sophistiqués sont déjà prêts à affronter de telles protections : leur absence accélérera essentiellement le piratage. Il est donc essentiel que ces mesures soient considérées comme nécessaires minimum.
Nous voulions étudier combien de fichiers binaires dans les distributions en question sont protégés par ces méthodes et trois autres :
- Bit inexécutable () empêche l'exécution dans toute région qui ne devrait pas être exécutable, comme le tas de pile, etc.
- désigne le chemin d'exécution utilisé par le chargeur dynamique pour trouver les bibliothèques correspondantes. Le premier est obligatoire pour tout système moderne : son absence permet aux attaquants d’écrire arbitrairement la charge utile en mémoire et de l’exécuter telle quelle. Pour le second, des configurations incorrectes du chemin d'exécution contribuent à introduire un code peu fiable qui peut conduire à un certain nombre de problèmes (par ex. et ).
- La protection contre les collisions de pile offre une protection contre les attaques qui provoquent le chevauchement de la pile avec d'autres zones de mémoire (telles que le tas). Compte tenu des exploits récents abusant , nous avons estimé qu'il était approprié d'inclure ce mécanisme dans notre ensemble de données.
Alors, sans plus attendre, passons aux chiffres. Les tableaux 4 et 5 contiennent respectivement un résumé de l'analyse des fichiers exécutables et des bibliothèques de diverses distributions.
- Comme vous pouvez le constater, la protection NX est mise en œuvre partout, à de rares exceptions près. On peut notamment noter son utilisation légèrement inférieure dans les distributions Ubuntu et Debian par rapport à CentOS, RHEL et OpenSUSE.
- Les canaris de pile sont absents à de nombreux endroits, en particulier dans les distributions avec des noyaux plus anciens. Certains progrès sont constatés dans les dernières distributions de Centos, RHEL, Debian et Ubuntu.
- À l'exception de Debian et Ubuntu 18.04, la plupart des distributions ont un faible support PIE.
- La protection contre les collisions de pile est faible dans OpenSUSE, Centos 7 et RHEL 7, et pratiquement inexistante dans d'autres.
- Toutes les distributions dotées de noyaux modernes prennent en charge RELRO, avec Ubuntu 18.04 en tête et Debian en deuxième position.
Comme déjà mentionné, les métriques de ce tableau sont la moyenne de toutes les versions du fichier binaire. Si vous regardez uniquement les dernières versions des fichiers, les numéros seront différents (par exemple, voir ). De plus, la plupart des distributions ne testent généralement que la sécurité de quelques fonctions binaires lors du calcul des statistiques, mais notre analyse montre le véritable pourcentage de fonctions renforcées. Ainsi, si 5 fonctions sur 50 sont protégées dans un binaire, nous lui attribuerons une note de 0,1, ce qui correspond à 10 % des fonctions renforcées.
Tableau 4. Caractéristiques de sécurité pour les fichiers exécutables illustrés à la Fig. 3 (implémentation des fonctions pertinentes en pourcentage du nombre total de fichiers exécutables)
Tableau 5. Caractéristiques de sécurité pour les bibliothèques illustrées à la Fig. 3 (mise en œuvre des fonctions pertinentes en pourcentage du nombre total de bibliothèques)
Alors, y a-t-il des progrès ? Il y en a certainement : cela se voit dans les statistiques des distributions individuelles (par exemple, ), ainsi que des tableaux ci-dessus. A titre d'exemple sur la Fig. La figure 6 montre la mise en œuvre des mécanismes de protection dans trois distributions successives d'Ubuntu LTS 5 (nous avons omis les statistiques de protection contre les collisions de pile). Nous remarquons que de version en version, de plus en plus de fichiers prennent en charge les canaris de pile, et de plus en plus de binaires sont également livrés avec une protection RELRO complète.
Fig. 6
Malheureusement, un certain nombre de fichiers exécutables dans différentes distributions ne bénéficient toujours d'aucune des protections ci-dessus. Par exemple, en regardant Ubuntu 18.04, vous remarquerez le binaire ngetty (un remplacement de getty), ainsi que les shells mksh et lksh, l'interpréteur picolisp, les packages nvidia-cuda-toolkit (un package populaire pour les applications accélérées par GPU tels que les frameworks d'apprentissage automatique) et klibc -utils. De même, le binaire mandos-client (un outil d'administration qui permet de redémarrer automatiquement les machines avec des systèmes de fichiers cryptés) ainsi que rsh-redone-client (une réimplémentation de rsh et rlogin) sont livrés sans protection NX, bien qu'ils disposent des droits SUID : (. De plus, plusieurs binaires suid manquent de protection de base telle que les canaris de pile (par exemple, le binaire Xorg.wrap du package Xorg).
Résumé et remarques finales
Dans cet article, nous avons mis en évidence plusieurs fonctionnalités de sécurité des distributions Linux modernes. L'analyse a montré que la dernière distribution Ubuntu LTS (18.04) implémente, en moyenne, la protection la plus forte au niveau du système d'exploitation et des applications parmi les distributions dotées de noyaux relativement nouveaux, comme Ubuntu 14.04, 12.04 et Debian 9. Cependant, les distributions examinées CentOS, RHEL et OpenSUSE dans notre ensemble produit par défaut un ensemble de packages plus dense et dans les dernières versions (CentOS et RHEL), ils ont un pourcentage de protection contre les collisions de pile plus élevé que les concurrents basés sur Debian (Debian et Ubuntu). En comparant les versions CentOS et RedHat, nous remarquons de grandes améliorations dans l'implémentation de Stack Canaries et de RELRO des versions 6 à 7, mais en moyenne CentOS a plus de fonctionnalités implémentées que RHEL. En général, toutes les distributions doivent accorder une attention particulière à la protection PIE qui, à l'exception de Debian 9 et Ubuntu 18.04, est implémentée dans moins de 10 % des binaires de notre ensemble de données.
Enfin, il convient de noter que même si nous avons effectué la recherche manuellement, de nombreux outils de sécurité sont disponibles (par ex. , , ), qui effectuent des analyses et aident à éviter les configurations dangereuses. Malheureusement, même une protection forte dans des configurations raisonnables ne garantit pas l’absence d’exploits. C'est pourquoi nous croyons fermement qu'il est essentiel de garantir , en se concentrant sur les modèles d’exploitation et en les prévenant.
Source: habr.com