রেডিস ৮.২.২: চারটি গুরুত্বপূর্ণ দুর্বলতার বিরুদ্ধে লুয়া ইঞ্জিনকে শক্তিশালী করা

ভূমিকা

রেডিস একটি ওপেন-সোর্স, ইন-মেমোরি ডেটা স্টোর যা ক্যাশে, মেসেজ ব্রোকার এবং উচ্চ-কার্যক্ষমতাসম্পন্ন NoSQL ডাটাবেস হিসেবে ব্যাপকভাবে ব্যবহৃত হয়। এটি স্ট্রিং, হ্যাশ, তালিকা, সেট, সাজানো সেট, বিটম্যাপ, হাইপারলগলগ এবং স্ট্রিমগুলির মতো সমৃদ্ধ ডেটা স্ট্রাকচার অফার করে, যা পারমাণবিক ক্রিয়াকলাপ এবং খুব কম ল্যাটেন্সি দ্বারা সমর্থিত। RDB স্ন্যাপশট এবং AOF এর মাধ্যমে স্থায়িত্ব পাওয়া যায় এবং রেপ্লিকেশন, সেন্টিনেল এবং ক্লাস্টারের মাধ্যমে উচ্চ প্রাপ্যতা প্রদান করা হয়। রেডিস পারমাণবিকভাবে জটিল ক্রিয়াকলাপ সম্পাদনের জন্য লুয়ার সাথে সার্ভার-সাইড স্ক্রিপ্টিংও সমর্থন করে। এর গতি, নমনীয়তা এবং পরিপক্ক ইকোসিস্টেম এটিকে আধুনিক, ল্যাটেন্সি-সংবেদনশীল সিস্টেমের জন্য একটি মূল বিল্ডিং ব্লক করে তুলেছে।

২০২৫ সালের অক্টোবরে, রেডিস সংস্করণ ৮.২.২ প্রকাশ করেছে , যা একটি নিরাপত্তা রিলিজ এবং এটি এমবেডেড লুয়া ইঞ্জিনের চারটি দুর্বলতা সংশোধন করে। এর মধ্যে সবচেয়ে গুরুতর হলো একটি লুয়া ইউজ-আফটার-ফ্রি ত্রুটি, যা আক্রমণকারীদের স্ক্রিপ্টিং স্যান্ডবক্স থেকে বেরিয়ে আসতে এবং হোস্টে কোড এক্সিকিউট করতে সাহায্য করে, যখন অবিশ্বস্ত ব্যবহারকারীরাও যেকোনো লুয়া কোড চালাতে পারে। এই রিলিজে আনপ্যাক-এ একটি ইন্টিজার ওভারফ্লো, একাধিক ব্যবহারকারীর মধ্যে স্ক্রিপ্ট এক্সিকিউশনের একটি ত্রুটি এবং লুয়া লেক্সারে একটি আউট-অফ-বাউন্ডস রিড সমস্যারও সমাধান করা হয়েছে। এই পোস্টে, আমরা প্রতিটি CVE বিশদভাবে আলোচনা করব, প্যাচগুলো ধাপে ধাপে দেখাব এবং আপনার রেডিস ডেপ্লয়মেন্টকে আরও সুরক্ষিত করার জন্য কিছু বাস্তব পদক্ষেপের রূপরেখা তুলে ধরব।

দুর্বলতাগুলির সংক্ষিপ্তসার

কোডে ডুব দেওয়ার আগে, লুয়া ইঞ্জিনে 8.2.2 কী কী সংশোধন করে তার একটি দ্রুত মানচিত্র এখানে দেওয়া হল।

CVE-2025-46817: আনপ্যাকের মধ্যে পূর্ণসংখ্যা ওভারফ্লো (CVSS 9.8, ক্রিটিক্যাল)
(tbl, i, j) আনপ্যাক করার জন্য চরম আর্গুমেন্টগুলি অভ্যন্তরীণ গণনার মানগুলিকে ওভারফ্লো করতে পারে যা ফেরত পাঠানো হবে। সেই ভাঙা গণনা স্ট্যাক চেকগুলিকে বাইপাস করতে পারে এবং ক্র্যাশ বা মেমরি দুর্নীতির দিকে পরিচালিত করতে পারে, যা এটিকে শোষণের জন্য একটি কার্যকর আদিম করে তোলে।

CVE-2025-46818: শেয়ার্ড রানটাইম স্টেটের মাধ্যমে ক্রস-ইউজার স্ক্রিপ্ট এক্সিকিউশন (CVSS 7.3, উচ্চ)
মেটাটেবল এবং পরিবেশ-সম্পর্কিত API-এর চারপাশে শিথিল নিয়ন্ত্রণের ফলে একটি স্ক্রিপ্ট অন্য স্ক্রিপ্টগুলি কীভাবে কাজ করে তা প্রভাবিত করতে পারে। কিছু সেটআপে, এর অর্থ হল একজন কম সুবিধাপ্রাপ্ত ব্যবহারকারী অন্য ব্যবহারকারীর প্রসঙ্গে কার্যকরকরণকে প্রভাবিত করতে পারে, যার ফলে বিচ্ছিন্নতা দুর্বল হয়ে পড়ে।

CVE-2025-46819: লং-স্ট্রিং পার্সিংয়ে লুয়া আউট-অফ-বাউন্ড পঠিত (CVSS 7.1, উচ্চ)
লুয়া লেক্সারে লং-স্ট্রিং/লং-কমেন্ট ডিলিমিটার ([=[ … ]=], ইত্যাদি) এর ভঙ্গুর হ্যান্ডলিং এটিকে তার বাফারের শেষের দিকে ঠেলে দিতে পারে। এটি রেডিসকে ক্র্যাশ করতে পারে এবং প্রান্তের ক্ষেত্রে, কাছাকাছি মেমরি প্রকাশ করতে পারে।

CVE-2025-49844: পার্সারে লুয়া ব্যবহার-পরবর্তী-মুক্ত (CVSS 10.0, সমালোচনামূলক)
একটি তৈরি লুয়া স্ক্রিপ্ট আবর্জনা সংগ্রহ এবং পার্সিংকে এমনভাবে পরিচালনা করতে পারে যা এমবেডেড লুয়া ইঞ্জিনে ব্যবহার-পরবর্তী-মুক্তিতে আঘাত করে।

এরপর, আমরা প্রাসঙ্গিক প্যাচ স্নিপেট সহ এই প্রতিটি বিষয় আরও বিশদে দেখব।

সমাধানের ভেতরের দিকগুলো: দুর্বলতার গভীরে অনুসন্ধান

CVE-2025-46817: আনপ্যাকের মধ্যে পূর্ণসংখ্যা ওভারফ্লো

এই সমস্যাটি Redis-এ এমবেড করা Lua 5.1-এর unpack(tbl, i, j) কে প্রভাবিত করে। চরম i/j মান সহ, "কত ফলাফল ফেরত দিতে হবে" এর গণনা ওভারফ্লো হতে পারে, একটি জাল গণনা তৈরি করতে পারে এবং স্ট্যাক চেকগুলি অতিক্রম করতে পারে। এটি ক্র্যাশ বা মেমরি দুর্নীতির দিকে পরিচালিত করতে পারে এবং প্রতিকূল পরিস্থিতিতে RCE-এর দিকে একটি বিল্ডিং ব্লক হিসাবে ব্যবহারযোগ্য।

এই CVE-এর প্যাচটি এখানে পাওয়া যাবে: fc9abc7

প্যাচ বিশ্লেষণ

এই সমাধানটি আনপ্যাকের রেঞ্জ হ্যান্ডলিংকে স্পষ্ট এবং নিরাপদ করে তোলে।

1. গণনা গণনা নিরাপদ স্বাক্ষরবিহীন গণিতে স্যুইচ করা হয়েছে

প্যাচ করার আগে :

স্ট্যাটিক 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));

যদি (i > e) 0 প্রদান করে; /* খালি পরিসর */

n = e – i + 1; /* ওভারফ্লো হতে পারে (স্বাক্ষরিত) */

যদি (n <= 0 || !lua_checkstack(L, n))

luaL_error(L, “অনেক বেশি ফলাফল আনপ্যাক করার জন্য”) রিটার্ন করুন;

/* পুশ এন ফলাফল… */

}

এখানে, e – i + 1 signed int-এ করা হয়েছে। চরম মান (যেমন 0 এবং 2147483647) সহ, এটি ওভারফ্লো হতে পারে এবং n <= 0 একটি নির্ভরযোগ্য গার্ড নয়।

প্যাচের পরে :

স্ট্যাটিক int luaB_unpack (lua_State *L) {

int i, e;

স্বাক্ষরবিহীন 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));

যদি (i > e) 0 প্রদান করে; /* খালি পরিসর */

n = (অস্বাক্ষরিত int)e – (অস্বাক্ষরিত int)i; /* উপাদান বিয়োগ ১ */

যদি (n >= INT_MAX || !lua_checkstack(L, ++n))

luaL_error(L, “অনেক বেশি ফলাফল আনপ্যাক করার জন্য”) রিটার্ন করুন;

lua_rawgeti(L, 1, i); /* পুশ arg[i] */

যখন (i++ < e) {

লুয়া_রাগেটি(এল, ১, আই);

}

ফেরত n;

}

গুরুত্বপূর্ণ দিক:

• নেতিবাচক/ওভারফ্লোড মান এড়াতে স্প্যানের জন্য unsigned int ব্যবহার করে।
• স্ট্যাক চেকের আগে n কে "গণনা - 1" হিসেবে বিবেচনা করে এবং একবার বৃদ্ধি করে।
• একটি প্রয়োগ করে শক্ত উপরের বাউন্ড (n >= INT_MAX → ত্রুটি)।
• নিশ্চিত করে যে স্ট্যাকে সমস্ত ফলাফলের জন্য জায়গা আছে আগে যেকোনো কিছু ঠেলে দেওয়া।

1. অ্যারে ইন্ডেক্সিং স্পষ্ট করা হয়েছে

টেবিল কোডে সম্পর্কিত শক্তকরণ:

প্যাচের পরে

যদি (১ <= কী && কী <= t-> আকারের অ্যারে)

রিটার্ন &t->অ্যারে[কী-১];

একটি স্বাক্ষরবিহীন কাস্ট ট্রিকের উপর নির্ভর করার পরিবর্তে, এটি একটি স্পষ্ট সীমানা পরীক্ষা ব্যবহার করে, যা বিশাল বা নেতিবাচক সূচকের জন্য অদ্ভুত আচরণ এড়ায়।

একসাথে, এই পরিবর্তনগুলির অর্থ হল চরম আনপ্যাক রেঞ্জগুলি আর র‍্যাপড কাউন্ট বা অনিরাপদ পুশের কারণ হবে না। ওভারসাইজড কলগুলি এখন ব্যর্থ হয় এবং ক্র্যাশ বা মেমরি দুর্নীতির ঝুঁকির পরিবর্তে "অনেক বেশি ফলাফল আনপ্যাক করার জন্য" ত্রুটি দেখা দেয়।

CVE-2025-46819: লং-স্ট্রিং পার্সিংয়ে লুয়া আউট-অফ-বাউন্ড পঠিত

এই সমস্যাটি লুয়ার লেক্সারে অবস্থিত, বিশেষ করে এটি কীভাবে লম্বা স্ট্রিং এবং [=[ … ]=] এর মতো লম্বা মন্তব্য পার্স করে। দুর্বল সংস্করণগুলিতে, কিছু ত্রুটিপূর্ণ বা চরম ডিলিমিটার প্যাটার্ন লেক্সারকে তার ইনপুট বাফারের শেষের দিকে ঠেলে দিতে পারে। এটি Redis (DoS) ক্র্যাশ করতে পারে এবং কিছু প্রান্তের ক্ষেত্রে কাছাকাছি মেমরি থেকে বাইট প্রকাশ করতে পারে।

এই CVE-এর প্যাচটি এখানে উল্লেখ করা হলো: 3a1624d

প্যাচ বিশ্লেষণ

এই সংশোধন দীর্ঘ-স্ট্রিং হ্যান্ডলিংকে আরও কঠোর এবং কম ভঙ্গুর করে তোলে।

ডিলিমিটার পার্সিং দ্ব্যর্থহীন করা হয়েছে

[===[ এবং ]===] এর মতো ক্রমগুলিকে পার্স করে এমন সহায়কটি একটি নিরাপদ টাইপ ব্যবহার করে এবং স্পষ্ট, সামঞ্জস্যপূর্ণ মান প্রদান করে আপডেট করা হয়েছে:

প্যাচের পরে

স্ট্যাটিক সাইজ_টি স্কিপ_সেপ (লেক্সস্টেট *এলএস) {

আকার_টি গণনা = 0;

int s = ls->বর্তমান; /* '[' অথবা ']' */

লুয়া_আসর্ট(গুলি == '[' || গুলি == ']');

save_and_next(ls); /* এটি গ্রাস করুন */

while (ls->current == '=') { /* count '=' */

সংরক্ষণ_এবং_পরবর্তী(ls);

গণনা++;

}

যদি (ls->বর্তমান == s) /* দ্বিতীয় '[' অথবা ']' এর সাথে মিলে যায় */

রিটার্ন কাউন্ট + ২; /* বৈধ দীর্ঘ ডিলিমিটার */

অন্যথায় যদি (গণনা == 0)

১ রিটার্ন করুন; /* লম্বা স্ট্রিং/মন্তব্য নয় */

আর

০ রিটার্ন করুন; /* বিকৃত */

}

• বৈধ লং-স্ট্রিং ডিলিমিটারগুলি এখন একটি সু-সংজ্ঞায়িত দৈর্ঘ্য (>= 2) প্রদান করে।
• সরল [ পরিষ্কারভাবে ফিরে আসে (1)।
• ত্রুটিপূর্ণ [==… প্যাটার্নগুলি 0 প্রদান করে এবং ত্রুটি হিসাবে বিবেচিত হয়।

এটি সেই ফাঁকটি বন্ধ করে দেয় যেখানে বিজোড় বা অসম্পূর্ণ প্যাটার্নগুলি লেক্সারকে বাফারের বাইরে পড়তে বিভ্রান্ত করতে পারে।

শরীর কাটার জন্য অফসেটগুলি সংশোধন করা হয়েছে

প্রকৃত স্ট্রিং কন্টেন্ট বের করার সময়, প্যাচটি skip_sep ফলাফলের সাথে স্লাইস ম্যাথকে সারিবদ্ধ করে:

প্যাচের পরে:

যদি (সেমিনফো) {

সেমিনফো->টিএস = লুয়াএক্স_নিউজস্ট্রিং(

ls,

luaZ_buffer(ls->buff) + সেপ্টেম্বর,

luaZ_bufflen(ls->বাফ) – 2 * sep

);

}

পূর্বে, অফসেটগুলি ডিলিমিটার শব্দার্থবিদ্যার সাথে সঠিকভাবে মেলে না, যার ফলে সূক্ষ্ম অফ-বাই-এন আচরণ হতে পারে। এখন শুরু এবং দৈর্ঘ্য সরাসরি sep থেকে নেওয়া হয়েছে, তাই লেক্সার সীমানার মধ্যে থাকে।

কোডটি আসলে যা করে তার সাথে প্রকারগুলি মিলে যায়

এই লজিকের সাথে জড়িত কাউন্টার এবং ইনডেক্সগুলি এখন ওভারলোডেড সাইনড ইনটের পরিবর্তে উপযুক্ত আনসাইনড/সাইজ টাইপ ব্যবহার করে, যা নেতিবাচক মান বা পয়েন্টার অ্যারিথেমেটিকের মধ্যে মোড়ক রেখার ঝুঁকি হ্রাস করে।

এর অর্থ হল, বিশাল বা ইচ্ছাকৃতভাবে ভাঙা [=…=[ … ]=…=] সিকোয়েন্স থাকা সত্ত্বেও, লুয়া এখন হয় সেগুলিকে সঠিকভাবে পার্স করে অথবা একটি সাধারণ ত্রুটির মাধ্যমে প্রত্যাখ্যান করে। এমন কোনও পথ আর নেই যেখানে একটি প্রতিকূল স্ক্রিপ্ট লেক্সারকে বাফারের শেষের দিকে তাকাতে বাধ্য করতে পারে।

CVE-2025-46818: লুয়া স্ক্রিপ্ট অন্য ব্যবহারকারীর প্রসঙ্গে চলতে পারে

এই সমস্যাটি হলো লুয়া স্ক্রিপ্টগুলোকে তাদের ব্যবহারকারী এবং পরিবেশের মধ্যে সীমাবদ্ধ রাখা । ঝুঁকিপূর্ণ সংস্করণগুলোতে, শেয়ার করা রানটাইম উপাদানগুলো—যেমন কোর টাইপের মেটাটেবিল এবং লিগ্যাসি এনভায়রনমেন্ট এপিআই—এতটাই শিথিল ছিল যে একটি স্ক্রিপ্ট অন্যগুলোর কার্যকারিতাকে প্রভাবিত করতে পারত। কিছু ডেপ্লয়মেন্টে, এটি ব্যবহারকারীদের মধ্যেকার বিচ্ছিন্নতাকে অস্পষ্ট করে দিতে পারত।

এই CVE-এর প্যাচটি এখানে পাওয়া যাবে: 45eac02

প্যাচ বিশ্লেষণ

এই সমাধানটি প্রধানত দুটি কাজ করে: কোর মেটাটেবিলগুলোকে সুরক্ষিত রাখে এবং ঝুঁকিপূর্ণ লিগ্যাসি এপিআইগুলোর প্রবেশাধিকার বন্ধ করে দেয় ।

1. কোর টাইপ মেটাটেবলগুলি সুরক্ষিত

পূর্বে, স্ক্রিপ্টের (স্ট্রিং, সংখ্যা, বুলিয়ান, ইত্যাদি) সংস্পর্শে আসা কোর লুয়া টাইপগুলিতে ব্যবহারকারীর স্ক্রিপ্ট থেকে মেটাটেবল পরিবর্তনগুলি প্রতিরোধ করার জন্য কোনও কঠোর বাধা ছিল না। এর অর্থ হল একটি শেয়ার্ড মেটাটেবলে পরিবর্তন একই ইঞ্জিনে চলমান অন্যান্য কোডকে প্রভাবিত করতে পারে।

প্যাচ করা কোডটি লুয়া এনভায়রনমেন্ট সেটআপের সময় স্পষ্টভাবে সেই মেটাটেবলগুলিকে শক্ত করে তোলে। সরলীকৃত আকারে:

প্যাচ করা কোড: আদিম মেটাটেবলগুলিকে সুরক্ষিত হিসেবে চিহ্নিত করুন

স্ট্যাটিক শূন্যতা luaProtectPrimitiveMetatables(lua_State *L) {

const int প্রকার[] = {LUA_TSTRING, LUA_TNUMBER, LUA_TBOOLEAN, LUA_TNIL};

(size_t i = 0; i <sizeof(types)/sizeof(types[0]); i++) এর জন্য {

luaL_getmetable(L, lua_typname(L, প্রকার[i]));

যদি (!lua_isnil(L, -1)) {

lua_pushliteral(L, "সুরক্ষিত");

lua_setfield(L, -2, “__মেটাটেবল”); /* লক মেটাটেবল */

}

লুয়া_পপ(এল, ১);

}

}

এই __metatable সুরক্ষার অর্থ হলো, ইউজার স্ক্রিপ্টগুলো এই টাইপগুলো দেখতে পেলেও , বিশ্বব্যাপী এদের মেটাটেবিলগুলো প্রতিস্থাপন বা পুনর্লিখন করতে পারে না। এমন কোনো প্রচেষ্টা করলে তা নীরবে অন্য সবার আচরণ পরিবর্তন না করে, সুষ্ঠুভাবে ব্যর্থ হয়।

2. লিগ্যাসি এনভায়রনমেন্ট API গুলি স্পষ্টভাবে অপ্ট-ইন করা হয়

পুরোনো লুয়া এপিআইগুলো, যেগুলো এনভায়রনমেন্ট পরিবর্তন করতে পারত, এখন ডিফল্টরূপে নিষ্ক্রিয় থাকে এবং শুধুমাত্র কোনো অপারেটর স্পষ্টভাবে সক্রিয় করলেই সেগুলো উন্মুক্ত হয়।

ধারণাগতভাবে, পরিবর্তনটি এইরকম দেখাচ্ছে:

প্যাচের আগে: অবচিত API গুলি সর্বদা স্ক্রিপ্টে উপলব্ধ env

স্ট্যাটিক কনস্ট লুয়াল_রেগ রিডিস_কম্প্যাট_ফাংশন[] = {

{“getfenv”, luaB_getfenv},

{“setfenv”, luaB_setfenv},

{“নতুনপ্রক্সি”, luaB_নতুনপ্রক্সি},

{শূন্য, শূন্য}

};

স্ক্রিপ্টক্রিয়েটএএনভি(…) {

luaL_register(L, “_G”, redis_compat_funcs);

}

প্যাচের পরে: শুধুমাত্র lua-enable-deprecated-api সেট করা থাকলেই নিবন্ধন করুন

স্ক্রিপ্টক্রিয়েটএএনভি(…) {

যদি (server.lua_enable_deprecated_api) {

luaL_register(L, “_G”, redis_compat_funcs);

}

}

যদি lua-enable-deprecated-api সক্রিয় না থাকে, তাহলে এই ফাংশনগুলি স্ক্রিপ্ট পরিবেশে উপস্থিত থাকবে না, যার ফলে ক্রস-কনটেক্সট ম্যানিপুলেশনের জন্য শক্তিশালী লিভারগুলি সরিয়ে ফেলা হবে।

একত্রে বললে, এই পরিবর্তনগুলি নিশ্চিত করে:

• কোর মেটাটেবল পুনর্লিখনের মাধ্যমে স্ক্রিপ্টগুলি নীরবে অন্য সমস্ত স্ক্রিপ্টের জন্য মৌলিক আচরণ প্যাচ করতে পারে না।
• পরিবেশ-কারসাজির আদিমগুলি হল কেবল যদি কোনও অপারেটর ইচ্ছাকৃতভাবে এগুলি চালু করে তবে এটি উপলব্ধ।

এটি লুয়া রানটাইমকে আরও ভবিষ্যদ্বাণীযোগ্য করে তোলে এবং প্রতিটি স্ক্রিপ্টকে তার অভিপ্রেত বিশেষাধিকার এবং প্রেক্ষাপটের অনেক কাছাকাছি রাখে—যেকোনো ভাগ করা বা বহু-ভাড়াটে Redis স্থাপনার জন্য গুরুত্বপূর্ণ।

CVE-2025-49844: পার্সারে লুয়া ব্যবহার-পর-মুক্ত

এই বাগটি Redis কীভাবে Lua-এর পার্সারকে একীভূত করে তার মধ্যে বাস করে। নির্দিষ্ট পরিস্থিতিতে, একটি তৈরি Lua স্ক্রিপ্ট ভুল সময়ে আবর্জনা সংগ্রহ শুরু করতে পারে এবং Redis-কে ইতিমধ্যেই মুক্ত করা মেমোরির পয়েন্টার দিয়ে পড়তে বাধ্য করতে পারে।

এই CVE-এর প্যাচটি এখানে উল্লেখ করা হলো: d5728cb5795

প্যাচ বিশ্লেষণ
মূল পরিবর্তন হল যে রেডিস এখন পার্সিং করার সময় লুয়া স্ট্যাকে পার্সার যে লুয়া অবজেক্টগুলি ব্যবহার করছে (যেমন চাঙ্কের নাম) তার সঠিক রেফারেন্স রাখে, তাই আবর্জনা সংগ্রহকারী সেগুলিকে জীবন্ত হিসেবে দেখে এবং তাড়াতাড়ি মুক্ত করতে বা সরাতে পারে না।

পূর্বে, chunk “name” ইনলাইনে তৈরি করা হত এবং সরাসরি লেক্সারে পাঠানো হত:

luaX_setinput(L, &lexstate, z, luaS_new(L, নাম));

যেহেতু সেই মানটি স্পষ্টভাবে নোঙ্গর করা হয়নি (উদাহরণস্বরূপ, লুয়া স্ট্যাকে), GC বা ডিফ্র্যাগ এবং আক্রমণাত্মক স্ক্রিপ্টিংয়ের একটি দুর্ভাগ্যজনক ইন্টারলিভিং, তত্ত্বগতভাবে, পার্সারকে এমন কিছুর দিকে একটি পয়েন্টার ধরে রাখতে পারে যা সরানো বা মুক্ত করা হয়েছিল।

প্যাচ করা কোডটি মালিকানা স্পষ্ট করে তোলে:

TString *tname = luaS_new(L, name);

setvalue2s(L, L->top, tname); /* স্ট্যাকে নামটি জীবন্ত রাখুন */

incr_top(L);

luaX_setinput(L, &lexstate, z, tname); /* লেক্সিং/পার্সিংয়ের জন্য নিরাপদে এটি ব্যবহার করুন */

/* … অংশটি বিশ্লেষণ করুন … */

–L->top; /* হয়ে গেলে রেফারেন্সটি বাদ দিন */

পুরো পার্সের জন্য এই অবস্থাটি রেফারেন্স রেখে, GC এবং defrag এখন এটিকে লাইভ হিসাবে বিবেচনা করে এবং মাঝপথে এটি পুনরুদ্ধার বা স্থানান্তর করতে পারে না। এটি কার্যকরভাবে সংকীর্ণ সময় উইন্ডোটি সরিয়ে দেয় যা ব্যবহার-পরবর্তী-মুক্তিকে সম্ভব করেছিল।

ঝুঁকিপূর্ণ স্থাপনার পরিস্থিতি

এই সমস্যাগুলি বিশেষ করে সেই পরিবেশে প্রাসঙ্গিক যেখানে:

• রেডিসে অ্যাপ্লিকেশনগুলি লুয়া স্ক্রিপ্টিং ব্যবহার করে।
• একই রেডিস ক্লাস্টারটি দল বা ভাড়াটেদের মধ্যে ভাগ করা হয়।
• অবিশ্বস্ত বা ব্যবহারকারী-নিয়ন্ত্রিত ইনপুট থেকে - সরাসরি বা আপনার অ্যাপ্লিকেশনের মাধ্যমে Redis-এর সাথে যোগাযোগ করা যেতে পারে।

প্রস্তাবিত কর্ম

১. প্রথমে প্যাচ করুন

• প্যাচ করা Redis 8.2.2 বিল্ডে আপগ্রেড করুন।
• অবিশ্বস্ত বা আধা-বিশ্বস্ত কোড যেখানে Lua চালাতে পারে (উদাহরণস্বরূপ EVAL/SCRIPT LOAD এর মাধ্যমে) অথবা যেখানে Redis ক্লাস্টারগুলি দল/ভাড়াটেদের মধ্যে ভাগ করা হয়, সেখানে এটিকে উচ্চ অগ্রাধিকার হিসাবে বিবেচনা করুন।

২. লুয়া স্ক্রিপ্টিং বন্ধ করুন

• লুয়া স্ক্রিপ্টিং শুধুমাত্র বিশ্বস্ত পরিষেবাগুলিতে সীমাবদ্ধ রাখতে ACL ব্যবহার করুন।
• রেডিসকে ব্যক্তিগত নেটওয়ার্কে রাখুন, সরাসরি ইন্টারনেট এক্সপোজার ছাড়াই।
• আপনার যদি স্পষ্ট, নিরীক্ষিত প্রয়োজন না থাকে, তাহলে lua-enable-deprecated-api অক্ষম রাখুন।

৩. সেগমেন্ট সংবেদনশীল কাজের চাপ

• আলাদা Redis ইনস্ট্যান্সে অবিশ্বস্ত বা গ্রাহক-চালিত Lua চালান।
• ভাড়াটে-নিয়ন্ত্রিত স্ক্রিপ্টগুলিকে গুরুত্বপূর্ণ বা সংবেদনশীল ডেটা ধারণকারী ক্লাস্টারের সাথে মিশ্রিত করবেন না।

৪. দৃশ্যমানতা যোগ করতে নিরাপত্তা নিয়ন্ত্রণ ব্যবহার করুন (প্যাচিংয়ের বিকল্প হিসেবে নয়)

• সরাসরি Redis অ্যাক্সেস এবং সন্দেহজনক Redis প্রোটোকল ব্যবহার সনাক্ত এবং ব্লক করতে IPS/IDS/WAF কনফিগার করুন।
• এক্সপ্লাইট-জাতীয় আচরণ সনাক্ত করতে Redis হোস্টে EDR/AV/রানটাইম সুরক্ষা ব্যবহার করুন

তথ্যসূত্র:

• github.com/redis/redis/commits/8.2.2/
• জন্য CVE-2025-46817
• জন্য CVE-2025-46818
• জন্য CVE-2025-46819
• জন্য CVE-2025-49844

লেখক:

বিনয় কুমার

অদ্রিপ মুখার্জি

নন্দিনী শেঠ

সুবর্ণজিৎ জগতাপ