{"id":19702,"date":"2022-11-08T12:59:44","date_gmt":"2022-11-08T10:59:44","guid":{"rendered":"https:\/\/www.kaspersky.fr\/blog\/?p=19702"},"modified":"2022-11-08T12:59:44","modified_gmt":"2022-11-08T10:59:44","slug":"sqlite-vulnerability-22yo","status":"publish","type":"post","link":"https:\/\/www.kaspersky.fr\/blog\/sqlite-vulnerability-22yo\/19702\/","title":{"rendered":"Les cons\u00e9quences d&rsquo;une vuln\u00e9rabilit\u00e9 vieille de plusieurs ann\u00e9es : SQLite"},"content":{"rendered":"<p>En octobre 2022, les chercheurs de Trail of Bits <a href=\"https:\/\/blog.trailofbits.com\/2022\/10\/25\/sqlite-vulnerability-july-2022-library-api\/\" target=\"_blank\" rel=\"noopener nofollow\">ont publi\u00e9<\/a> la d\u00e9composition pr\u00e9cise d\u2019une vuln\u00e9rabilit\u00e9 dans le syst\u00e8me de gestion de base de donn\u00e9es (SGBD) SQLite. L\u2019article \u00e9voque les attaques possibles en exploitant <a href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2022-35737\" target=\"_blank\" rel=\"noopener nofollow\">CVE-2022-35737<\/a>, avec des cons\u00e9quences qui vont du simple plantage de l\u2019application \u00e0 l\u2019ex\u00e9cution d\u2019un code arbitraire. Ce bug assez anecdotique du code SQLite est int\u00e9ressant et potentiellement dangereux pour deux raisons. Tout d\u2019abord, il se trouve dans SQLite depuis octobre 2000, autrement dit depuis les d\u00e9buts du d\u00e9veloppement de ce programme open-source. Ensuite, les fonctionnalit\u00e9s de SQLite pourraient, en th\u00e9orie, permettre d\u2019attaquer un vaste \u00e9ventail de programmes qui utilisent SQLite.<\/p>\n<h2>Les fonctionnalit\u00e9s de SQLite<\/h2>\n<p>SQLite est un <a href=\"https:\/\/fr.wikipedia.org\/wiki\/Base_de_donn%C3%A9es\" target=\"_blank\" rel=\"noopener nofollow\">syst\u00e8me de gestion de base de donn\u00e9es<\/a> compact, open-source et int\u00e9gr\u00e9 sorti il y a 22 ans (ao\u00fbt 2000). \u00ab\u00a0Int\u00e9gr\u00e9 \u00a0\u00bb est le mot-cl\u00e9. SQLite n\u2019est pas install\u00e9 comme un programme ind\u00e9pendant. En effet, les d\u00e9veloppeurs de programmes qui ont besoin de travailler avec des bases de donn\u00e9es s\u2019en servent comme biblioth\u00e8que. SQLite est inclus par d\u00e9faut comme c\u2019est le cas avec les navigateurs Google Chrome, Firefox et Safari, avec Android, avec les applications de r\u00e9seau et avec de nombreux packs \u00e0 distribuer pour les syst\u00e8mes d\u2019exploitation bas\u00e9s sur le noyau Linux. SQLite s\u2019est fait conna\u00eetre pour sa licence libre, son s\u00e9rieux et\u2026 sa s\u00e9curit\u00e9. Peu de failles graves ont \u00e9t\u00e9 trouv\u00e9es dans le code de ce SGBD jusqu\u2019\u00e0 pr\u00e9sent.<\/p>\n<h2>Les d\u00e9tails de CVE-2022-35737<\/h2>\n<p>Les experts ont d\u00e9tect\u00e9 un bug dans le code de la fonction <em>sqlite3_snprintf<\/em>, utilis\u00e9 pour interagir avec la base de donn\u00e9es dans les programmes \u00e9crits en C\/C++. Si vous envoyez une tr\u00e8s grande quantit\u00e9 de donn\u00e9es en cha\u00eene (plus de 2 GB) \u00e0 cette fonction, le programme va planter et une attaque par d\u00e9ni de service pourra \u00eatre lanc\u00e9e (DoS). Avec le <em>code sqlite3_snprintf<\/em>, une variable enti\u00e8re \u00e9tait utilis\u00e9e pour calculer la taille des donn\u00e9es transmises. Si la quantit\u00e9 est trop importante, la variable peut prendre une valeur n\u00e9gative. La m\u00e9moire tampon qui doit \u00eatre attribu\u00e9e est trop petite pour \u00e9crire les donn\u00e9es re\u00e7ues, ce qui provoque une erreur de d\u00e9passement de tampon.<\/p>\n<p>Il est fort probable que l\u2019erreur ait \u00e9t\u00e9 saisie dans le code il y a 22 ans, puisque le transfert de gigaoctets des param\u00e8tres de la fonction \u00e9tait improbable \u00e0 cause des limites de l\u2019\u00e9poque en termes de ressources. Ce n\u2019est plus le cas aujourd\u2019hui. L\u2019hypoth\u00e8se \u00e9mise pour chercher \u00e0 comprendre pourquoi cette erreur n\u2019a pas \u00e9t\u00e9 d\u00e9tect\u00e9e lorsque le code a \u00e9t\u00e9 test\u00e9 est un autre point int\u00e9ressant du rapport de Trail of Bits. L\u2019objectif de la proc\u00e9dure de test est essentiellement de v\u00e9rifier le code ajout\u00e9 ou modifi\u00e9, mais le code de SQLite est le m\u00eame depuis plus de 20 ans. Ces vuln\u00e9rabilit\u00e9s sont assez difficiles \u00e0 d\u00e9tecter avec le fuzzing, qui consiste \u00e0 injecter des donn\u00e9es al\u00e9atoires dans les entr\u00e9es d\u2019un programme. Les m\u00e9thodes habituelles de fuzzing n\u2019impliquent pas la g\u00e9n\u00e9ration de grandes cha\u00eenes de donn\u00e9es. Les auteurs de cette \u00e9tude en ont conclu que le fuzzing ne peut pas vraiment remplacer l\u2019analyse statique du code, m\u00eame si l\u2019action est effectu\u00e9e manuellement.<\/p>\n<h2>Des implications floues<\/h2>\n<p>Trail of Bits a pu \u00ab\u00a0moderniser\u00a0\u00bb l\u2019attaque par d\u00e9ni de service originale afin d\u2019ex\u00e9cuter un code arbitraire en manipulant minutieusement le contenu et la taille des param\u00e8tres envoy\u00e9s. M\u00eame si les auteurs de de ce rapport <a href=\"https:\/\/github.com\/trailofbits\/publications\/tree\/master\/disclosures\/CVE-2022-35737\" target=\"_blank\" rel=\"noopener nofollow\">ont pr\u00e9sent\u00e9<\/a> une preuve de concept en donnant plusieurs exemples d\u2019attaques, ce n\u2019est qu\u2019un exercice purement th\u00e9orique d\u2019attaque contre SQLite. Pourtant, comme nous l\u2019avons dit ant\u00e9rieurement, SQLite est un SGBD int\u00e9gr\u00e9 et le cybercriminel devrait se servir du code SQLite int\u00e9gr\u00e9 pour attaquer une application et causer des d\u00e9g\u00e2ts.<\/p>\n<p>Il s\u2019av\u00e8re que cette \u00e9tude offre diverses hypoth\u00e8ses, et l\u2019exploitation de cette vuln\u00e9rabilit\u00e9 en pratique doit encore \u00eatre d\u00e9montr\u00e9e. Il y a plusieurs limites. Selon les <a href=\"https:\/\/www.sqlite.org\/cves.html\" target=\"_blank\" rel=\"noopener nofollow\">donn\u00e9es<\/a> fournies par les d\u00e9veloppeurs de SQLite, le bug n\u2019est pertinent que pour l\u2019interface des applications C et seulement si le code est compil\u00e9 selon plusieurs param\u00e8tres. Les chercheurs de Trail of Bits ont eux-m\u00eames soulign\u00e9 qu\u2019il est impossible de lancer une attaque si SQLite est compil\u00e9 avec des cookies de s\u00e9curit\u00e9 (<em>stack canaries<\/em>). Une m\u00e9thode suppl\u00e9mentaire de protection contre les attaques du d\u00e9passement de tampon qui emp\u00eache l\u2019ex\u00e9cution d\u2019un code arbitraire m\u00eame lorsque le d\u00e9passement est possible.<\/p>\n<p>La vuln\u00e9rabilit\u00e9 <a href=\"https:\/\/www.sqlite.org\/releaselog\/3_39_2.html\" target=\"_blank\" rel=\"noopener nofollow\">a \u00e9t\u00e9 corrig\u00e9e<\/a> en juillet 2022 avec la sortie de SQLite 3.39.2. Pourtant, le patch a eu peu d\u2019effet. Les d\u00e9veloppeurs de programmes qui se servent de SQLite dans leur code vont certainement devoir mettre \u00e0 jour leurs d\u00e9veloppements et proposer une nouvelle version du programme. La vuln\u00e9rabilit\u00e9 sera pr\u00e9sente jusqu\u2019alors. Il convient de souligner que de nombreux programmes qui utilisent SQLite ne sont plus soutenus.<\/p>\n<p>Nous ne savons pas vraiment \u00e0 quel point cette vuln\u00e9rabilit\u00e9 est dangereuse et dans quelle mesure elle peut \u00eatre exploit\u00e9e en pratique. \u00c0 en juger par la d\u00e9finition des d\u00e9veloppeurs de SQLite, le risque d\u2019attaque r\u00e9elle est bas mais existe. En attendant, le bug a \u00e9t\u00e9 ajout\u00e9 \u00e0 notre <a href=\"https:\/\/www.kaspersky.fr\/blog\/tarfile-15-year-old-vulnerability\/19552\/\" target=\"_blank\" rel=\"noopener\">collection<\/a> de d\u00e9fauts qui existent depuis des ann\u00e9es et qui pourraient \u00e9ventuellement \u00eatre un v\u00e9ritable casse-t\u00eate pour les d\u00e9veloppeurs de programmes.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"kesb-top3\">\n","protected":false},"excerpt":{"rendered":"<p>Un bug int\u00e9ressant dans un des plus c\u00e9l\u00e8bres SGBD int\u00e9gr\u00e9.<\/p>\n","protected":false},"author":665,"featured_media":19703,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2112,3150,3151],"tags":[1246,27,60,322],"class_list":{"0":"post-19702","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-developpement","11":"tag-sql","12":"tag-vulnerabilite","13":"tag-vulnerabilites"},"hreflang":[{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/sqlite-vulnerability-22yo\/19702\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/sqlite-vulnerability-22yo\/24829\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/sqlite-vulnerability-22yo\/20329\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/sqlite-vulnerability-22yo\/27364\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/sqlite-vulnerability-22yo\/25166\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/sqlite-vulnerability-22yo\/25501\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/sqlite-vulnerability-22yo\/28057\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/sqlite-vulnerability-22yo\/34205\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/sqlite-vulnerability-22yo\/46029\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/sqlite-vulnerability-22yo\/20389\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/sqlite-vulnerability-22yo\/29474\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/sqlite-vulnerability-22yo\/25570\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/sqlite-vulnerability-22yo\/31214\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/sqlite-vulnerability-22yo\/30921\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.fr\/blog\/tag\/vulnerabilite\/","name":"vuln\u00e9rabilit\u00e9"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/19702","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/comments?post=19702"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/19702\/revisions"}],"predecessor-version":[{"id":19706,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/19702\/revisions\/19706"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/media\/19703"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/media?parent=19702"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/categories?post=19702"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/tags?post=19702"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}