La sérialisation en Java : une horrible erreur

Par:
fredericmazue

mar, 29/05/2018 - 15:12

Ceci selon Mark Reinhold lui-même. Mark Reinhold est l'architecte en chef de la plateforme Java chez Oracle. Il s'est confié à InfoWorld sur ce sujet il y a quelques jours.

Mark Reinhold indique que l'équipe Java travaille actuellement à la suppression de la prise en charge de la sérialisation dans le JDK. Pour ceux qui en ont absolument besoin, un système de plug-in pour prendre en charge les opérations de sérialisation via un nouveau framework sera proposé. Mark Reinhold n'a précisé aucune date

Pour lui, l'ajout du support de la sérialisation à Java qui a été faite en 1997 a été 'a horrible mistake', une horrible erreur.

La sérialisation permet de transformer un objet en un flux d'octets, ce qui permet de le rendre persistant, ou de le reconstituer par désérialisation via RMI, une connexion par socket, etc.

Le problème de la sérialisation Java se situe au niveau de la sécurité. Selon Mark Reinhold, au moins un tiers, et peut-être même la moitié des problèmes des vulnérabilités dans Java, impliquent la sérialisation. En janvier 2018, Oracle a corrigé 237 vulnérabilités dans Java. Plus de 28% d'entre elles concernaient des opérations de désérialisation non sécurisées.

Ce problème majeur est apparu début 2015 lorsque deux chercheurs - Chris Frohoff et Gabriel Lawrence - ont découvert une faille de désérialisation dans Apache Commons Collection.

Fin  2015, des chercheurs de Foxglove Security sont allés plus loin en montrant comment un attaquant pourrait utiliser une faille de désérialisation dans les applications Java où les développeurs n'utilisent pas correctement la bibliothèque Apache Commons Collection pour gérer les opérations de désérialisation.

Ils ont montré qu'un attaquant pouvait injecter des données malveillantes dans des applications Java populaires telles que WebLogic, WebSphere, JBoss, Jenkins et OpenNMS. Ces données sont sérialisées et stockées dans une base de données ou en mémoire, et lorsque l'application les désérialise, elle exécute le code malveillant injecté.

La faille a secoué tout l'écosystème Java en 2016, lorsqu'on s'est aperçu qu'elle affectait 70 autres bibliothèques Java, et qu'elle a même été utilisée pour compromettre les serveurs de PayPal. Des organisations telles qu'Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare, IBM, Intel, Adobe, HP et SolarWinds, ont toutes du publier des correctifs de sécurité pour patcher leurs produits.

Cette faille de Java était considérée comme si dangereuse que les ingénieurs de Google se sont regroupés pendant leur temps libre pour corriger les bibliothèques Java open-source de plus de 2 600 projets. En interne, chez Google, la faille était référencée comme Mad Gadget, mais tout le monde l'appelait Java Apocalypse.

L'année dernière, une seule faille de désérialisation dans Apache Struts (Java) a affecté 65% des entreprises du Fortune 100 , 

Pour mémoire, en attendant qu'Oracle fasse les modifications annoncées par Mark Reinhold, rappelons que les entreprises et les chefs de projet qui ne veulent pas qu'un développeur ou un module appelle des fonctions de sérialisation / désérialisation peuvent empêcher cela via le "filtre de sérialisation" qui a été ajouté à Java en 2016.