Discussion :

[OButterlin]

Par contre, faut faire super attention à bien valider d'ou viennent les données.

Je ne vois pas comment on peut s'en assurer... si les données viennent de l'objet désérialisé, c'est la porte ouverte à n'importe quoi, mais je trouve le principe de cette classe très discutable.
Qu'on puisse programmatiquement faire une action particulière soit, mais dans un set d'actions prévues. Ces actions pourraient être définies dans un fichier de paramétrage (xml par exemple) ou par annotations mais "n'importe quelle action" ça me paraît être fou

[thelvin]

Là je trouve que ce n'est plus le problème de la désérialisation mais de la classe elle même, il ne faut pas jeter le mécanisme sous prétexte qu'on code n'importe quoi

Bah c'est pas pour rien qu'ils proposent un patch.

Cela dit, on peut quand même déplorer que le mécanisme ait rendu une telle chose possible. Ce n'était pas obligatoire : la plupart des systèmes de sérialisation/désérialisation sont nettement plus résistants à ce genre de choses, il faut que celui qui intègre une classe à son projet aille lister lui-même cette classe dans celles qui sont désérialisables par son action.

Évidemment, cela a été conçu avant qu'on sache que le futur pointerait vers des écosystèmes technologiques de cette ampleur.

[Gugelhupf]

syj,
Le pirate peut de toute façon t'envoyer ce qu'il veut (tout et n'importe quoi), le readObject() que tu as redéfinit continuera de faire ce qu'il fait habituellement, donc si ton readObject contient des méthodes sensibles (lecture/écriture sur le disque, communication par socket, exécution de méthode par reflexion etc) et que tu ne contrôle pas ce qu'on t'envoies, tu vas exécuter ce que tu n'aimerais pas que ton programme exécutes.

Si j'ai bien compris, pour réaliser une attaque moyennant cette faille, il faut avoir la main sur le serveur hébergeant le code Java pour modifier le fichier contenant l'objet serialisé!
Dans ce cas on ne peut pas parler d'une prise de contrôle à distance sans avoir déjà infecté la machine physique.

J'y ai pensé aussi, mais il ne faut pas forcément le prendre en ce sens, le fait que le pirate sache comment c'est fait coté serveur devrait lui suffire à dire si son attaque pourra passer le contrôle et être une réussite.

Dans un précédent post je disais que le "problème" évoqué venait de Java, mais j'étais hors contexte, Java est fait ça comme ça, on peut redéfinir une méthode readObject dans la classe de sérialisation. Autrement je suis allé dans la classe InvokerTransformer, elle n'a rien de bien méchant, c'est juste un wrapper pour invoquer des méthodes via la reflexion... mais ça peut être un problème si on l'utilise au mauvais endroit.

C'est pas pour être méchant mais le premier exemple donné par le chercheur n'est pas suffisamment explicite.

[hwoarang]

Je ne vois pas comment on peut s'en assurer...

Bah tout simplement en n'utilisant cette classe que sur des contenus sérializés présents sur le serveur dans des fichiers de config (mais jamais sur un fichier provenant d'un utilisateur)
Si on veut utiliser ce genre de chose sur du contenu utilisateur, la, je pense que j'aurais plutot fait un genre de set avec la liste des actions autorisées (un peu comme tu le suggeres).
Franchement, ce genre d'erreur me fait enormement penser à de l'injection SQL et je pensais pas qu'on pourrait retrouver ca dans du code apache...

C'est pas pour être méchant mais le premier exemple donné par le chercheur n'est pas suffisamment explicite.

L'exemple me parait meme tres mauvais. Il suggere que c'est la serialisation en général qui est en cause (en tout cas dans java) plutot que l'utilisation qui en est faite dans ce cas précis. Cet effet est amplifié par le fait qu'il affiche les données binaires du fichier sérialisé (qui ne sert à rien dans ce cas sinon à crier au loup).

[OButterlin]

Il suggere que c'est la serialisation en général qui est en cause (en tout cas dans java) plutot que l'utilisation qui en est faite dans ce cas précis. Cet effet est amplifié par le fait qu'il affiche les données binaires du fichier sérialisé (qui ne sert à rien dans ce cas sinon à crier au loup).

bien d'accord avec toi... c'est comme si on disait JDBC c'est nul parce que tu peux faire de l'injection si tu as codé avec les pieds