Le 12 juillet 2022 11:39:41 GMT+02:00, Christophe Casalegno via FRsAG <frsag@frsag.org> a écrit :
Le mardi 12 juillet 2022, 10:11:37 IST Maxime DERCHE a écrit :
Là encore, cela relève de l'analyse au doigt mouillé, pas de la gestion de
risque. :)
Pas vraiment, ce genre de sujet est parfaitement documenté et traité dans de
nombreuses analyses de risques de nombreuses entreprises. Les mêmes qui sont
effectuées correctement et ne se contentent pas de reporter l'indice de gravité
d'un CVE publié sur internet, mais qui l'appliquent au contexte de
l'entreprise (exemple : un remote exploit flagué au max sur un équipement
déconnecté de tout réseau, n'a aucun sens). Même si chez 90% des acteurs c'est
le bordel : certains font le boulot, proprement et en détail pour chaque
composant.
(L'équipe d'OpenBSD a maintenu Apache HTTPd 1.3 pendant des années sans
problème. C'est par contre inimaginable dans le monde
propriétaire/commercial.)
Il s'agit juste d'une question de volonté et de capacité de l'éditeur. Il est
parfaitement possible de maintenir une vieille version d'un logiciel pour une
ancienne version ad vitam. Contrairement aux idées reçues cela ne signifie pas
toujours une quantité de travail astronomique.
prestataire qui maintient un service obsolète depuis longtemps d'avoir
cassé quelque chose avec un patch artisanal introduisant un bug quelconque
(par exemple) ?
ça veut dire quoi "artisanal" ici ? Les responsabilités des prestataires et
des éditeurs sont généralement dans tous les cas déterminées par le contexte
juridique (et dans la plupart des licenses, qu'elles soient libres ou
propriétaires, il y a peu de garanties coté éditeur en dehors du fait de
corriger après coup certains bugs)
Au passage l'argument des trucs tellement anciens qu'ils sont devenus sûrs
ne tient
ni techniquement (Internet n'oublie jamais rien, l'exploit
publié en 19xy est toujours disponible et fonctionnel) ni juridiquement
("security by design"), et encore moins moralement face aux personnes
concernées qui nous font confiance pour protéger leurs données...
Ce n'est pas du tout ce que j'ai écrit : je dis qu'une fois qu'on a patché
tout ce qui a été publié, le % de risque de voir sortir une *nouvelle*
vulnérabilité sur un système vieux de 15 ans et peu utilisé est quasiment nul.
Ce n'est pas un argument d'autorité : c'est un argument statistique. Cela ne
signifie pas que le produit est plus ou moins sur : seulement qu'on ne publie
plus de vulnérabilités à son sujet car tout le monde s'en fou.
Peut être que quelqu'un qui n'a que ça à faire va publier un jour une nouvelle
vulnérabilité sur apache 1.3 ou php4, mais ça n'intéresse personne. Si
quelqu'un fait ça, c'est qu'il sera probablement le plus concerné lui même par
la faille et son correctif.. Là encore c'est statistique.
marché pour héberger des applications PHP 4 non-maintenues (ou maintenues
mais faibles voire indéfendables) au risque que les données fuitent, et
tant pis pour les victimes, même si l'hébergeur a bien fait son travail.
Bon courage pour démontrer qu'une application développée en php4 et qui a été
capable de résister à 15 ans d'attaques quotidiennes avec une exposition
maximale est de facto moins sécure qu'une application développée en php 8.1 il
y a 2 mois...
Attention, je ne dis pas que c'est *ce qu'il faut faire*, je dis juste que
l'aspect sécurité est beaucoup plus complexe qu'en première apparence et
dépend à chaque fois du contexte.
Aujourd'hui un serveur en apache 1.3 et php4 a moins de change de pouvoir se
faire défoncer qu'un serveur en apache 2.4 avec php 8.1 : les logiciels sont
de plus en plus gros, de plus en plus lourd, et tout programme de plus de
100kb est *toujours* bugué. L'épreuve du temps reste sécuritairement parlant
une valeur sure, surtout en environnement libre / opensource sur un logiciel
qui a été très utilisé (et ou donc beaucoup de personnes y ont cherché, moi le
premier des vulnérabilités).
amicalement,