প্রথম অংশ · পূর্ণাঙ্গ নিবন্ধ
সার্ভারটি চালু হচ্ছে। বিদ্যুৎ সংযোগ হয়েছে, ফার্মওয়্যার নিজের কাজ শুরু করেছে, নেটওয়ার্ক থেকে বুট ইমেজ নামছে। এই কয়েক সেকেন্ডে অপারেটিং সিস্টেম এখনো জাগেনি, Secure Boot এখনো কোনো সফটওয়্যার যাচাই করেনি, লগ লেখা শুরু হয়নি, এন্ডপয়েন্ট সুরক্ষা সক্রিয় হয়নি। ডেটা সেন্টারের দৃষ্টিতে এটি রুটিন প্রক্রিয়া; আক্রমণকারীর দৃষ্টিতে এটি এমন একটি জানালা, যেখানে ঢোকার পর তাকে আর কোনো সুরক্ষা পেরোতে হয় না। সম্প্রতি ঠিক এই স্তরেই একটি গুরুতর ত্রুটি প্রকাশ্যে এসেছে, যা CVE-2026-97631 নামে নিবন্ধিত।
ত্রুটিটি আছে TianoCore EDK II-তে, ওপেন সোর্স কোডবেসটিতে যা বিশ্বের বহু সার্ভার ও মাদারবোর্ড নির্মাতা নিজেদের UEFI ফার্মওয়্যার বানাতে ব্যবহার করেন। ফার্মওয়্যার হলো সেই সফটওয়্যার, যা কম্পিউটার চালু হওয়ার সঙ্গে সঙ্গে চলে এবং অপারেটিং সিস্টেমকে লোড করার দায়িত্ব নেয়। UEFI হলো আধুনিক ফার্মওয়্যার-ইন্টারফেস, যা পুরোনো BIOS-এর জায়গা নিয়েছে; Secure Boot-এর মতো ব্যবস্থা এরই অংশ, যার কাজ হলো বুটের প্রতিটি ধাপে কোডের অনুমোদন যাচাই করা। EDK II সেই UEFI-এর সবচেয়ে বহুল ব্যবহৃত রেফারেন্স বাস্তবায়ন। আর PXE (Preboot eXecution Environment) হলো নেটওয়ার্ক থেকে বুট করার পদ্ধতি — ডেটা সেন্টারে এটি অত্যন্ত সাধারণ, কারণ এতে শত শত সার্ভারে আলাদা করে ইনস্টলেশন মিডিয়া ঢোকাতে হয় না; একটি কেন্দ্রীয় সার্ভার থেকেই সবাই বুট ইমেজ পায়।
ত্রুটিটির অবস্থান NetworkPkg/UefiPxeBcDxe ড্রাইভারে, অর্থাৎ PXE Base Code ড্রাইভারে। নেটওয়ার্ক বুট চলাকালে এই ড্রাইভার ICMP ত্রুটি-বার্তা গ্রহণের জন্য একটি অনুরোধ খোলা রাখে এবং প্রতিটি বার্তা তার নিজস্ব কাঠামোর নির্দিষ্ট ৫০৪ বাইটের একটি ঘরে অনুলিপি করে। সমস্যা হলো, অনুলিপির সীমা ঠিকভাবে হিসাব করা হয়নি। ৫০৪ বাইটের চেয়ে বড় বার্তা এলেও বাইটগুলো ওই ঘরে লেখা চলতে থাকে, এবং গন্তব্য-নির্দেশকটি প্রতি খণ্ডের দৈর্ঘ্যের বদলে ক্রমপুঞ্জিত দৈর্ঘ্য দিয়ে এগোয়। ফলে অতিরিক্ত বাইট ঘরের বাইরে, ড্রাইভারের নিজস্ব মেমরিতে গিয়ে পড়ে। IPv4 ও IPv6 — দুই পথেই ত্রুটিটি আছে, এবং গ্রহণের আগে বার্তার দৈর্ঘ্য নিয়ন্ত্রণ করার কোনো ব্যবস্থাও নেই। NVD এটিকে তিনটি দুর্বলতার শ্রেণিতে রেখেছে: বাফার ওভারফ্লো, ভুল বাফার-আকার গণনা এবং সীমার বাইরে লেখা।
এর ফল দুই রকম হতে পারে। প্রথমটি সরল: ড্রাইভারের নিজস্ব তথ্য নষ্ট হয়ে পরের ICMP বার্তায় প্রসেসর ব্যতিক্রম ঘটে বুট আটকে যায় — অর্থাৎ সেবা প্রস্তুত করা বা পুনরুদ্ধার করা ব্যাহত হয়। দ্বিতীয়টি জটিল: যে আক্রমণকারী লক্ষ্য ফার্মওয়্যারের নির্দিষ্ট বিল্ড সম্পর্কে জানেন, তিনি একই প্যাকেটে একটি ভুয়া ইভেন্ট বসিয়ে দিতে পারেন, যা DXE পর্যায়ে আক্রমণকারীর দেওয়া বাইট চালু করিয়ে দেয়। DXE হলো বুটের সেই ধাপ, যেখানে এখনো কোনো অপারেটিং সিস্টেম-স্তরের নিরাপত্তা নেই। এ কারণেই ত্রুটিটিকে "প্রি-বুট রিমোট কোড এক্সিকিউশন" বলা হচ্ছে।
এখানে একটি সূক্ষ্মতা জরুরি। TianoCore ও GitHub CVSS ৪.০-এ এটিকে ৯.৫ (Critical) দিয়েছে, কিন্তু Red Hat CVSS ৩.১-এ ৮.৮ দিয়েছে এবং আক্রমণ-পথকে "সংলগ্ন নেটওয়ার্ক" হিসেবে গণ্য করেছে। NVD নিজে কোনো স্কোর দেয়নি; রেকর্ডটি "Deferred" অবস্থায় আছে। অর্থাৎ ৯.৫ সংখ্যাটি একটি প্রভাব-নির্দেশক, কোনো ঘটনার প্রমাণ নয়। ৩০ অক্টোবর ২০২৬ পর্যন্ত CISA-র Known Exploited Vulnerabilities তালিকায় CVE-টি নেই, এবং কোনো নিরাপত্তা প্রতিষ্ঠান বাস্তবে শোষণের নিশ্চিত প্রমাণ প্রকাশ করেনি। ঝুঁকি বাস্তব, কিন্তু ঘটনা এখনো অনুমান।
কেন এই ত্রুটি আলাদা গুরুত্ব পাচ্ছে, তার কারণ এর অবস্থান। সাধারণ দুর্বলতা অপারেটিং সিস্টেমের ভেতরে থাকে, তাই প্যাচ, এন্ডপয়েন্ট সুরক্ষা, লগ বিশ্লেষণ — সবই কাজে লাগে। ফার্মওয়্যারের ত্রুটি তার নিচে থাকে। সার্ভার চালু হওয়ার আগেই যদি কোড চলে, তবে অপারেটিং সিস্টেমের লগে তার কোনো চিহ্ন থাকবে না, EDR কিছু দেখবে না, ফাইল-ইন্টিগ্রিটি মনিটরিং নিষ্ক্রিয় থাকবে। ঘটনা শনাক্ত করা কঠিন হয়ে পড়ে, আর প্রতিক্রিয়াও দুর্বল হয়। তবে এখানে সীমাবদ্ধতাও আছে: প্রকাশিত বিশ্লেষণ অনুযায়ী এই ত্রুটির মাধ্যমে পাঠানো চূড়ান্ত পেলোড নিজে থেকে টিকে থাকে না — এটি একবার চলে শেষ। অর্থাৎ ফার্মওয়্যারে স্থায়ী বসতি গাড়ার জন্য আক্রমণকারীকে আলাদা পদক্ষেপ নিতে হবে, যা সহজ নয়। ঝুঁকিটি তাই "মুহূর্তের প্রবেশদ্বার", "স্থায়ী দখল" নয়।
বাংলাদেশের প্রেক্ষাপটে এই আলোচনার প্রাসঙ্গিকতা আছে, তবে সতর্কতার সঙ্গে। দেশের সরকারি ডেটা সেন্টার, ব্যাংক ও আর্থিক প্রতিষ্ঠানের সার্ভার, টেলিযোগাযোগ ও ইন্টারনেট সেবাদাতার অবকাঠামো, বিশ্ববিদ্যালয় ও গবেষণা প্রতিষ্ঠানের কম্পিউটিং — এসব জায়গায় নেটওয়ার্ক বুট ব্যবহারের প্রবণতা ও ফার্মওয়্যার-ইনভেন্টরি সংরক্ষণের অভ্যাস সম্পর্কে আমাদের নির্ভরযোগ্য প্রকাশ্য তথ্য নেই। BGD e-GOV CIRT-এর প্রকাশিত অ্যাডভাইজরি তালিকায় ৩০ অক্টোবর ২০২৬ পর্যন্ত এই CVE-টি নেই, এবং দেশের কোনো প্রতিষ্ঠান আক্রান্ত হয়েছে বলে কোনো প্রমাণও নেই। তাই এটিকে "বাংলাদেশে ঘটে যাওয়া ঘটনা" হিসেবে উপস্থাপন করা ভুল হবে। বরং প্রশ্নটি হলো প্রস্তুতির: আমাদের প্রতিষ্ঠানগুলোর কাছে নিজেদের ফার্মওয়্যার সংস্করণের তালিকা আছে কি, এবং কোনো সরবরাহকারী নিরাপত্তা-হালনাগাদ দিলে তা দ্রুত প্রয়োগ করার প্রক্রিয়া আছে কি।
সম্প্রতি আলোচিত PHP-সংক্রান্ত ত্রুটির সঙ্গে এর তুলনা সহায়ক। PHP-র দুর্বলতা অ্যাপ্লিকেশন স্তরে; আপডেট করা তুলনামূলক সহজ, কারণ প্যাকেজ ব্যবস্থাপক একটি কমান্ডেই কাজ সেরে দেয়। ফার্মওয়্যার সম্পূর্ণ ভিন্ন — এটি হার্ডওয়্যারের সঙ্গে বাঁধা, নির্মাতার ওপর নির্ভরশীল, এবং শত শত সার্ভারে প্রয়োগ করতে রিবুট, ডাউনটাইম ও ঝুঁকি লাগে। এ কারণেই একটি প্রযুক্তি ব্যাপক ব্যবহৃত হলেই সব ব্যবহারকারী একইভাবে আক্রান্ত হন না: শর্ত হলো ফার্মওয়্যারটি EDK II-ভিত্তিক কি না, PXE চালু কি না, এবং সার্ভারটি নেটওয়ার্ক থেকে বুট করে কি না। শুধু ডিস্ক থেকে বুট করা সাধারণ ব্যবহারকারী বা ছোট অফিস এই ত্রুটি দ্বারা প্রভাবিত নন।
প্রতিরোধের প্রথম ধাপ সহজ কিন্তু উপেক্ষিত: ফার্মওয়্যার-ইনভেন্টরি। কোন সার্ভারে কোন নির্মাতার কোন সংস্করণ চলছে, তা না জানলে প্যাচ দেওয়ার প্রশ্নই ওঠে না। এরপর দরকার সরবরাহকারীর সঙ্গে সরাসরি যোগাযোগ — কারণ এই ত্রুটির ক্ষেত্রে EDK II-এর master শাখায় ১৫ অক্টোবর সমাধান এলেও কোনো stable release-এ তা এখনো আসেনি, এবং Debian-সহ কয়েকটি ডিস্ট্রিবিউশনে প্যাকেজ এখনো "unfixed" হিসেবে তালিকাভুক্ত। যেখানে নেটওয়ার্ক বুটের প্রয়োজন নেই, সেখানে PXE বন্ধ করা একটি সস্তা ও কার্যকর প্রশমন। যেখানে প্রয়োজন, সেখানে PXE সার্ভার ও ক্লায়েন্টের মধ্যে নেটওয়ার্ক বিভাজন, অননুমোদিত ICMP প্রবেশ নিয়ন্ত্রণ এবং বুট-নেটওয়ার্কে প্রবেশাধিকার সীমিত রাখা জরুরি। পাশাপাশি Secure Boot ও মেজার্ড বুটের কনফিগারেশন যাচাই করা উচিত — যদিও এই ত্রুটি বুটের আগেই ঘটে, তাই এগুলো পূর্ণ সুরক্ষা দেয় না, তবু পরবর্তী ধাপের প্রতিরক্ষা হিসেবে কাজ করে।
শেষ পর্যন্ত শিক্ষাটি প্রযুক্তিগতের চেয়ে প্রাতিষ্ঠানিক। ফার্মওয়্যার নিরাপত্তা সাধারণত কোনো প্রতিষ্ঠানের দুর্বলতা-ব্যবস্থাপনা কর্মসূচির তালিকায় থাকে না, কারণ এটি সফটওয়্যার দলের নয়, হার্ডওয়্যার বা অবকাঠামো দলের বিষয়। অথচ আক্রমণের দিক থেকে এটি সবচেয়ে নিচের স্তর। বাংলাদেশের জন্য তাই প্রয়োজন একটি সাধারণ ফার্মওয়্যার-ইনভেন্টরি ও হালনাগাদ নীতি, সরবরাহকারীর নিরাপত্তা-প্রতিশ্রুতি চুক্তিতে অন্তর্ভুক্ত করা, এবং জাতীয় সাইবার নিরাপত্তা প্রতিষ্ঠানগুলোর জন্য ফার্মওয়্যার-স্তরের সতর্কতা প্রকাশের একটি নিয়মিত চ্যানেল। অপারেটিং সিস্টেম চালু হওয়ার আগের সুরক্ষা নিয়ে কথা বলা মানে আতঙ্ক নয় — বরং স্বীকার করা যে প্রতিরক্ষার একটি স্তর আমরা এখনো ঠিকভাবে দেখছি না।