Historiquement, j'ai toujours lu que les fabricants d'analyseurs statiques indiquent, en moyenne, et de façon répétée, un nombre de vulnérabilités par ligne de code inférieur dans le logiciel ouvert par rapport au logiciel propriétaire. Et le Patch Tuesday de MS détaille chaque mois des corrections de jusqu'à des dizaines de vulnérabilités suffisamment graves dans Windows, alors que
l'on n'entend pas parler de dizaines de vulnérabilités graves par mois dans le
core du kernel Linux.
Mais dans Linux, les drivers font également partie du kernel, à une échelle beaucoup plus large que dans Windows, où nombre de drivers sont à la charge des fabricants (et pas forcément écrits selon les guidelines de sécurité...). Et j'avais lu que le nombre de vulnérabilités par ligne de code était beaucoup plus élevé dans les drivers que dans le core de Linux. Pour faire une comparaison à périmètre similaire (*) par rapport à Windows, il faut ne compter de Linux que le core et les drivers les plus centraux qui sont également présents dans Windows, ou bien - mais c'est probablement plus difficile - compter pour Windows également les vulnérabilités dans les drivers.
Depuis quelques semaines, le kernel Linux a sa propre CNA, et une ML pour annoncer les CVEs qui touchent le kernel Linux:
https://lore.kernel.org/linux-cve-announce/ . On peut tous voir qu'il y en a beaucoup, mais que seule une minorité touche le core, et que parmi les vulnérabilités, les problèmes graves car facilement exploitables sont (très ?) minoritaires. Du DoS, en général partiel, par nullptr deref, il y en a pas mal. Des memory leaks aussi, mais si la proportion de memory leaks qui peuvent être utilisés pour déclencher des DoS complets de la machine (parce qu'ils sont répétables à volonté) était autre chose que négligeable, je pense que depuis le temps, ça se verrait plus souvent. Des choses vraiment plus graves (OOB writes sur des tailles significatives, en particulier; UAF et UMR ne sont pas toujours faciles à exploiter), qui peuvent facilement entraîner ACE, RCE ou privesc, il y en a nettement moins.
Là où Linux pèche, outre certaines technos qui sont des passoires connues et qui ne s'améliorent que très lentement (citons eBPF, io_uring, unprivileged userns, ksmbd), c'est dans les défenses anti-exploitation. Pour ça, il n'y a qu'une vraie solution, depuis une vingtaine d'années maintenant: PaX + grsecurity. Les approches de type LKRG, qui s'exécutent au même niveau de privilège, permettent de détecter un certain nombre de choses a posteriori, mais c'est par construction trop tard et donc bypassable. Mais depuis 7 ans, pour avoir accès à PaX + grsecurity, il faut être une entreprise et payer. Au moins, cela leur a permis de vivre de leur travail, plutôt que de passer un temps libre très important, sans rémunération en commune mesure - et même de recruter d'autres chercheurs en sécurité pour continuer à augmenter l'écart avec mainline, ou encore de sponsoriser des développements sur le front-end Rust de GCC.
Du côté de Windows, Virtualization-Based Security pour une partie de l'OS finira par faire une différence... et les Linux utilisés par tout le monde n'ont aucune techno comparable.
*: historiquement, Windows avait une partie non négligeable de la stack graphique dans le kernel, donc les vulnérabilités de la stack graphique se comptaient également dans les vulnérabilités du kernel. Je ne sais pas si ça a changé dans les kernels Windows les plus récents.
Ceci dit il faut mettre à jour uefi pour changer ce logo donc déjà avoir sa machine sacrément infectée, non ?
