Je suis développeur Java depuis assez longtemps pour me souvenir de l’excitation lorsque Sun a introduit le concept de sérialisation dans la JVM. Dans le monde du C, nous pouvions simplement écrire une structure dans un fichier, mais cela était toujours problématique. Ce n’était pas portable et avait de nombreux problèmes. Mais pour Java, nous pouvions simplement écrire la classe, et cela « fonctionnait ». C’était de la pure magie !
Java était encore principalement utilisé côté client, et lorsque nous avons pensé à la sécurité, nous avions différentes vulnérabilités à l’esprit. Le bac à sable a occupé la plupart de nos discussions sur la sécurité. Avance rapide de quelques décennies, et aujourd’hui, alors que la plupart des développeurs discutent de la sérialisation, la discussion n’est pas si positive. La sérialisation, comme le dit Brian Vermeer, est : « le cadeau qui continue de donner ».
En fait, juste après avoir créé cette vidéo, une nouvelle vulnérabilité de désérialisation dans SnakeYaml a été exposée. La sérialisation est l’un des plus gros problèmes de sécurité dans de nombreux langages de programmation. ce n’est pas seulement un problème de JVM. Les pirates peuvent utiliser des outils conçus pour fournir une chaîne d’exploitation de sérialisation. Vous pouvez ensuite générer un gadget utilisé pour délivrer l’exploit sans trop connaître le système. C’est effrayant.
Je ne suis pas un expert en sécurité. Je me soucie plus de la solution. Comment s’assurer que le prochain jour zéro ne nous affecte pas ?
Comment renforcer notre code serveur contre les attaques de sérialisation ?
Avons-nous besoin de la sérialisation ?
Nous avons rarement besoin de sérialisation. Idéalement, si vous pouvez supprimer entièrement la sérialisation de votre code et éviter le code tiers qui utilise la sérialisation, vous pouvez la bloquer complètement. Cela signifie que même si un jour zéro se présente, la partie de sérialisation échouera. Vous pourriez avoir un bogue, mais ce ne sera pas une vulnérabilité exploitable.
Parfois, nous avons besoin d’un peu de sérialisation. Dans ce cas, nous pouvons inclure uniquement les classes bien connues nécessaires et bloquer tout le reste.
JEP 290 : Filtrage de sérialisation
La solution est venue dans Java 9 sous la forme d’un filtrage de sérialisation dans le cadre de JEP 290. Il existe des mises à jour de correctifs critiques pour les JDK plus anciens, tels que JDK 8u121. Donc si vous devez rester dans une ancienne version, il est toujours possible d’utiliser cette fonctionnalité.
Il est possible d’utiliser cette fonctionnalité sans modification du code, bien que nous souhaitions peut-être modifier le code pour des fonctionnalités supplémentaires. Le problème fondamental est de vérifier que les systèmes importants ne se cassent pas. Nous pourrions rencontrer des difficultés lors de la vérification de l’utilisation de la sérialisation, par exemple, dans les couches de mise en cache distribuées. Un cache peut sérialiser des objets pour les synchroniser entre les nœuds du réseau. Nous pourrions manquer cette dépendance lors de l’exécution de tests localement, mais échouer en production. Dans ces cas, vous pouvez suivre les stratégies énumérées ci-dessous pour résoudre les problèmes.
Liste blanche contre liste noire
Il existe deux approches que nous pouvons adopter lors du filtrage d’objets sérialisables spécifiques :
Une liste noire nous permet de bloquer des vulnérabilités bien connues, et cela pourrait suffire. Mais nous n’avons aucune garantie que nous avons tout bloqué. Une liste blanche est généralement l’option la plus sécurisée, mais elle peut casser votre code si vous avez manqué une classe requise dans un cas marginal.
Nous pouvons définir le filtre sur le JDK lui-même en éditant le fichier java. fichier de propriétés de sécurité. Cela peut avoir un sens si vous empaquetez un JDK avec votre application. Personnellement, je préfère utiliser l’argument de ligne de commande pour configurer cela, par exemple :
java “-Djdk.serialFilter=!*” -jar MyJar.jarCette commande bloquera toute sérialisation. Remarquez que je dois utiliser les guillemets pour empêcher bash d’étendre le signe astrologique. Le point d’exclamation signifie que nous souhaitons bloquer, et l’étoile signifie que nous bloquons tout.
Le code suivant est une liste noire. Nous bloquons un package spécifique. Nous pouvons également le réduire à une classe spécifique. Mais comme je l’ai déjà dit, ce n’est pas idéal:
java “-Djdk.serialFilter=!mypackage.*” -jar MyJar.jarOutre les problèmes inhérents à la liste noire, un problème majeur est de savoir quoi bloquer. Il y a des cibles évidentes comme des classes qui ont été vulnérables dans le passé, par exemple :
-
java.rmi.server.UnicastRemoteObject -
java.util.logging.Handler -
java.util.zip.Inflater -
org.apache.commons.collections.functors.InvokerTransformer -
org.apache.commons.collections4.functors.InvokerTransformer
Malheureusement, cette liste n’est pas exhaustive et je n’ai trouvé aucune liste que je puisse utiliser comme source pour une liste noire appropriée. Nous pouvons rechercher des exploits dans la base de données CVE (Common Vulnerabilities and Exposures), mais c’est un travail minutieux.
Enfin, nous avons une liste blanche où nous autorisons les classes sous le package mypackage. Nous pouvons les sérialiser comme d’habitude. La JVM bloque de manière transparente tout le reste. C’est assez proche de la situation idéale. Nous pouvons ajouter des classes et des packages supplémentaires si nécessaire en les ajoutant et en les séparant par un point-virgule :
java “-Djdk.serialFilter=mypackage.*;!*” -jar MyJar.jarQu’en est-il de la complexité ?
Comment savez-vous quelles classes sont sérialisées dans le code ? Comment recevoir une alerte si votre code a bloqué une tentative de sérialisation ? Cela pourrait être quelque chose que vous voudriez suivre car il pourrait s’agir d’une panne du système ou d’une tentative de piratage. Les deux sont des raisons valables pour une alerte. Vous ne pouvez pas le faire de manière déclarative, mais vous pouvez écrire du code qui peut utiliser une logique sophistiquée pour déterminer si la sérialisation doit réussir.
Ceci est un exemple de la documentation Oracle d’un filtre de sérialisation simple. Notez qu’il peut rejeter la sérialisation ou la laisser indécise. Cela fait partie d’une chaîne de filtrage où chaque étape du processus de validation peut rejeter la sérialisation ou la transmettre à l’étape suivante. Nous pouvons lier le filtre globalement comme nous le faisons ici ou le faire par flux. L’API est remarquablement flexible et fournit de nombreuses informations sur le processus :
ObjectInputFilter.Config.setSerialFilter(info -> info.depth() > 10 ? Status.REJECTED : Status.UNDECIDED); TL;DR
Vous devez toujours utiliser le filtrage de sérialisation lors de l’exécution d’un déploiement JVM. Cela devrait toujours être le cas.
Le filtrage de sérialisation a été rétroporté vers les anciennes versions de JVM, il n’y a donc absolument aucune excuse.
Le filtrage de sérialisation ne nécessite aucune modification du code et nous pouvons l’activer via la configuration globale ou la ligne de commande.
À tout le moins, vous pouvez l’utiliser pour mettre sur liste noire les vulnérabilités connues. Idéalement, nous devrions bloquer toutes les classes ou packages spécifiques de sérialisation et de liste blanche selon les besoins.