Les conséquences d’une vulnérabilité vieille de plusieurs années : SQLite

En octobre 2022, les chercheurs de Trail of Bits ont publié la décomposition précise d’une vulnérabilité dans le système de gestion de base de données (SGBD) SQLite. L’article évoque les attaques possibles en exploitant CVE-2022-35737, avec des conséquences qui vont du simple plantage de l’application à l’exécution d’un code arbitraire. Ce bug assez anecdotique du code SQLite est intéressant et potentiellement dangereux pour deux raisons. Tout d’abord, il se trouve dans SQLite depuis octobre 2000, autrement dit depuis les débuts du développement de ce programme open-source. Ensuite, les fonctionnalités de SQLite pourraient, en théorie, permettre d’attaquer un vaste éventail de programmes qui utilisent SQLite.

Les fonctionnalités de SQLite

SQLite est un système de gestion de base de données compact, open-source et intégré sorti il y a 22 ans (août 2000). « Intégré  » est le mot-clé. SQLite n’est pas installé comme un programme indépendant. En effet, les développeurs de programmes qui ont besoin de travailler avec des bases de données s’en servent comme bibliothèque. SQLite est inclus par défaut comme c’est le cas avec les navigateurs Google Chrome, Firefox et Safari, avec Android, avec les applications de réseau et avec de nombreux packs à distribuer pour les systèmes d’exploitation basés sur le noyau Linux. SQLite s’est fait connaître pour sa licence libre, son sérieux et… sa sécurité. Peu de failles graves ont été trouvées dans le code de ce SGBD jusqu’à présent.

Les détails de CVE-2022-35737

Les experts ont détecté un bug dans le code de la fonction sqlite3_snprintf, utilisé pour interagir avec la base de données dans les programmes écrits en C/C++. Si vous envoyez une très grande quantité de données en chaîne (plus de 2 GB) à cette fonction, le programme va planter et une attaque par déni de service pourra être lancée (DoS). Avec le code sqlite3_snprintf, une variable entière était utilisée pour calculer la taille des données transmises. Si la quantité est trop importante, la variable peut prendre une valeur négative. La mémoire tampon qui doit être attribuée est trop petite pour écrire les données reçues, ce qui provoque une erreur de dépassement de tampon.

Il est fort probable que l’erreur ait été saisie dans le code il y a 22 ans, puisque le transfert de gigaoctets des paramètres de la fonction était improbable à cause des limites de l’époque en termes de ressources. Ce n’est plus le cas aujourd’hui. L’hypothèse émise pour chercher à comprendre pourquoi cette erreur n’a pas été détectée lorsque le code a été testé est un autre point intéressant du rapport de Trail of Bits. L’objectif de la procédure de test est essentiellement de vérifier le code ajouté ou modifié, mais le code de SQLite est le même depuis plus de 20 ans. Ces vulnérabilités sont assez difficiles à détecter avec le fuzzing, qui consiste à injecter des données aléatoires dans les entrées d’un programme. Les méthodes habituelles de fuzzing n’impliquent pas la génération de grandes chaînes de données. Les auteurs de cette étude en ont conclu que le fuzzing ne peut pas vraiment remplacer l’analyse statique du code, même si l’action est effectuée manuellement.

Des implications floues

Trail of Bits a pu « moderniser » l’attaque par déni de service originale afin d’exécuter un code arbitraire en manipulant minutieusement le contenu et la taille des paramètres envoyés. Même si les auteurs de de ce rapport ont présenté une preuve de concept en donnant plusieurs exemples d’attaques, ce n’est qu’un exercice purement théorique d’attaque contre SQLite. Pourtant, comme nous l’avons dit antérieurement, SQLite est un SGBD intégré et le cybercriminel devrait se servir du code SQLite intégré pour attaquer une application et causer des dégâts.

Il s’avère que cette étude offre diverses hypothèses, et l’exploitation de cette vulnérabilité en pratique doit encore être démontrée. Il y a plusieurs limites. Selon les données fournies par les développeurs de SQLite, le bug n’est pertinent que pour l’interface des applications C et seulement si le code est compilé selon plusieurs paramètres. Les chercheurs de Trail of Bits ont eux-mêmes souligné qu’il est impossible de lancer une attaque si SQLite est compilé avec des cookies de sécurité (stack canaries). Une méthode supplémentaire de protection contre les attaques du dépassement de tampon qui empêche l’exécution d’un code arbitraire même lorsque le dépassement est possible.

La vulnérabilité a été corrigée en juillet 2022 avec la sortie de SQLite 3.39.2. Pourtant, le patch a eu peu d’effet. Les développeurs de programmes qui se servent de SQLite dans leur code vont certainement devoir mettre à jour leurs développements et proposer une nouvelle version du programme. La vulnérabilité sera présente jusqu’alors. Il convient de souligner que de nombreux programmes qui utilisent SQLite ne sont plus soutenus.

Nous ne savons pas vraiment à quel point cette vulnérabilité est dangereuse et dans quelle mesure elle peut être exploitée en pratique. À en juger par la définition des développeurs de SQLite, le risque d’attaque réelle est bas mais existe. En attendant, le bug a été ajouté à notre collection de défauts qui existent depuis des années et qui pourraient éventuellement être un véritable casse-tête pour les développeurs de programmes.