P2Patch trouve des contournements et renforce les correctifs de sécurité

Comment les évaluateurs peuvent-ils savoir si une réparation logicielle ferme la vulnérabilité signalée, au lieu de bloquer seulement l’exemple qui a guidé la réparation ?

Les mêmes éléments servent souvent à la fois à construire le correctif et à vérifier sa réussite ; un seul exemple bloqué peut donc masquer un autre chemin vers la même faille.

P2Patch transforme les attaques confirmées contre un correctif en nouvelles exigences de réparation, puis évalue le résultat sur des tests d’attaque indépendants.

Les chercheurs ont comparé P2Patch à une réparation en une seule passe à partir du même constat, sans exemple d’attaque exécutable ni recherche ultérieure de contournements. Ils ont mesuré, pour chaque projet, la part des tests d’attaque concluants mis de côté que le correctif bloquait, puis calculé la moyenne entre les projets.

Sur les tests bloqués par le correctif officiel, les moyennes sont de 0,847 pour P2Patch et de 0,781 pour la réparation en une seule passe, sur 101 sujets.

Sur les tests qui reproduisent aussi la faille après le correctif officiel, les moyennes sont de 0,625 et de 0,421 pour les 40 sujets disposant de telles suites. L’orchestrateur a évalué les résultats d’exécution, tandis que les chercheurs ont calculé ces moyennes.

Les deux groupes de tests montrent une couverture mesurée plus élevée, à la fois sur les chemins fermés par le correctif officiel et sur les chemins possibles qu’il laisse ouverts.

La recherche d’attaques dispose d’un budget fixe, et les suites de tests rédigées indépendamment couvrent certains parcours, pas l’ensemble des entrées possibles. Une exécution stable ou une couverture mesurée élevée ne prouve donc pas qu’un correctif ne contient aucune vulnérabilité.