Correction de bogue : Lua et MessagePack

Correction de bogue : Lua et MessagePack

Apple Vulnerability Research nous a informés d’un bogue potentiellement exploitable dans Redis en mai 2018. Nous avons pris cette divulgation très au sérieux et avons consacré des ressources pour résoudre correctement ce problème. Nous sommes heureux de vous annoncer que Salvatore Sanfilippo (le créateur et développeur principal de Redis open source) a créé le correctif pour les utilisateurs open source et a contacté tous les principaux fournisseurs Redis. Nous avons appliqué le correctif à toutes nos offres Redis Enterprise : Cloud, VPC et logiciels.

Quel est le bogue ?

Contexte : Redis intègre Lua pour les scripts au niveau de la base de données. Le moteur de script Lua comprend un certain nombre de bibliothèques pertinentes pour les cas d’utilisation de Redis. Le bogue original trouvé était lié à la bibliothèque MsgPack, une implémentation du format de sérialisation MessagePack. MessagePack est similaire à JSON, mais est plus économe en espace car il s’appuie sur l’encodage binaire pour le contrôle et, si possible, sur les valeurs elles-mêmes.

Une fonction qui accepte un nombre variable d’arguments (variadic) est disponible en Lua pour “emballer” un message en utilisant le format MessagePack. L’implémentation derrière cette fonction variadique ne vérifie pas correctement la disponibilité de la pile. Sans cette vérification, un très grand nombre d’arguments peut être passé dans cette fonction et provoquer un débordement. En raison de la nature de Redis, il est possible que ces données provenant directement d’un utilisateur non fiable soient acceptées et traitées de cette manière.

Il n’y a pas d’exploits “dans la nature” connus de ce bogue. En raison de la nature de ce bogue, comme pour toute situation de débordement, il est théoriquement possible d’exécuter du code à distance, mais cela devrait cibler des versions très spécifiques de Redis dans des scénarios très spécifiques. Nous n’avons été informés d’aucune preuve de concept de ce comportement. Plus probablement, ce bogue pourrait être exploité pour provoquer une instabilité ou un plantage du serveur Redis.

Y a-t-il des bugs associés ?

Au cours du processus de révision, il est d’usage de passer en revue d’autres parties de la base de code pour les erreurs associées. Au cours de ce processus, Salvatore, assisté de la communauté OSS, a trouvé des bogues similaires dans l’implémentation Lua de l’emballage et du déballage d’autres structures. Des correctifs ont également été implémentés pour résoudre ces problèmes.

Apple Vulnerability Research a également soulevé un problème concernant la configuration à distance de Sentinel en tant que risque de sécurité. Nous ne sommes pas d’accord avec cette conclusion car Redis permet spécifiquement et explicitement la configuration à distance, étant entendu que Sentinel ne doit pas être accessible par une adresse publique.

De plus, Redis Enterprise n’utilise pas Sentinel pour la haute disponibilité mais plutôt d’autres mécanismes internes, donc cette découverte n’a aucun effet sur les utilisateurs de Redis Enterprise.

Suis-je vulnérable ?

Toutes les versions non corrigées de Redis après 2.8.18 sont potentiellement affectées. Pour être à risque, vous devez utiliser à la fois Lua et permettre directement aux entrées utilisateur illimitées d’être transmises aux scripts de manière très spécifique. Bien que nous pensons qu’il s’agit d’une très petite fraction d’utilisateurs utilisant ces fonctionnalités ensemble de cette manière, nous suggérons tout de même à tout le monde d’appliquer le correctif pour empêcher les futurs vecteurs d’attaque sur les systèmes non corrigés.

Comment fonctionne le patch ?

Le correctif ajoute la vérification appropriée de la disponibilité de la pile et renvoie une erreur si un script Lua tente de compresser un message trop volumineux. Cela garantit qu’au moment de l’exécution, cette attaque particulière sera impossible.

Suivi supplémentaire

Nous avons vérifié d’autres parties de Redis pour des bogues similaires et jusqu’à présent, je n’ai trouvé aucun autre bogue avec le même profil de risque.

Si je suis un utilisateur Redis Enterprise (Cloud/VPC/Logiciel), que dois-je faire ?

De manière générale, tant que vous utilisez l’un de nos mécanismes de contrôle d’accès (Cloud Security Group) et d’authentification (SSL, Mot de passe)/contrôle d’accès (SIP), votre Redis doit être sécurisé. De plus, si votre application n’utilise pas les scripts Lua, vous ne devriez rencontrer aucun problème. Et même si votre application utilise Lua, ce bug se produit dans des conditions extrêmes et uniquement si votre application appelle Lua avec un très grand nombre d’arguments. Comme ce bogue existait depuis l’annonce de la prise en charge de Lua dans Redis (en 2014), nous pensons que vous n’avez probablement jamais rencontré le problème auparavant et à moins que votre application ne soit radicalement modifiée, la probabilité que cela affecte votre déploiement Redis est extrêmement faible. De plus, Redis Enterprise est livré avec des mécanismes intégrés de réplication, de basculement automatique et de persistance des données qui garantissent la haute disponibilité et la durabilité de vos données en cas de défaillance de Redis.

Cela dit, nous avons corrigé nos déploiements Redis Cloud et VPC, et si vous avez d’autres questions, veuillez contacter support@redis.com pour vérifier si votre déploiement n’est pas à risque. Si vous utilisez le logiciel Redis Enterprise dans un déploiement sur site, vous pouvez télécharger la dernière version de Redis Enterprise qui inclut le correctif de vulnérabilité à partir de ici.

Enfin, assurez-vous que votre base de données Redis Enterprise est protégés par mot de passe et les mécanismes de contrôle d’accès et d’authentification.

Si je suis un utilisateur open source Redis, que dois-je faire ?

Nous suggérons aux utilisateurs open source de s’assurer d’abord que toutes les instances Redis ne sont pas ouvertes sans restriction à Internet, puis de passer à la dernière version de Redis (3.2.12, 4.0.10 ou 5.0-rc2, au moment de la rédaction) qui peut être trouvé sur le page de téléchargement redis.io.

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *