ট্রোজান সোর্স আক্রমণ কোডে পরিবর্তন আনতে যা বিকাশকারীর কাছে অদৃশ্য

ক্যামব্রিজ বিশ্ববিদ্যালয়ের গবেষকরা পিয়ার-রিভিউ সোর্স কোডে নীরবে দূষিত কোড সন্নিবেশ করার জন্য একটি কৌশল প্রকাশ করেছেন। প্রস্তুত আক্রমণ পদ্ধতি (CVE-2021-42574) ট্রোজান সোর্স নামে উপস্থাপিত হয়েছে এবং টেক্সট গঠনের উপর ভিত্তি করে তৈরি করা হয়েছে যা কম্পাইলার/দোভাষী এবং কোডটি দেখার জন্য আলাদা দেখায়। পদ্ধতির উদাহরণগুলি C, C++ (gcc এবং clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go এবং Python এর জন্য সরবরাহ করা বিভিন্ন কম্পাইলার এবং দোভাষীর জন্য প্রদর্শিত হয়।

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

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

কোড পর্যালোচনা করার সময়, একজন বিকাশকারী অক্ষরগুলির ভিজ্যুয়াল অর্ডারের মুখোমুখি হবে এবং একটি আধুনিক পাঠ্য সম্পাদক, ওয়েব ইন্টারফেস বা IDE-এ একটি সন্দেহজনক মন্তব্য দেখতে পাবে, কিন্তু কম্পাইলার এবং দোভাষী অক্ষরগুলির যৌক্তিক ক্রম ব্যবহার করবে এবং করবে। মন্তব্যে দ্বিমুখী পাঠ্যের প্রতি মনোযোগ না দিয়েই দূষিত সন্নিবেশ প্রক্রিয়া করুন। সমস্যাটি বিভিন্ন জনপ্রিয় কোড এডিটর (ভিএস কোড, ইম্যাক্স, অ্যাটম) এবং সেইসাথে রিপোজিটরিগুলিতে কোড দেখার জন্য ইন্টারফেসগুলিকে প্রভাবিত করে (GitHub, Gitlab, BitBucket এবং সমস্ত আটলাসিয়ান পণ্য)।

দূষিত ক্রিয়াগুলি বাস্তবায়নের জন্য পদ্ধতিটি ব্যবহার করার বিভিন্ন উপায় রয়েছে: একটি লুকানো "রিটার্ন" অভিব্যক্তি যোগ করা, যা সময়ের আগে ফাংশনটি সম্পূর্ণ করার দিকে নিয়ে যায়; অভিব্যক্তিগুলি মন্তব্য করা যা সাধারণত বৈধ গঠন হিসাবে দৃশ্যমান হবে (উদাহরণস্বরূপ, গুরুত্বপূর্ণ চেকগুলি নিষ্ক্রিয় করতে); অন্যান্য স্ট্রিং মান নির্ধারণ করা যা স্ট্রিং যাচাইকরণ ব্যর্থতার দিকে পরিচালিত করে।

উদাহরণস্বরূপ, একজন আক্রমণকারী এমন একটি পরিবর্তনের প্রস্তাব করতে পারে যাতে লাইনটি অন্তর্ভুক্ত থাকে: if access_level != "ব্যবহারকারী{U+202E} {U+2066}// প্রশাসক{U+2069} {U+2066}" {

যা পর্যালোচনা ইন্টারফেসে প্রদর্শিত হবে যেন অ্যাক্সেস_লেভেল!= “ব্যবহারকারী” { // প্রশাসক কিনা তা পরীক্ষা করুন

উপরন্তু, আরেকটি আক্রমণের বৈকল্পিক প্রস্তাব করা হয়েছে (CVE-2021-42694), হোমোগ্লিফের ব্যবহারের সাথে যুক্ত, অক্ষর যা দেখতে একই রকম, কিন্তু অর্থে ভিন্ন এবং বিভিন্ন ইউনিকোড কোড রয়েছে (উদাহরণস্বরূপ, অক্ষর “ɑ” অনুরূপ। a", "ɡ" - "g", "ɩ" - "l")। অনুরূপ অক্ষরগুলি কিছু ভাষায় ফাংশন এবং ভেরিয়েবলের নামে ডেভেলপারদের বিভ্রান্ত করার জন্য ব্যবহার করা যেতে পারে। উদাহরণ স্বরূপ, পৃথকীকরণযোগ্য নামের দুটি ফাংশন সংজ্ঞায়িত করা যেতে পারে যা বিভিন্ন ক্রিয়া সম্পাদন করে। একটি বিশদ বিশ্লেষণ ব্যতীত, এই দুটি ফাংশনের মধ্যে কোনটিকে একটি নির্দিষ্ট জায়গায় বলা হয় তা অবিলম্বে স্পষ্ট নয়।

একটি নিরাপত্তা ব্যবস্থা হিসাবে, এটি সুপারিশ করা হয় যে কম্পাইলার, দোভাষী, এবং সমাবেশ সরঞ্জাম যা ইউনিকোড অক্ষর সমর্থন করে একটি ত্রুটি বা সতর্কতা প্রদর্শন করে যদি মন্তব্য, স্ট্রিং লিটারাল বা শনাক্তকারীর মধ্যে সংযোগহীন নিয়ন্ত্রণ অক্ষর থাকে যা আউটপুটের দিক পরিবর্তন করে (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E এবং U+200F)। এই ধরনের অক্ষরগুলিও প্রোগ্রামিং ভাষার স্পেসিফিকেশনে স্পষ্টভাবে নিষিদ্ধ করা উচিত এবং কোড এডিটর এবং রিপোজিটরি ইন্টারফেসে সম্মান করা উচিত।

সংযোজন 1: GCC, LLVM/Clang, Rust, Go, Python এবং binutils-এর জন্য দুর্বলতা প্যাচ প্রস্তুত করা হয়েছে। গিটহাব, বিটবাকেট এবং জিরাও সমস্যাটি ঠিক করেছে। GitLab-এর জন্য একটি ফিক্স প্রগতিতে আছে। সমস্যাযুক্ত কোড সনাক্ত করতে, কমান্ডটি ব্যবহার করার পরামর্শ দেওয়া হয়: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069/' উৎস

সংযোজন 2: রাস কক্স, প্ল্যান 9 ওএস এবং গো প্রোগ্রামিং ভাষার অন্যতম বিকাশকারী, বর্ণিত আক্রমণ পদ্ধতির প্রতি অত্যধিক মনোযোগের সমালোচনা করেছেন, যা দীর্ঘদিন ধরে পরিচিত (গো, রাস্ট, সি++, রুবি) এবং গুরুত্বের সাথে নেওয়া হয়নি। . কক্সের মতে, সমস্যাটি মূলত কোড এডিটর এবং ওয়েব ইন্টারফেসে তথ্যের সঠিক প্রদর্শন নিয়ে উদ্বিগ্ন, যা পর্যালোচনার সময় সঠিক টুল এবং কোড বিশ্লেষক ব্যবহার করে সমাধান করা যেতে পারে। অতএব, অনুমানমূলক আক্রমণের প্রতি দৃষ্টি আকর্ষণ করার পরিবর্তে, কোড এবং নির্ভরতা পর্যালোচনা প্রক্রিয়াগুলির উন্নতিতে ফোকাস করা আরও উপযুক্ত হবে।

রাস কক্স আরও বিশ্বাস করেন যে কম্পাইলারগুলি সমস্যা সমাধানের জন্য সঠিক জায়গা নয়, যেহেতু কম্পাইলার স্তরে বিপজ্জনক চিহ্নগুলি নিষিদ্ধ করার মাধ্যমে, সরঞ্জামগুলির একটি বিশাল স্তর রয়েছে যেখানে এই প্রতীকগুলির ব্যবহার গ্রহণযোগ্য থেকে যায়, যেমন বিল্ড সিস্টেম, অ্যাসেম্বলার, প্যাকেজ ম্যানেজার এবং বিভিন্ন কনফিগারেশন পার্সার এবং ডেটা। উদাহরণ হিসেবে, রাস্ট প্রজেক্ট দেওয়া হয়েছে, যা কম্পাইলারে LTR/RTL কোডের প্রক্রিয়াকরণ নিষিদ্ধ করেছে, কিন্তু কার্গো প্যাকেজ ম্যানেজারে কোনো ফিক্স যোগ করেনি, যা Cargo.toml ফাইলের মাধ্যমে একই ধরনের আক্রমণের অনুমতি দেয়। একইভাবে, BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml এবং requirements.txt এর মতো ফাইলগুলি আক্রমণের উত্স হতে পারে।

উত্স: opennet.ru