pagpapakilala
Ang Redis ay isang open-source, in-memory na data store na malawakang ginagamit bilang cache, message broker, at high-performance na database ng NoSQL. Nag-aalok ito ng mga rich data structures tulad ng mga string, hash, list, set, sorted set, bitmaps, HyperLogLogs, at stream, na sinusuportahan ng atomic operations at napakababang latency. Available ang pagtitiyaga sa pamamagitan ng mga snapshot ng RDB at AOF, at ang mataas na kakayahang magamit ay inihahatid sa pamamagitan ng pagtitiklop, Sentinel, at Cluster. Sinusuportahan din ng Redis ang server-side scripting kasama si Lua upang magsagawa ng mga kumplikadong operasyon sa atomically. Dahil sa bilis, flexibility, at mature na ecosystem nito, ginawa itong pangunahing building block para sa mga moderno, latency-sensitive na system.
Noong Oktubre 2025, inilabas ng Redis ang bersyon 8.2.2 , isang security release na nag-aayos ng apat na kahinaan sa naka-embed na Lua engine. Ang pinakamahalaga ay ang Lua use-after-free na maaaring magpahintulot sa mga attacker na makatakas sa scripting sandbox at magpatupad ng code sa host kapag ang mga hindi pinagkakatiwalaang user ay maaaring magpatakbo ng Lua nang walang katiyakan. Tinutugunan din ng release ang isang integer overflow sa unpack, isang cross-user script execution flaw, at isang out-of-bounds read sa Lua lexer. Sa post na ito, susuriin namin ang bawat CVE, tatalakayin ang mga patch , at ibabalangkas ang mga praktikal na hakbang upang palakasin ang iyong mga Redis deployment.
Pangkalahatang-ideya ng Mga Kahinaan
Bago sumisid sa code, narito ang mabilis na mapa kung ano ang inaayos ng 8.2.2 sa Lua engine.
CVE-2025-46817: Integer overflow sa pag-unpack (CVSS 9.8, Kritikal)
Ang mga matinding argumento na i-unpack(tbl, i, j) ay maaaring umapaw sa panloob na bilang ng mga halagang ibabalik. Maaaring lampasan ng sirang bilang na iyon ang mga stack check at humantong sa mga pag-crash o pagkasira ng memorya, na ginagawa itong isang kapaki-pakinabang na primitive para sa pagsasamantala.
CVE-2025-46818: Cross-user script execution sa pamamagitan ng shared runtime state (CVSS 7.3, High)
Ang mga maluwag na kontrol sa mga metatable at mga API na nauugnay sa kapaligiran ay nagbigay-daan sa isang script na maimpluwensyahan kung paano tumatakbo ang iba. Sa ilang mga pag-setup, nangangahulugan ito na ang isang hindi gaanong pribilehiyong user ay maaaring makaapekto sa pagpapatupad sa konteksto ng isa pang user, na nagpapahina sa paghihiwalay.
CVE-2025-46819: Binasa ang Lua out-of-bounds sa long-string parsing (CVSS 7.1, High)
Ang malutong na paghawak ng mga delimiter na may mahabang string/mahabang komento ([=[ … ]=], atbp.) sa Lua lexer ay maaaring itulak ito sa dulo ng buffer nito. Na maaaring mag-crash sa Redis at, sa mga gilid na kaso, ilantad ang kalapit na memorya.
CVE-2025-49844: Lua use-after-free sa parser (CVSS 10.0, Kritikal)
Maaaring manipulahin ng isang ginawang script ng Lua ang pagkolekta at pag-parse ng basura sa paraang maabot ang isang walang gamit na gamit sa naka-embed na Lua engine.
Susunod, titingnan natin ang bawat isa sa mga ito nang mas detalyado, kasama ang mga nauugnay na snippet ng patch
Sa loob ng mga pag-aayos: Malalim na pagsisid sa kahinaan
CVE-2025-46817: Integer overflow sa pag-unpack
Nakakaapekto ang isyung ito sa pag-unpack ng Lua 5.1(tbl, i, j) bilang naka-embed sa Redis. Sa matinding mga halaga ng i/j, ang pagkalkula ng "kung gaano karaming mga resulta ang ibabalik" ay maaaring umapaw, makagawa ng isang bogus na bilang, at makalampas sa mga stack check. Iyon ay maaaring humantong sa isang pag-crash o memory corruption at magagamit bilang isang building block patungo sa RCE sa mga masasamang sitwasyon.
Ang patch para sa CVE na ito ay maaaring tingnan dito: fc9abc7
Pagsusuri ng patch
Ginagawang tahasan at ligtas ng pag-aayos ang saklaw ng paghawak ng unpack.
- Ang pagkalkula ng bilang ay inilipat sa ligtas na unsigned na matematika
Bago ang patch :
static int luaB_unpack (lua_State *L) {
int i, e, n;
luaL_checktype(L, 1, LUA_TTABLE);
i = luaL_optint(L, 2, 1);
e = luaL_opt(L, luaL_checkint, 3, luaL_getn(L, 1));
kung (i > e) bumalik 0; /* walang laman na hanay */
n = e – i + 1; /* maaaring umapaw (lagdaan) */
kung (n <= 0 || !lua_checkstack(L, n))
ibalik ang luaL_error(L, "napakaraming resulta upang i-unpack");
/* push n resulta... */
}
Dito, tapos na ang e – i + 1 sa naka-sign int. Sa matinding mga halaga (hal. 0 at 2147483647), maaari itong umapaw, at ang n <= 0 ay hindi isang maaasahang bantay.
Pagkatapos ng patch :
static int luaB_unpack (lua_State *L) {
int i, e;
unsigned int n;
luaL_checktype(L, 1, LUA_TTABLE);
i = luaL_optint(L, 2, 1);
e = luaL_opt(L, luaL_checkint, 3, luaL_getn(L, 1));
kung (i > e) bumalik 0; /* walang laman na hanay */
n = (unsigned int)e – (unsigned int)i; /* mga elemento minus 1 */
kung (n >= INT_MAX || !lua_checkstack(L, ++n))
ibalik ang luaL_error(L, "napakaraming resulta upang i-unpack");
lua_rawgeti(L, 1, i); /* push arg[i] */
habang (i++ < e) {
lua_rawgeti(L, 1, i);
}
ibalik n;
}
Pangunahing puntos:
- Gumagamit ng unsigned int para sa span para maiwasan ang mga negatibo/umapaw na value.
- Tinatrato ang n bilang "bilang - 1" at mga pagtaas ng isang beses bago ang stack check.
- Nagpapatupad ng a mahirap itaas na hangganan (n >= INT_MAX → error).
- Tinitiyak na ang stack ay may puwang para sa lahat ng mga resulta bago pagtutulak ng kahit ano.
- Ang pag-index ng array ay ginawang tahasan
Kaugnay na paghihigpit sa code ng talahanayan:
Pagkatapos ng patch
if (1 <= key && key <= t->sizearray)
ibalik ang &t->array[key-1];
Sa halip na umasa sa isang unsigned cast trick, gumagamit ito ng malinaw na bounds check, na nag-iwas sa kakaibang gawi para sa malaki o negatibong mga index.
Kung magkakasama, ang mga pagbabagong ito ay nangangahulugan na ang matinding pag-unpack ng mga hanay ay hindi na nagiging sanhi ng mga nakabalot na bilang o hindi ligtas na mga pagtulak. Nabigo na ngayon ang malalaking tawag na may malinaw na error na "napakaraming resulta upang i-unpack" sa halip na ipagsapalaran ang pag-crash o pagkasira ng memorya.
CVE-2025-46819: Binasa ang Lua out-of-bounds sa long-string parsing
Ang isyung ito ay nasa lexer ni Lua, partikular sa kung paano ito nag-parse ng mahabang string at mahabang komento tulad ng [=[ … ]=]. Sa mga vulnerable na bersyon, maaaring itulak ang lexer sa dulo ng buffer ng input nito. Na maaaring mag-crash sa Redis (DoS), at sa ilang mga gilid na kaso ay maaaring maglantad ng mga byte mula sa kalapit na memorya.
Ang patch para sa CVE na ito ay maaaring tingnan dito: 3a1624d
Pagsusuri ng patch
Ang pag-aayos ay ginagawang mas mahigpit at hindi gaanong marupok ang long-string handling.
Ang pag-parse ng delimiter ay ginawang hindi malabo
Ang helper na nag-parse ng mga sequence tulad ng [===[ at ]===] ay ina-update upang gumamit ng mas ligtas na uri at magbalik ng malinaw, pare-parehong mga halaga:
Pagkatapos ng patch
static size_t skip_sep(LexState *ls) {
sukat_t bilang = 0;
int s = ls->kasalukuyan; /* '[' o ']' */
lua_assert(s == '[' || s == ']');
save_and_next(ls); /* ubusin mo */
habang (ls->kasalukuyang == '=') { /* bilang '=' */
save_and_next(ls);
bilang++;
}
kung ang (ls->kasalukuyang == s) /* ay tumugma sa pangalawang '[' o ']' */
bilang ng pagbalik + 2; /* wastong mahabang delimiter */
else if (bilang == 0)
bumalik 1; /* hindi isang mahabang string/komento */
iba
bumalik 0; /* malformed */
}
- Ang mga wastong long-string delimiter ay nagbabalik na ngayon ng isang mahusay na tinukoy na haba (>= 2).
- Plain [ bumagsak nang malinis (1).
- Maling nabuo [==… pattern ay nagbabalik ng 0 at itinuturing bilang mga error.
Isinasara nito ang puwang kung saan ang mga kakaiba o hindi kumpletong pattern ay maaaring malito ang lexer sa pagbabasa sa kabila ng buffer.
Ang mga offset para sa paghiwa ng katawan ay naitama
Kapag kinukuha ang aktwal na nilalaman ng string, inihanay ng patch ang slice math sa resulta ng skip_sep:
Pagkatapos ng patch:
kung (seminfo) {
semifo->ts = luaX_newstring(
ls,
luaZ_buffer(ls->buff) + sep,
luaZ_bufflen(ls->buff) – 2 * sep
);
}
Dati, ang mga offset ay hindi wastong tumugma sa delimiter semantics, na maaaring humantong sa banayad na off-by-N na pag-uugali. Ngayon ang simula at haba ay direktang hinango mula sa sep, kaya ang lexer ay nananatili sa loob ng mga hangganan.
Ang mga uri ay tumutugma sa kung ano talaga ang ginagawa ng code
Gumagamit na ngayon ang mga counter at index na kasangkot sa logic na ito ng mga naaangkop na uri ng hindi nilagdaan/laki sa halip na mga overload na naka-sign na ints, na binabawasan ang panganib ng mga negatibong halaga o ang wraparound na gumagapang sa pointer arithmetic.
Nangangahulugan ang lahat ng ito na kahit na may malalaking o sinadyang sira [=…=[ … ]=…=] na mga sequence, maaaring i-parse ngayon ni Lua ang mga ito nang tama o tinatanggihan ang mga ito nang may normal na error. Wala nang landas kung saan ang isang pagalit na script ay maaaring itulak ang lexer sa pagtingin sa dulo ng buffer.
CVE-2025-46818: Maaaring tumakbo ang script ng Lua sa konteksto ng isa pang user
Ang isyung ito ay tungkol sa pagpapanatili ng saklaw ng mga Lua script sa user at environment na kinabibilangan nila . Sa mga vulnerable na bersyon, ang mga shared runtime elements—tulad ng mga metatable sa mga core type at legacy environment API—ay sapat na maluwag kaya maaaring maimpluwensyahan ng isang script kung paano tumatakbo ang iba. Sa ilang deployment, maaari nitong malabo ang paghihiwalay sa pagitan ng mga user.
Ang patch para sa CVE na ito ay maaaring tingnan dito: 45eac02
Pagsusuri ng patch
Ang pag-aayos ay may dalawang pangunahing ginagawa: pinoprotektahan ang mga core metatable at nilo-gate ang mga risky legacy API.
- Ang mga pangunahing uri ng metatable ay protektado
Dati, ang mga pangunahing uri ng Lua na nakalantad sa mga script (mga string, numero, boolean, atbp.) ay walang mahigpit na hadlang na pumipigil sa mga metatable na pagbabago mula sa mga script ng user. Nangangahulugan iyon na ang isang pagbabago sa isang nakabahaging metatable ay maaaring makaapekto sa iba pang code na tumatakbo sa parehong engine.
Ang naka-patch na code ay tahasang nagpapatigas sa mga metatable na iyon sa panahon ng pag-setup ng kapaligiran ng Lua. Sa pinasimpleng anyo:
Naka-patch na code: markahan ang mga primitive na metatable bilang protektado
static void luaProtectPrimitiveMetatables(lua_State *L) {
const int type[] = {LUA_TSTRING, LUA_TNUMBER, LUA_TBOOLEAN, LUA_TNIL};
para sa (size_t i = 0; i < sizeof(types)/sizeof(types[0]); i++) {
luaL_getmetatable(L, lua_typename(L, mga uri[i]));
kung (!lua_isnil(L, -1)) {
lua_pushliteral(L, “protektado”);
lua_setfield(L, -2, “__metatable”); /* lock metatable */
}
lua_pop(L, 1);
}
}
Ang proteksyong __metatable na ito ay nangangahulugan na makikita pa rin ng mga script ng user ang mga ganitong uri ngunit hindi maaaring palitan o isulat muli ang kanilang mga metatable sa buong mundo. Anumang pagtatangka na gawin ito ay mabibigo nang malinis sa halip na tahimik na baguhin ang gawi para sa lahat.
- Ang mga legacy environment API ay tahasang nag-opt in
Ang mga lumang Lua API na kayang manipulahin ang mga kapaligiran ay hindi na pinagana bilang default at ipinapakita lamang kapag tahasang pinagana ng isang operator ang mga ito.
Sa konsepto, ang pagbabago ay ganito:
Bago mag-patch: ang mga hindi na ginagamit na API ay palaging available sa script env
static const luaL_Reg redis_compat_funcs[] = {
{“getfenv”, luaB_getfenv},
{“setfenv”, luaB_setfenv},
{“newproxy”, luaB_newproxy},
{NULL, NULL}
};
scriptCreateEnv(…) {
luaL_register(L, “_G”, redis_compat_funcs);
}
Pagkatapos ng patch: magrehistro lamang kapag naitakda ang lua-enable-deprecated-api
scriptCreateEnv(…) {
kung (server.lua_enable_deprecated_api) {
luaL_register(L, “_G”, redis_compat_funcs);
}
}
Kung ang lua-enable-deprecated-api ay hindi pinagana, ang mga function na ito ay wala lang sa script environment, na nag-aalis ng malakas na hanay ng mga lever para sa cross-context manipulation.
Kung magkakasama, tinitiyak ng mga pagbabagong ito:
- Ang mga script ay hindi maaaring tahimik na mag-patch ng pangunahing gawi para sa lahat ng iba pang mga script sa pamamagitan ng muling pagsusulat ng mga pangunahing metatable.
- Environment-manipulation primitives ay lamang magagamit kung sinasadya ng isang operator na i-on ang mga ito.
Ginagawa nitong mas predictable ang runtime ng Lua at pinapanatili nitong mas malapit ang bawat script sa nilalayon nitong pribilehiyo at konteksto—mahalaga para sa anumang shared o multi-tenant na deployment ng Redis.
CVE-2025-49844: Lua use-after-free sa parser
Ang bug na ito ay nabubuhay sa kung paano isinasama ng Redis ang parser ni Lua. Sa ilalim ng mga partikular na kundisyon, ang isang ginawang script ng Lua ay maaaring magpalitaw ng koleksyon ng basura sa maling oras at ipabasa sa Redis ang isang pointer sa memorya na na-freeze na.
Ang patch para sa CVE na ito ay maaaring tingnan dito: d5728cb5795
Pagsusuri ng patch
Ang pangunahing pagbabago ay ang Redis na ngayon ay nagpapanatili ng isang wastong reference sa mga bagay na Lua na ginagamit ng parser (tulad ng chunk name) sa Lua stack habang nag-parse, kaya nakikita ng basurero na buhay ang mga ito at hindi maaaring palayain o ilipat ang mga ito nang maaga.
Noong nakaraan, ang tipak na "pangalan" ay ginawa sa linya at direktang ipinasa sa lexer:
luaX_setinput(L, &lexstate, z, luaS_new(L, pangalan));
Dahil ang value na iyon ay hindi malinaw na naka-angkla (halimbawa, sa Lua stack), ang isang hindi mapalad na interleaving ng GC o defrag at agresibong scripting, sa teorya, ay maaaring mag-iwan sa parser na may hawak na pointer sa isang bagay na inilipat o napalaya.
Ginagawang tahasan ng na-patch na code ang pagmamay-ari na iyon:
TString *tname = luaS_new(L, pangalan);
setsvalue2s(L, L->itaas, tname); /* panatilihing buhay ang pangalan sa stack */
incr_top(L);
luaX_setinput(L, &lexstate, z, tname); /* ligtas itong gamitin para sa pag-lex/pag-parse */
/* … i-parse ang tipak … */
–L->itaas; /* i-drop ang reference kapag tapos na */
Sa pamamagitan ng pagpapanatiling naka-reference ang estado na ito para sa buong pag-parse, tinatrato na ito ng GC at defrag bilang live at hindi na ito mabawi o mailipat sa kalagitnaan ng paglipad. Iyon ay epektibong nag-aalis sa makitid na window ng timing na naging posible ang paggamit-pagkatapos-libre.
Nanganganib ang mga senaryo ng deployment
Ang mga isyung ito ay partikular na nauugnay sa mga kapaligiran kung saan:
- Gumagamit ang mga application ng Lua scripting sa Redis.
- Ang parehong Redis cluster ay ibinabahagi sa mga koponan o nangungupahan.
- Maaaring maabot ang Redis, direkta o sa pamamagitan ng iyong application - mula sa hindi pinagkakatiwalaan o kontrolado ng user na input.
Mga inirerekomendang aksyon
1. Patch muna
- Mag-upgrade sa na-patch na Redis 8.2.2 build.
- Tratuhin ito bilang mataas na priyoridad saanman ang hindi pinagkakatiwalaan o semi-pinagkakatiwalaang code ay maaaring magpatakbo ng Lua (halimbawa sa pamamagitan ng EVAL / SCRIPT LOAD) o kung saan ibinabahagi ang mga cluster ng Redis sa mga team/tenant.
2. I-lock down ang pag-script ng Lua
- Gumamit ng mga ACL upang paghigpitan ang pag-script ng Lua sa mga pinagkakatiwalaang serbisyo lamang.
- Panatilihin ang Redis sa mga pribadong network, walang direktang pagkakalantad sa internet.
- Iwanang naka-disable ang lua-enable-deprecated-api maliban kung mayroon kang malinaw, na-audit na pangangailangan.
3. I-segment ang mga sensitibong workload
- Patakbuhin ang hindi pinagkakatiwalaan o hinihimok ng customer na Lua sa magkahiwalay na mga pagkakataon ng Redis.
- Huwag paghaluin ang mga script na kinokontrol ng nangungupahan sa mga cluster na naglalaman ng kritikal o sensitibong data.
4. Gumamit ng mga kontrol sa seguridad para magdagdag ng visibility (hindi bilang kapalit ng pag-patch)
- I-configure ang IPS/ID/WAF para makita at harangan ang direktang pag-access sa Redis at kahina-hinalang paggamit ng Redis protocol.
- Gumamit ng proteksyon ng EDR/AV/runtime sa mga host ng Redis para makita ang pag-uugaling tulad ng pagsasamantala
Sanggunian:
Mga May-akda:
Vinay Kumar
Adrip Mukherjee
Nandini Seth
Suvarnjeet Jagtap
