Des petits trous, des petits trous, encore des petits trous

L’actualité (https://citizenlab.org/2016/08/million-dollar-dissident-iphone-zero-day-nso-group-uae/) nous donne un excellent exemple avec les 0 days révélés dans iOS :

• CVE-2016-4655: Information leak in Kernel – A kernel base mapping vulnerability that leaks information to the attacker allowing him to calculate the kernel’s location in memory.
• CVE-2016-4656: Kernel Memory corruption leads to Jailbreak – 32 and 64 bit iOS kernel-level vulnerabilities that allow the attacker to silently jailbreak the device and install surveillance software.
• CVE-2016-4657: Memory Corruption in Webkit – A vulnerability in the Safari WebKit that allows the attacker to compromise the device when the user clicks on a link.

Ils ont été très rapidement patchés sur iOS, mais on mis une dizaine de jours à être patchées sur OS X, et en plus, elles ont été mal patchées : http://sektioneins.de/en/blog/16-09-05-pegasus-ios-kernel-vulnerability-explained-part-2.html

Il arrive très fréquemment que des projets s’appuient sur du code tiers (genre une bibliothèque externe à la zlib), ou partagent des composants (libssl utilisée par plein de composants sous Android). On se retrouve avec une jolie vuln quand :

1. la bibliothèque n’est pas à jour, par exemple des vulns dans zlib ou openssl qui sont très largement utilisées par d’autres composants, mais pas forcément dans leur dernière version ou pour lesquelles le patch n’est pas backporté ;
2. le correctif est appliqué au mauvais endroit, tuant uniquement un code path, mais pas la root cause. On voit ce qui se passe quand il existe d’autres code paths, comme l’exemple précédent pour iOS / OS X.

L’objectif de ce projet est de proposer des approches et des stratégies pour déterminer lorsque de telles situations se produisent.