Ce que tu dis est certainement valable pour les branches stables (quatrième composant dans le numéro de version pour le noyau linux, mises à jour des distributions, ...), où les patchs sont peu nombreux, déjà identifiés comme critiques (sans quoi ils ne sont pas rétro-portés dans les branches stables), et où les patchs sont sujet à une attention particulière, plutôt pour éviter des régressions par effet de bord que pour évaluer les conséquences en terme de sécurité (et c'est dommage puisqu'une bonne partie du travail est déjà faite).
Mais est-ce applicable pour le lot commun des patchs concernant un OS ? Pour les trois que je connais, la tâche semble ardue : ce qui est reproché aujourd'hui à Linux l'est régulièrement à Microsoft. Et OpenBSD ne prétends par faire mieux : les devs anticipent la question en martelant : "nous préférons passer du temps à prévenir et corriger plein de choses qu'à évaluer la possibilité qu'un de nos patch répare une faille de sécurité" ; il leur arrive effectivement de découvrir avoir corrigé une faille longtemps après l'application d'un patch (par ex. sur leur version d'apache).
Autrement dit, tout les fournisseurs OS sont régulièrement accusés de cacher intentionnellement la poussière sous le tapis ; et le fait que ça touche tout les OS permet justement de douter du qualificatif "intentionnellement".
Détaillons le cas de la démarche dite "proactive" (= le principe de "mieux vaut prévenir que guérir") d'OpenBSD. L'équipe de développeur est assez réduite ; à chaque nouvelle faille, et à chaque découverte de paradigmes de programmation sécurisée, ils ont pour habitude de passer tout leur CVS (contenant un OS complet hein, pas seulement le noyau) à la moulinette du rechercher/remplacer. C'était le cas lorsqu'ils ont remplacé tout les srt[n]cat/cpy par des strlcat/cpy, la plupart des atoll/atoi par des strtonum, trouvé une méthodologie plus robuste pour prévenir les débordement d'entiers, activé tel ou tel warning supplémentaire du compilateur et corrigé tout ce qui bronche, etc. : un travail de titan, et des dizaines de milliers de patchs à chaque fois. Si, pour chacun de ces patchs, il avait fallu passer plusieurs heures à chercher s'il corrigeait une faille effective, ils n'auraient jamais pu mener ces chantiers à terme, loin s'en faut.
Moralité : dans ce cas, l'effort de transparence (catégorisation des modifications appliquées dans les branches de développement de l'OS) est antithétique et préjudiciable à la sécurité effective du système. Tout simplement parce que les ressources humaines ne sont pas illimitées (peut-être qu'elle le sont chez Microsoft, mais ce n'est pas le cas pour les OS libres que je connais). Et si le "armchair security expert" était, justement, celui qui juge le résultat de haut et de loin, sans mettre les mains dans le cambouis ?
[^] # Re: Quelques commentaires
Posté par herodiade . En réponse à la dépêche Exploit local dans le noyau Linux 2.6.30. Évalué à 7.
Mais est-ce applicable pour le lot commun des patchs concernant un OS ? Pour les trois que je connais, la tâche semble ardue : ce qui est reproché aujourd'hui à Linux l'est régulièrement à Microsoft. Et OpenBSD ne prétends par faire mieux : les devs anticipent la question en martelant : "nous préférons passer du temps à prévenir et corriger plein de choses qu'à évaluer la possibilité qu'un de nos patch répare une faille de sécurité" ; il leur arrive effectivement de découvrir avoir corrigé une faille longtemps après l'application d'un patch (par ex. sur leur version d'apache).
Autrement dit, tout les fournisseurs OS sont régulièrement accusés de cacher intentionnellement la poussière sous le tapis ; et le fait que ça touche tout les OS permet justement de douter du qualificatif "intentionnellement".
Détaillons le cas de la démarche dite "proactive" (= le principe de "mieux vaut prévenir que guérir") d'OpenBSD. L'équipe de développeur est assez réduite ; à chaque nouvelle faille, et à chaque découverte de paradigmes de programmation sécurisée, ils ont pour habitude de passer tout leur CVS (contenant un OS complet hein, pas seulement le noyau) à la moulinette du rechercher/remplacer. C'était le cas lorsqu'ils ont remplacé tout les srt[n]cat/cpy par des strlcat/cpy, la plupart des atoll/atoi par des strtonum, trouvé une méthodologie plus robuste pour prévenir les débordement d'entiers, activé tel ou tel warning supplémentaire du compilateur et corrigé tout ce qui bronche, etc. : un travail de titan, et des dizaines de milliers de patchs à chaque fois. Si, pour chacun de ces patchs, il avait fallu passer plusieurs heures à chercher s'il corrigeait une faille effective, ils n'auraient jamais pu mener ces chantiers à terme, loin s'en faut.
Moralité : dans ce cas, l'effort de transparence (catégorisation des modifications appliquées dans les branches de développement de l'OS) est antithétique et préjudiciable à la sécurité effective du système. Tout simplement parce que les ressources humaines ne sont pas illimitées (peut-être qu'elle le sont chez Microsoft, mais ce n'est pas le cas pour les OS libres que je connais). Et si le "armchair security expert" était, justement, celui qui juge le résultat de haut et de loin, sans mettre les mains dans le cambouis ?