La sérialisation en Java, une « horrible erreur » ? Oracle prévoit de la supprimer,
Car elle serait la source de bon nombre de problèmes de sécurité

Le , par Michael Guilloux, Chroniqueur Actualités
Oracle prévoit de supprimer la prise en charge de la fonctionnalité de sérialisation / désérialisation des données du langage Java. C'est ce qu'a révélé Mark Reinhold, l'architecte en chef de la plateforme Java chez Oracle.

Pour information, la sérialisation est un mécanisme introduit dans les tout débuts de Java (JDK 1.1), en 1997. Ce mécanisme permet d’écrire des données présentes en mémoire (un objet par exemple) dans un format de données binaires, permettant alors de rendre persistant l’élément via un stockage disque, une transmission réseau ou autre. La désérialisation est l'activité réciproque qui permet d'utiliser l'objet sous sa forme originale. Java fournit donc un certain nombre d’outils permettant de sérialiser ou désérialiser de manière transparente et indépendante du système.

En raison de sa commodité, un grand nombre de langages de programmation prennent en charge cette fonctionnalité, mais pour Java, elle a été ces dernières années impliquée dans de nombreuses failles de sécurité. C'est ce qui motive d'ailleurs Oracle à vouloir la supprimer maintenant. L'ajout du support de la sérialisation à Java en 1997 était une « horrible erreur », affirme Mark Reinhold, alors qu'il explique qu'au moins un tiers - peut-être même la moitié - des vulnérabilités Java impliquent la sérialisation.

Pour comprendre les propos de l'architecte en chef du JDK chez Oracle, revenons d'abord au problème de sécurité de la sérialisation en Java. Notons avant d'aller plus loin que les attaques via des opérations de sérialisation sont connues depuis des années, sous une forme ou une autre. Elles sont toutefois devenues un problème sérieux après des découvertes faites par des chercheurs en 2015. D'abord à la conférence AppSec Californie en janvier 2015, deux chercheurs - Chris Frohoff et Gabriel Lawrence - ont présenté leurs travaux et des outils pour exploiter des mécanismes de sérialisation et les utiliser à des fins malveillantes.

En novembre 2015, des chercheurs de FoxGlove Security vont plus loin et révèlent qu'un certain nombre de bibliothèques Java chargées par défaut par les serveurs applicatifs (WebSphere, Jboss, WebLogic, etc.) sont vulnérables à des attaques par désérialisation. Et parmi ces bibliothèques se trouve Apache Commons Collections, un module Java très populaire.

Pour information, Apache Commons est un projet de la fondation Apache, dont le but est de fournir un ensemble de bibliothèques réutilisables et open source pour Java. Elles sont de ce fait, largement employées dans bon nombre de projets open source en Java. Apache Commons se décompose en un nombre important de modules, dont les utilisés sont Commons Collections, Commons DBCP, Commons IO, Commons Lang, Commons Logging et Commons Pool.

Fin 2015, en dehors d'Apache Commons Collections, plusieurs dizaines d'autres bibliothèques ont été déclarées vulnérables, ce qui a nécessité la mobilisation des organisations telles qu'Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare et IBM, entre autres, qui ont publié des correctifs de sécurité pour leurs produits. Malgré cela, la sérialisation continue d'être une source importante de problèmes de sécurité pour la plateforme. Ce qui conduit Mark Reinhold aujourd'hui à penser que c'était une « horrible erreur ».


L'équipe Java d'Oracle travaille donc actuellement sur la suppression de la prise en charge de la sérialisation. Toutefois, il ne s'agit pas de la supprimer complètement puisqu'il sera fourni aux développeurs un système de plug-in pour prendre en charge les opérations de sérialisation via un nouveau framework. Précisons aussi que la suppression de cette fonctionnalité est un objectif à long terme, donc la date de sa finalisation n'est pas encore définie. Mais jusqu'à ce qu'Oracle la supprime, les entreprises et les chefs de projet qui ne veulent pas qu'un développeur ou module appelle des fonctions de sérialisation ou désérialisation peuvent empêcher cela via un "filtre de sérialisation" qui a été ajouté dans Java en 2016 pour bloquer toutes ces opérations.

En savoir plus sur la vulnérabilité de sérialisation en Java

Source : Mark Reihnold, architecte en Chef du JDK chez Oracle

Et vous ?

Que pensez-vous de la décision d'Oracle ?
Utilisez-vous souvent la sérialisation en Java ? Est-ce une horrible erreur ?
Les plateformes telles que .NET, Ruby et autres sont-elles déjà protégées contre ces attaques ?

Voir aussi :

JavaFX SDK Early Access disponible pour le JDK 11 et un miroir GitHub du projet OpenJFX mis en place
Java SE 8 : les mises à jour publiques seront disponibles jusqu'à décembre 2020 minimum pour les fonctionnalités non commerciales
Java : proposition en open source pour Mission Control, l'outil de profilage et d'analyse des performances d'Oracle
JDK 11 : trois nouveautés sont prévues ainsi que la suppression de JAVA EE, JavaFX et CORBA, dans le cadre des mises à jour semestrielles
Tutoriel : La sérialisation binaire en Java


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de emixam16 emixam16 - Membre confirmé https://www.developpez.com
le 28/05/2018 à 14:46
Ça serait une bonne chose que Java modifie la manière dont est gérée la sérialisation car c'est effectivement une passoire d'un point de vue sécurité.

Mais aller jusqu'à supprimer une fonctionnalité si basique, cela me semble une très mauvaise idée.

Si les gens doivent sérialiser leurs objets manuellement ou utiliser des bibliothèques tierces (plus ou moins supportées), ça pourrait faire fuir beaucoup de gens de Java. La sérialisation c'est très simple à faire manuellement mais cela ne signifie pas que tout le monde soit près à le faire.

Par ailleurs, puisque énormément de code utilise la sérialisation, supprimer son support c'est rendre tous ces codes incompatibles avec les futures versions de JAVA

Bref, ce serait vraiment aller contre le sens du progrès.

[TROLL] Mais cela ne m'étonne pas d'Oracle, qui à l'habitude de changer l'or en plomb... [/TROLL]
Avatar de supergeoffrey supergeoffrey - Membre éprouvé https://www.developpez.com
le 28/05/2018 à 15:06
Que pensez-vous de la décision d'Oracle ?
Oui ça sert à rien, il existe des format tierce (JSON, XML) pour sérialiser des objets, et aussi des SGBD (et son équivalent pour le NoSql).
Utilisez-vous souvent la sérialisation en Java ? Est-ce une horrible erreur ?
Non. C'est pas très compliqué à écrire. Mais c'est plus dur à maintenir.
Les plateformes telles que .NET, Ruby et autres sont-elles déjà protégées contre ces attaques ?
J'en sais rien. Mais utiliser des standards permet de migrer plus facilment d'une plateforme à une autre.
Avatar de epsilon68 epsilon68 - Membre éprouvé https://www.developpez.com
le 28/05/2018 à 15:53
je pense que la serialisation dans Java ne servait a rien. Mieux vaut serialiser en XML ou json ou meme dans sqlite, c'est bien mieux. Je pense que leur decision de le mettre dans une librairie est la meilleure chose à faire

EDIT: +1 pour supergeoffrey
Avatar de Gugelhupf Gugelhupf - Modérateur https://www.developpez.com
le 28/05/2018 à 16:10
Bonjour,

La sérialisation Java n'est certe par parfaite:
  • Incompatibilité de sérialisation/désérialisation des objets entre les différentes versions de la JVM
  • Interopérabilité avec les autres langages quasi inexistante (ex: Sérialiser un objet Java, puis le récupérer dans un programme C#)
  • Vitesse de sérialisation/désérialisation plus lente et poids des objets plus élevés que ceux des technos plus récentes (gRPC ou Thrift Compact)


Par contre il y a tellement de librairies qui reposent sur la sérialisation Java qu'il sera difficile de s'en passer, RMI en fait parti.

A+
Avatar de AoCannaille AoCannaille - Membre émérite https://www.developpez.com
le 28/05/2018 à 16:49
Citation Envoyé par supergeoffrey Voir le message
Oui ça sert à rien, il existe des format tierce (JSON, XML) pour sérialiser des objets
J'ai l'impression de vivre dans un autre monde... Sérialiser en mode texte? sérieusement? à quoi ça peut servir un truc aussi gourmand?
Je ne suis pas dans le web, donc je ne sais pas l'utilité que vous avez de la sérialisation, mais personnellement on l'utilise soit entre applications sur la même machine, soit sur le réseau en radio.
En local, sur les petits objets pourquoi pas, mais dès que ça part sur du réseau, faire passer du texte est horriblement inefficient...

On utilise surtout google protocol buffer pour ça. ça marche plutôt bien.

Le binaire il n'y a que ça d'efficace!
Avatar de - https://www.developpez.com
le 28/05/2018 à 17:02

Pour information, la sérialisation est un mécanisme introduit dans les tout débuts de Java (JDK 1.1), en 1997. Ce mécanisme permet d’écrire des données présentes en mémoire (un objet par exemple) dans un format de données binaires, permettant alors de rendre persistant l’élément via un stockage disque, une transmission réseau ou autre. La désérialisation est l'activité réciproque qui permet d'utiliser l'objet sous sa forme originale. Java fournit donc un certain nombre d’outils permettant de sérialiser ou désérialiser de manière transparente et indépendante du système.
ASCII, ANSI, etc... ?

Ça serait une bonne chose que Java modifie la manière dont est gérée la sérialisation car c'est effectivement une passoire d'un point de vue sécurité.

Mais aller jusqu'à supprimer une fonctionnalité si basique, cela me semble une très mauvaise idée.
Soit c'est une variable public qui gène une donnée "globale ou public". Soit c'est une variable private ou protected qui peut transmettre aisément à du non autorisé ou c'est une histoire de certificat /chiffrement comme les certificats réseaux (
Oui, l'adresse MAC réseau n'est pas forcément fixe à un HW.)...
Je crois qu'ils auront des soucis qu'a l'accès de l'information de façon "public".


  1. Incompatibilité de sérialisation/désérialisation des objets entre les différentes versions de la JVM


C'est donc un " dump " de la mémoire de la JVM...
Injection de codes malicieux ?

Citation Envoyé par AoCannaille Voir le message
Utilisable dans un cluster de plusieurs machines constituant une machine massivement parallèle ? (calcul)
Relié de façon natif des barrettes mémoires en réseau...
Avatar de thelvin thelvin - Modérateur https://www.developpez.com
le 28/05/2018 à 17:14
Citation Envoyé par emixam16 Voir le message
Par ailleurs, puisque énormément de code utilise la sérialisation, supprimer son support c'est rendre tous ces codes incompatibles avec les futures versions de JAVA
Ah bah oui mais y'a pas de magie, hein. C'est une faille de sécurité ambulante, parce que ça fonctionne comme ça au lieu de fonctionner autrement. Du coup, ben, si tu casses pas la fonctionnalité existante, tu gardes les failles de sécurité comme elles sont. Logique.

Citation Envoyé par AoCannaille Voir le message
J'ai l'impression de vivre dans un autre monde... Sérialiser en mode texte? sérieusement? à quoi ça peut servir un truc aussi gourmand?
Même chose que la science, ça sert à marcher, b****** ! (Euh, je crois que c'est, "brelan de dames".)

Citation Envoyé par AoCannaille Voir le message
On utilise surtout google protocol buffer pour ça. ça marche plutôt bien.
Honnêtement, dès que je veux faire de la communication un peu lourde, j'utilise protocol buffer, oui. Les quelques pourcents économisés ont de la valeur à mes yeux.

Mais la différence fondamentale c'est que protocol buffer il faut lui configurer un modèle, le compiler, vérifier sa validité, le lier aux classes, etc. Il ne marche pas tout seul, il demande du travail.

XML et JSON marchent tout seul pour une utilisation simpliste, et ne demandent pas beaucoup de boulot quand on les connaît bien pour une utilisation plus universelle. Sensiblement moins de boulot que protocol buffer en tout cas.

C'est à ça que ça sert un protocole texte, lourdingue et universel. Ça marche, b******. Rien de plus ni de moins. Même raison pour laquelle le web est ce qu'il est. En principe ça devrait paraître tout autant ridicule tout ce texte dans le protocole le plus Universel de la planète. Et c'est lui qui c'est imposé. Parce que lui, il marche.
Avatar de atha2 atha2 - Membre éprouvé https://www.developpez.com
le 28/05/2018 à 20:41
Pour avoir pas mal travaillé avec des protocoles binaires, un des gros avantages de la sérialisation textuelle, c'est sa rapidité de debug, on voit tout de suite ou est le problème.

Sinon, on n'est pas obligé d'utiliser json/xml pour sérialiser rapidement des données, en java il existe Preon (présentation), une lib qui fait très bien le travaille (et qui permet de spécifier au bit près le mapping sur les champs de la structure) et si on a besoin interopérabilité, on peut utiliser le format BSON (format de stockage de MongoDB), qui s'il n'est pas normalisé, est populaire.
Avatar de kedare kedare - Membre expérimenté https://www.developpez.com
le 28/05/2018 à 20:51
C'est la même chose dans tout les languages, il faut pas "deserializer" des données qui ne sont pas sûre (Never Trust User Input).

Exemple avec Python: https://docs.python.org/3.6/library/pickle.html

Warning The pickle module is not secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source.
Le principe même de la serialization n'est pas sûr car on peut potentiellement bypasser les vérifications qui sont normalement faite a la construction et l'objet pour y passer tout ce qu'on veut.
Avatar de _champy_ _champy_ - Membre du Club https://www.developpez.com
le 28/05/2018 à 22:08
XML et JSON marchent tout seul pour une utilisation simpliste, et ne demandent pas beaucoup de boulot quand on les connaît bien pour une utilisation plus universelle. Sensiblement moins de boulot que protocol buffer en tout cas.
Surtout que si on cherche java serialization XML sur Google.fr on tombe la dessus https://ydisanto.developpez.com/tuto...ation/partie2/ La sérialisation XML est déjà prévu ...

En JSON bon d'accord faut un com.google.gson.Gson

Cela fait longtemps que je n'ai pas fait de Java mais si le problème est l’origine de la source de données pourquoi supprimer la sérialisation ?

Plus le temps passe plus j'ai l'impression qu'Oracle veut tuer Java, un jour il sortirons un langage propriétaire implémentant tout ce qu'il aurons supprimer de Java avec un outils de conversion OracleIKVM, très très chère.

Comme on dit chez nous "dans le cul lulu"
Contacter le responsable de la rubrique Accueil