PostgreSQL-এর ১২ বছরের ফাঁক—backup account থেকেই server দখল সম্ভব
Cyera Research ১ সেপ্টেম্বর ২০২৬-এ PostGREShell নামে CVE-2026-6471-এর প্রযুক্তিগত বিশ্লেষণ প্রকাশ করেছে; PostgreSQL প্রকল্প এর patch দিয়েছিল ১৩ আগস্ট। PostgreSQL-এর CVE নথি অনুযায়ী, logical decoding-এর authorization ত্রুটি REPLICATION privilege-ধারী non-superuser-কে server-এর operating-system account দেখতে পায় এমন library load করে সেই account-এর অধিকারেই arbitrary code চালানোর সুযোগ দিত।
এটি password ছাড়াই যেকোনো PostgreSQL server আক্রমণের ত্রুটি নয়। আক্রমণকারীর REPLICATION-সক্ষম বৈধ credential, logical decoding ব্যবহারের সুযোগ এবং malicious library-টি server-এর কাছে পৌঁছানোর উপায় দরকার; তবে শর্তগুলো মিললে backup বা replication account থেকে database host নিয়ন্ত্রণ এবং PostgreSQL superuser অধিকার অর্জন সম্ভব। Cyera Research-এর বিশ্লেষণ ত্রুটিপূর্ণ পথটি ২০১৪ সালে PostgreSQL 9.4-এ logical decoding আসার সময় থেকে থাকার কথা জানিয়েছে এবং proof of concept-এ code execution, privilege escalation ও restart-সহনশীল persistence দেখিয়েছে।
কোন instance-এ exploit-এর শর্ত মেলে
Version inventory ঝুঁকি নির্ধারণের প্রথম ধাপ, কিন্তু vulnerable release চললেই প্রতিটি instance একইভাবে exploitable হয় না। এই পথে এমন একটি login দরকার যার REPLICATION attribute রয়েছে; logical decoding চালাতে server-এ সাধারণত wal_level = logical থাকতে হয়। এরপর replication client একটি logical slot তৈরির সময় output plugin হিসেবে এমন library নির্দেশ করে, যা PostgreSQL backend load করতে পারে।
তাই title-এর ‘backup account’ বলতে প্রতিটি backup credential বোঝায় না। Physical backup, standby, CDC connector, migration tool বা WAL-পড়া monitoring integration-এর role-এ REPLICATION থাকতে পারে, আবার কোনো backup role-এ তা নাও থাকতে পারে। ঝুঁকির আসল সীমা নির্ধারণ করবে role attribute, logical-decoding configuration, network access এবং server-visible library path—account-এর নাম নয়।
Logical replication এখন ব্যবহার না হলেও পুরোনো slot, অসমাপ্ত migration বা সাময়িকভাবে দেওয়া REPLICATION attribute exposure রেখে যেতে পারে। pg_hba.conf যদি বিস্তৃত address range থেকে replication connection নেয়, অথবা একই credential একাধিক system-এ সংরক্ষিত থাকে, credential চুরি হওয়ার পর exploit path-এ পৌঁছানো সহজ হয়; তবে এগুলো patch-এর প্রয়োজন বদলায় না।
Logical decoding কীভাবে privilege boundary ভেঙেছে
Logical replication slot-এর output plugin হলো compiled shared library, যা পরিবর্তনের stream কোন format-এ বের হবে তা নির্ধারণ করে। PostgreSQL library-টি নিজের backend process-এ load করে; ফলে তার code database server চালানো operating-system account-এর অধিকার পায়।
সাধারণ SQL LOAD পথে non-superuser-এর library path সীমিত করার পরীক্ষা ছিল। কিন্তু replication protocol দিয়ে plugin বেছে নেওয়ার পথে সেই restriction প্রয়োগ করা হয়নি: quoted plugin name-এ path separator, traversal sequence বা পূর্ণ path পৌঁছে যেতে পারত library loader পর্যন্ত। Server process-এর কাছে library-টি দৃশ্যমান হলে সেটি load হয়ে arbitrary code চালাতে পারত।
Library পৌঁছানোর উপায় platform-ভেদে আলাদা। Windows server outbound SMB share-এ পৌঁছাতে পারলে remote DLL load করা যায়; NFS automount-সক্ষম Linux বা macOS-এ network path ব্যবহার করা সম্ভব। সাধারণ Linux, container বা Kubernetes deployment-এ আক্রমণকারীর আগে থেকেই server-visible স্থানে malicious shared library লেখার আলাদা পথ দরকার—তাই vulnerable version মানেই সব পরিবেশে সমান remote exploitability নয়।
Code একবার PostgreSQL process-এর মধ্যে চললে SQL permission আর কার্যকর নিরাপত্তা-সীমা থাকে না। প্রদর্শিত exploit catalog সরাসরি বদলে replication role-কে superuser করেছে এবং configuration ও preload mechanism ব্যবহার করে restart-এর পরেও access রেখেছে। এটি সম্ভাব্য প্রভাবের demonstration; অস্বাভাবিক slot বা plugin error একা সফল exploitation-এর প্রমাণ নয়।
কোন branch-এ কোন fixed version
Supported upstream branch-এর ন্যূনতম fixed release হলো:
- PostgreSQL 18: 18.6;
- PostgreSQL 17: 17.11;
- PostgreSQL 16: 16.15;
- PostgreSQL 15: 15.19;
- PostgreSQL 14: 14.24।
Patch-এর সঙ্গে output_plugin_libraries setting এসেছে; default অনুমোদিত plugin হলো pgoutput ও test_decoding। The Hacker News-এর ৪ সেপ্টেম্বরের যাচাই অনুযায়ী, wal2json বা decoderbufs-এর মতো অন্য plugin ব্যবহারকারী installation-এ update-এর পর সংশ্লিষ্ট নাম allowlist-এ না দেওয়া পর্যন্ত logical decoding প্রত্যাখ্যাত হবে; একই প্রতিবেদনের সময় Amazon RDS-এ পাঁচটি supported branch-এর fixed package পাওয়া যাচ্ছিল।
Unsupported major version-এর নিরাপত্তা এই তালিকা থেকে অনুমান করা যাবে না। পুরোনো deployment-কে supported branch-এ নিতে হবে, অথবা operating-system distribution বা service provider CVE-টির নির্দিষ্ট backport দিয়েছে কি না যাচাই করতে হবে। Vendor package-এ আলাদা suffix বা version scheme থাকতে পারে, তাই শুধু PostgreSQL major number দেখে patch status স্থির করা যথেষ্ট নয়।
চার স্তরের exposure checklist
১. Version inventory: primary, replica, disaster-recovery node, CI database এবং বন্ধ থাকা deployable image-সহ সব instance-এর চলমান server version ও package source নথিবদ্ধ করুন। Image বা manifest আপডেট হলেও পুরোনো process চলতে পারে; তাই rollout ও প্রয়োজনীয় restart সম্পন্ন হয়েছে কি না মিলিয়ে দেখুন।
২. REPLICATION role inventory: প্রতিটি cluster-এর pg_roles-এ rolreplication সক্রিয় role শনাক্ত করুন। Role-টির workload, credential কোথায় রাখা আছে, কোন address থেকে connection অনুমোদিত এবং privilege এখনও প্রয়োজন কি না দেখুন। অপ্রয়োজনীয় attribute সরানো, credential rotate করা ও pg_hba.conf সংকুচিত করা exposure কমায়, কিন্তু vulnerable binary patch করার বিকল্প নয়।
৩. Logical-decoding inventory: wal_level, pg_replication_slots-এর logical slot এবং প্রতিটি slot-এর plugin পরীক্ষা করুন। Non-default plugin থাকলে update-এর আগে নতুন allowlist-এ তার প্রয়োজন ও compatibility ঠিক করুন; তা না হলে বৈধ CDC বা migration pipeline থেমে যেতে পারে। অপ্রত্যাশিত source address, অচেনা slot, path-সদৃশ plugin name এবং library-load error তদন্তের জন্য server log সংরক্ষণ করুন।
৪. Managed-service patch status: console-এ শুধু ‘automatic maintenance’ দেখা যথেষ্ট নয়। চলমান engine-এর কার্যকর build, maintenance completion এবং replica বা read-pool একই patched build-এ আছে কি না provider-এর release note বা CVE advisory দিয়ে মিলিয়ে নিন। Self-hosted পরিবেশে package ও restart সরাসরি দলের নিয়ন্ত্রণে; managed service patch-এর সময় provider ঠিক করলেও role, credential ও logical-slot audit গ্রাহকের দায়িত্বে থাকতে পারে।
বর্তমানে vulnerability এবং supported branch-এর fixed releases নিশ্চিত; account থেকে code execution-এর পথও গবেষণায় প্রদর্শিত। কিন্তু কোনো নির্দিষ্ট organization আক্রান্ত হয়েছে কি না, তা version দেখে বলা যায় না। সিদ্ধান্তের ভিত্তি তাই চারটি আলাদা তথ্য: চলমান build fixed কি না, কোন role REPLICATION বহন করছে, logical decoding ও কোন plugin সক্রিয়, এবং provider বাস্তবে patch rollout শেষ করেছে কি না।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।