strongSwan-এ PKCS#7 পাঠালেই মেমোরি ক্ষয়—IKEv1 বন্ধ থাকলে ঝুঁকি কম

৭ সেপ্টেম্বর ২০২৬-এ প্রকাশিত strongSwan-এর vulnerability advisory অনুযায়ী, 5.0.2 থেকে 6.1.0-এর আগের সংস্করণগুলোর openssl plugin PKCS#7 container থেকে certificate গণনার সময় মেমোরি ছাড়ে না। IKEv1 গ্রহণকারী server-এ দূরবর্তী peer authentication শেষ হওয়ার আগেই leak-টি বারবার ঘটাতে পারে—যদিও একটি packet যথেষ্ট নয়, aggressive mode-এও অন্তত দুটি IKE message লাগে।

একই দিন প্রকাশিত strongSwan 6.1.0 release announcement সংস্করণটিতে CVE-2026-78124 সংশোধন এবং IKEv1 default অবস্থায় বন্ধ করার তথ্য দেয়। তাই স্থায়ী upstream সমাধান হলো 6.1.0; এখনই সেখানে যাওয়া সম্ভব না হলে নির্দিষ্ট patch বা distribution-এর backport প্রয়োজন, আর সাময়িক ঝুঁকি নির্ভর করবে IKE version, openssl plugin, pkcs7 plugin ও তাদের load order-এর ওপর।

Authentication-এর আগেই leak যেভাবে তৈরি হয়

ত্রুটিটি certificate-এর cryptographic validation ভাঙে না। openssl plugin একটি PKCS#7/CMS structure থেকে certificate stack নিতে CMS_get1_certs() ব্যবহার করে; এতে stack এবং তার প্রতিটি X509 certificate-এর reference count বাড়ে। সংশ্লিষ্ট enumerator ধ্বংস হওয়ার সময় sk_X509_pop_free() ডাকা না হওয়ায় ওই মেমোরি আর মুক্ত হতো না।

IKEv1 certificate payload-এ “PKCS #7 wrapped X.509 certificate” encoding সমর্থিত। ফলে এক বা একাধিক certificate থাকা container পাঠিয়ে unauthenticated peer ত্রুটিপূর্ণ enumeration path-এ পৌঁছাতে পারে। একই exchange পুনরাবৃত্ত হলে প্রতিবার কিছু মেমোরি থেকে যায়; জমতে থাকা বরাদ্দ শেষ পর্যন্ত gateway-এর উপলভ্য মেমোরি ও সেবার স্থিতিশীলতায় প্রভাব ফেলতে পারে।

শিরোনামের “পাঠালেই” কথাটি তাই একক message বোঝায় না: exploit path-এ অন্তত দুই ধাপের IKE exchange প্রয়োজন। তবে authentication সফল হওয়া বা বৈধ VPN credential থাকা দরকার নেই—এ কারণেই পরিচিত ব্যবহারকারীর মধ্যে প্রবেশাধিকার সীমিত করলেই ঝুঁকি শেষ হয় না।

চার শর্তে কোন configuration ঝুঁকিতে

শুধু strongSwan-এর version number দিয়ে exposure নির্ধারণ করা যাবে না। আক্রান্ত code উপস্থিত থাকলেও দূর থেকে trigger হওয়ার প্রধান পথটি নিচের চারটি configuration অবস্থার সমন্বয়ের ওপর নির্ভর করে:

• IKEv1 গ্রহণ করা হয় না: advisory-তে বর্ণিত প্রধান remote attack path বন্ধ; এই পথে server vulnerable নয়।
• IKEv1 চালু, কিন্তু openssl plugin ব্যবহৃত হয় না: ত্রুটিপূর্ণ PKCS#7 implementation-এ request পৌঁছায় না, তাই এই নির্দিষ্ট leak ঘটে না।
• IKEv1 ও openssl plugin চালু, এবং container openssl দিয়েই parse হয়: configuration-টি আক্রান্ত; fixed package বা patch প্রয়োজন।
• pkcs7 plugin openssl-এর আগে load হয়: দুটি plugin-ই enabled থাকলে এটি default order এবং সাধারণত leak এড়াতে পারে। কিন্তু pkcs7 container parse করতে ব্যর্থ হলে openssl-এ fallback হয়, তাই load order-কে পূর্ণাঙ্গ fix ধরা যাবে না।

version = 0 নিরাপদ IKEv2-only setting নয়। এই মানে strongSwan নিজে connection শুরু করার সময় IKEv2 বেছে নেয়, কিন্তু responder হিসেবে IKEv1 গ্রহণ করতে পারে। ফলে outbound session-এ শুধু IKEv2 দেখা গেলেও inbound IKEv1 exposure থেকে যেতে পারে; নির্ভরযোগ্য mitigation-এর জন্য connection definition-এ version স্পষ্টভাবে 2 করতে হবে অথবা build থেকে IKEv1 বাদ দিতে হবে।

6.1.0, backport ও patch-এর পার্থক্য

প্রথম পছন্দ strongSwan 6.1.0 অথবা distribution-এর এমন package যাতে সংশোধনটি backport করা হয়েছে। পুরোনো upstream version string দেখেই package vulnerable ধরে নেওয়া ঠিক নয়: ৭ সেপ্টেম্বরের Debian security alert Debian 13 “trixie”-এর 6.0.1-6+deb13u7 package-কে সংশোধিত সংস্করণ হিসেবে চিহ্নিত করে। বিপরীতে একই distribution-এর আগের 6.0.1-6+deb13u6 package আক্রান্ত ছিল।

Vendor-fixed package না থাকলে upstream-এর CVE-2026-78124 patch পুরোনো release branch-এ প্রয়োগ করতে হবে। strongSwan জানিয়েছে, প্রয়োজনীয় hunk offset মিলিয়ে patchটি পুরোনো release-এ প্রয়োগযোগ্য হওয়া উচিত। নিজস্ব build-এর ক্ষেত্রে source patch করাই শেষ ধাপ নয়: package পুনর্নির্মাণ, deployment এবং সংশ্লিষ্ট daemon restart না হওয়া পর্যন্ত চলমান binary পুরোনো code-ই ব্যবহার করবে।

Patch rollout-এর আগে exposure কমানোর ক্রমটি হলো:

1. প্রতিটি connection definition পরীক্ষা করে প্রয়োজন না থাকলে version = 2 নির্ধারণ করা; version 0-কে IKEv1 বন্ধ বলে গণ্য না করা।
2. Build ও runtime configuration-এ openssl plugin load হচ্ছে কি না যাচাই করা।
3. pkcs7 ও openssl দুটিই থাকলে load order দেখা, কিন্তু pkcs7 আগে থাকাকে patch-এর বিকল্প না ধরা।
4. Legacy client-এর জন্য IKEv1 রাখতেই হলে 6.1.0, vendor backport অথবা upstream patch দ্রুত স্থাপন করা।

প্রভাবের সীমা ও আপডেটের পরেও যা দেখতে হবে

CVE-2026-78124 দিয়ে remote code execution সম্ভব নয়। এটি memory corruption বা certificate authentication bypass হিসেবেও বর্ণিত হয়নি; নির্দিষ্ট ত্রুটি হলো certificate enumeration-এর পর memory leak। নিরাপত্তা-প্রভাব তৈরি হয় একই pre-authentication path বারবার ব্যবহার করে মেমোরি জমিয়ে তোলার সুযোগ থেকে।

6.1.0-এ IKEv1 support build করার সময় --enable-ikev1 দিয়ে আলাদাভাবে চালু করতে হয় এবং configuration-এর version default এখন 2। তবে distribution build বা স্থানীয় configuration-এ IKEv1 আবার স্পষ্টভাবে enable করা থাকতে পারে। তাই upgrade-এর পরও package-এ fix উপস্থিতি, inbound IKEv1 গ্রহণ, openssl plugin-এর ব্যবহার এবং pkcs7 থেকে openssl-এ fallback—এই চার অবস্থাই বাস্তব exposure নির্ধারণ করবে।