Un mot sur ImageTragick (CVE-2016-3714)
Tôt ce matin, un bug critique d’ImageMagick a été révélé, et il a rapidement été surnommé ImageTragick. Transloadit est sponsor et utilisateur de longue date d’ImageMagick, il n’est donc pas surprenant que l’on craigne que Transloadit puisse être touché par ce bug. Franchement, nous avions les mêmes craintes.
Pour l’instant, nous n’avons pas réussi à exploiter notre service avec ce bug, bien que le code de l’exploit n’ait pas encore été publié. L’enquête est toujours en cours, mais nous pouvons affirmer avec un certain degré de certitude que notre service ne devrait pas être touché. Avant même que ce bug d’ImageMagick ne soit connu, nous disposions déjà d’un système permettant de vérifier si un fichier présenté comme une image est réellement une image. Nous utilisons pour cela un logiciel appelé ExifTool, qui devrait offrir une protection suffisante contre tout exploit utilisant ce bug.
Nous avons depuis vérifié auprès de son auteur, Phil Harvey, qui nous a rassurés en ces termes :
ExifTool analyse le début du fichier pour déterminer son type. Pour la plupart des types, il s’agit simplement d’un test de nombre magique, comme vous l’avez mentionné, mais pour certains types sans nombre magique, un traitement est nécessaire. ExifTool n’utilise l’extension que comme un indice sur la variante précise du fichier lorsque plusieurs types de fichiers partagent le même format (par exemple ASF/WMV/WMA/DIVX ou DOC/PPT/XLA).
Si le fichier n’est pas reconnu, aucun MIMEType n’est renvoyé et ExifTool renvoie une erreur « Unknown file type ».
Ainsi, pour l’instant, en plus des solutions de contournement annoncées, cet outil protégera convenablement Transloadit, et vous pouvez continuer à utiliser notre service en toute sécurité.
Mais que se passera-t-il si, d’ici un mois ou deux, des vulnérabilités plus graves sont découvertes dans ImageMagick ? Ou dans ExifTool, d’ailleurs.
La question est assurément préoccupante. Tout outil a bien sûr son lot de bugs, et beaucoup de bugs peuvent être exploités. Ces bugs sont généralement corrigés rapidement et les utilisateurs sont censés mettre à jour dès que possible. Mais là encore, Transloadit ne peut pas toujours mettre à jour instantanément, car nous devons maintenir la rétrocompatibilité pour nos utilisateurs. Idéalement, nous voulons garder tous nos logiciels à jour, tout en dépréciant progressivement les anciennes versions et en les prenant en charge plus longtemps, afin que nos clients aient la possibilité de vérifier les nouvelles versions et de s’y adapter, plutôt que de subir des mises à jour soudaines du jour au lendemain.
Il est clair que nous devons limiter ce que nos outils peuvent faire (de travers), pour gagner du temps au cas où la prochaine vulnérabilité nous frapperait plus durement.
Depuis le tout début, nous exécutons nos outils sous un utilisateur système non privilégié, qui n’a pas accès aux clés secrètes. Les attaquants se trouveraient toutefois toujours sur le système hôte. Cela signifie que si un exploit root zero-day venait à apparaître, nous aurions des problèmes. Si nous pouvions ajouter davantage de couches de sécurité, ce serait donc encore mieux.
C’est pourquoi, parallèlement à l’évaluation de cette vulnérabilité et aux tentatives de mise au point d’un exploit, plusieurs membres de l’équipe ont commencé à conteneuriser nos outils d’encodage. Ainsi, nos outils n’ont accès à rien sur le système hôte, hormis les fichiers multimédias qu’ils doivent traiter. Cela nous permettrait même d’exécuter des outils vulnérables en production sans donner aux attaquants la possibilité d’espionner d’autres utilisateurs ou de causer de graves dommages d’une autre manière.
Ce travail prendra bien sûr un certain temps, et nous déploierons sa prise en charge progressivement.
Malheureusement, la sécurité à 100 % est un mythe, mais nous espérons que vous serez rassurés de savoir que nous faisons tout notre possible pour que Transloadit reste aussi sûr que possible. Si vous avez d’autres questions ou préoccupations à ce sujet, n’hésitez pas à nous contacter.
Mise à jour du 2016-07-01 : Nous avons constaté que, pour exécuter nos outils d’encodage de manière sécurisée dans des conteneurs, nous devrons attendre de pouvoir exécuter des tâches ponctuelles sans privilèges sudo. C’est en cours. En attendant, nous avons finalisé et déployé une mise à jour importante pour que nos machines d’encodage (qui seraient les plus exposées à ce type d’attaques) fonctionnent désormais sans aucun secret. Elles peuvent récupérer des Jobs dans une file d’attente via un accès en lecture seule, et les exporter via un accès en ajout seul. Tous les autres secrets et privilèges ont été supprimés.
Mise à jour du 2016-08-02 : Nous avons travaillé avec le chercheur en sécurité Florian Courtial pour ajouter un filtrage supplémentaire des images SVG malveillantes auxquelles nous étions encore vulnérables dans certains cas (même si, les machines d’encodage ayant été bridées, aucun dommage réel n’aurait pu être causé).