Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

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

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

Le 24 septembre 2018 à 09h45

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.

Le 24 septembre 2018 à 09h45

Commentaires (12)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

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à…

votre avatar







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=" />


votre avatar

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

votre avatar







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.


votre avatar

ça n’en rend pas moins la faille dangereuse

votre avatar







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 !


votre avatar

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 :)

votre avatar







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).


votre avatar

&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 ?

votre avatar

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é.


votre avatar







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 ?


votre avatar

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

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

Fermer