Windows : faille 0-day dans le moteur JET pour toutes les versions

Windows : faille 0-day dans le moteur JET pour toutes les versions

Par Sébastien Gavois

Le 24 Septembre 2018 à 09h45
Logiciel
1 min 12

Windows : faille 0-day dans le moteur JET pour toutes les versions

Le chercheur Lucas Leong, de chez Trend Micro Security Research, a rendu publique une faille 0-day valable pour toutes les versions de Windows en cours de support, dont les 7, 8.1 et 10.

La brèche réside dans la manière dont le moteur de base de données JET Database Engine gère les index. Exploitée, elle permet au processus d’écrire dans une autre zone mémoire, donc une exécution de code arbitraire. Elle peut se faire à distance si le pirate réussit à faire ouvrir une base de JET.

La vulnérabilité avait été signalée le 8 mai à Microsoft, qui a confirmé son existence six jours plus tard. L’éditeur n’ayant pas apporté de correctif dans les 120 jours impartis, la Zero Day Initiative a publié un bulletin d’information.

De son côté, Trend Micro Security a fourni les détails de la faille, accompagnés d’un prototype d’exploitation sur GitHub.

Microsoft travaille bien à colmater la brèche, mais il faudra attendre maintenant le Patch Tuesday du 9 octobre comme prochaine rampe de lancement. À moins que l’entreprise estime la situation urgente, mais le calendrier ne plaide pas pour cette hypothèse.

Commentaires (12)


Dude76 Abonné
Le 24/09/2018 à 08h56

Je trouve toujours aussi couillon de voir une faille 0-day divulguée alors que le correctif est sur le lancement.

En quoi ça aurait dérangé d’attendre 15j de plus la publication planifiée du correctif ?

Qu’on en arrive à publier une faille lorsque l’éditeur fait la sourde oreille, ok, mais là…


Bejarid
Le 24/09/2018 à 09h48







Dude76 a écrit :



En quoi ça aurait dérangé d’attendre 15j de plus la publication planifiée du correctif ? 



  Qu'on en arrive à publier une faille lorsque l'éditeur fait la sourde oreille, ok, mais là...









  Quand un éditeur n'a pas réagit en 120 jours, on considère qu'il fait la sourde oreille (rien ne garanti à 100% que le correctif sera bien là pour le tuesday patch d'octobre, après tout il ne l'était pas pour celui de septembre). Donc en soit, c'est logique que ça soit publié.      







 Mais c'est plus la raison du temps de développement de ce patch qui est intéressante. Y a plusieurs domaine où, oui, 120 jours c'est trop court pour faire un patch, car rien que les tests de non régression peuvent prendre plus de temps (Windows était déployé dans un gros nombre de situation, elles se font parfois en entreprise, car la config ne saurait en sortir pour des raisons de sécurité). Et là, ça pourrait devenir idiot d'avoir publié la faille...




Dans ce cas précis, vu que ça ne touche que Jet (base de donnée d’Access, pas de Windows qui ne l’utilise pas), je pense que c’est surtout parce que MS s’en fout un peu <img data-src=" />



Roxtar!
Le 24/09/2018 à 09h51

ça fait peut-être 3 mois que MS lui dit que ça sera pour le prochain patch Tuesday…


barthous
Le 24/09/2018 à 11h51







Bejarid a écrit :



Quand un éditeur n’a pas réagit en 120 jours, on considère qu’il fait la sourde oreille (rien ne garanti à 100% que le correctif sera bien là pour le tuesday patch d’octobre, après tout il ne l’était pas pour celui de septembre). Donc en soit, c’est logique que ça soit publié. 




  Mais c'est plus la raison du temps de développement de ce patch qui est intéressante. Y a plusieurs domaine où, oui, 120 jours c'est trop court pour faire un patch, car rien que les tests de non régression peuvent prendre plus de temps (Windows était déployé dans un gros nombre de situation, elles se font parfois en entreprise, car la config ne saurait en sortir pour des raisons de sécurité). Et là, ça pourrait devenir idiot d'avoir publié la faille...




Dans ce cas précis, vu que ça ne touche que Jet (base de donnée d’Access, pas de Windows qui ne l’utilise pas), je pense que c’est surtout parce que MS s’en fout un peu <img data-src=" />



Si au moins ils avaient publié un moyen de s’en protéger en attendant le patch officiel, ça serait logique. Mais là non, c’est juste idiot.



barthous
Le 24/09/2018 à 11h53

ça n’en rend pas moins la faille dangereuse


Bejarid
Le 24/09/2018 à 12h47







barthous a écrit :



Si au moins ils avaient publié un moyen de s’en protéger en attendant le patch officiel, ça serait logique. Mais là non, c’est juste idiot.





“Crafted data in a database file can trigger a write past the end of an allocated buffer.” Je connais pas d’utilisation d’une base JET pour y mettre des données externes (dans le temps, c’était fait pour y sauvegarder les données locales de formulaires ACCESS). Et si une entreprise s’est amusé à faire ça, je crois que les failles de sécu de la DB sont le derniers de ses soucis, sans compter que les buffer overflow ne sont plus très efficace non plus avec l’ASLR, surtout que les bases JET tourne en espace utilisateur, donc même ainsi, y a pas vraiment de risque.

&nbsp; 



 Cette faille est d'une importance aussi faible que l'envie de NXi a faire du buzz avec du vent en mettant "FAILLE" et "WINDOWS" dans le titre est forte. C'est dire à quel point on s'en fout. Ceux qui utilise encore JET ont qu'a faire un petit effort et dev un truc un peu plus sérieux, au moins basé sur SQLite.




En vrai, le patch risque de mettre des années à sortir car faut déjà que MS arrive à retrouver des devs compétents dessus en maison de retraite !



Wosgien Abonné
Le 24/09/2018 à 12h54

Le moteur Jet, c’est bien le moteur qui n’existe qu’en version 32 bits et qu’il faut installer pour faire marcher de très vieux bouzins?

Vu que MS ne le porte pas en x64, je pense qu’ils ont perdu les sources en fait :)


Jerome7573 Abonné
Le 24/09/2018 à 13h07







barthous a écrit :



Si au moins ils avaient publié un moyen de s’en protéger en attendant le patch officiel, ça serait logique. Mais là non, c’est juste idiot.





Les gens qui disent “juste idiot” militent juste pour que la faille ne soit jamais corrigée car le seul qui peut corriger est l’auteur du logiciel (car un truc proprio) et si au bout de 120 jours toujours rien c’est que l’auteur n’a rien à faire. Donc “on attend” jusqu’à un autre découvre la faille (ça viendra, pas de raison d’être unique à découvrir) et l’exploite?

Rien d’horrible, juste la seule façon de faire bouger un auteur de logiciel proprio. Et ici l’auteur a jugé que ce n’était pas prioritaire, c’est que ça ne doit pas être méchant non? Donc pas de soucis à dévoiler la faille ;-).

Bref, ici soit la faille est mineur et la dévoiler n’est pas méchant, soit la faille est majeure et Microsoft est responsable du problème, en aucun cas il est “juste idiot” de dévoiler une faille après 120 jours.



Il y a des délais et c’est heureux, le seul irresponsable est l’auteur du logiciel si la faille n’est pas corrigée au bout de 120 jours (par exemple, c’est souvent négociable, voirhttps://fr.wikipedia.org/wiki/Divulgation_responsable pour plus d’info).



barthous
Le 24/09/2018 à 13h54

&nbsp;Je pense que tu n’as pas compris le sens&nbsp; de la remarque.

Qu’apporte donc la divulgation de la faille (concept et protocole pour réaliser l’attaque) sans un correctif ?

Rien à part une exposition énorme.

En quoi attendre la divulgation empeche la livraison du correctif ?


Jeanprofite
Le 24/09/2018 à 21h02

C’est désespérant ce dialogue de sourd.

Il a bien attendu 120 jours .



Il n’y aura peut-être pas de correctif = il faut utiliser un autre logiciel (respectant peut-être plus ses clients).

L’obfuscation n’est pas une sécurité.



Bejarid
Le 25/09/2018 à 01h30







Jeanprofite a écrit :



Il n’y aura peut-être pas de correctif = il faut utiliser un autre logiciel (respectant peut-être plus ses clients).





JET est passé en mode “support” et non “en développement” il y a des années. Cela fait bien longtemps que les clients sont encouragés à changer de DB. Sauf que contrairement à ce qui se fait dans le libre et certains concurrent, où certains projets meurt du jour au lendemain, chez MS les clients continuent à avoir un truc qui marche pendant 10 ans, même après que ça soit déclaré comme “mort” (car remplacé par mieux : SQLCompact, SQLite…). Et cette faille ne remet pas ça en cause, car en local elle ne pause pas de problème, et même en remote l’ASLR en bloque l’exploitation.



Qui est respectueux ici du coup ?



Jeanprofite
Le 25/09/2018 à 05h22

Je ne connaissais pas l’historique. Merci pour l’éclairage.


Fermer