OpenBSD এর W^X নিরাপত্তা ব্যবস্থাকে শক্তিশালী করার পরিকল্পনা

থিও ডি রাড্ট ভাগ W^X (Write XOR Execute) মেমরি সুরক্ষা ব্যবস্থাকে শক্তিশালী করার পরিকল্পনা করছে। মেকানিজমের সারমর্ম হল যে প্রক্রিয়া মেমরি পৃষ্ঠাগুলি একই সাথে লেখা এবং সম্পাদনের জন্য অ্যাক্সেস করা যায় না। সুতরাং, লেখা নিষ্ক্রিয় হওয়ার পরেই কোডটি কার্যকর করা যেতে পারে, এবং একটি মেমরি পৃষ্ঠায় লেখা শুধুমাত্র সম্পাদন নিষ্ক্রিয় করার পরেই সম্ভব। W^X মেকানিজম স্ট্যাক ওভারফ্লো সহ সাধারণ বাফার ওভারফ্লো আক্রমণ থেকে ব্যবহারকারী-স্পেস অ্যাপ্লিকেশনগুলিকে রক্ষা করতে সাহায্য করে এবং OpenBSD-তে সক্রিয়। ডিফল্টরূপে.

W^X-এ কাজ শুরু হওয়ার পর থেকে, এটা স্পষ্ট যে এটি একটি দীর্ঘ রাস্তা, যেহেতু JIT ব্যবহার করে উল্লেখযোগ্য সংখ্যক অ্যাপ্লিকেশন ছিল। JIT বাস্তবায়ন তিনটি বিভাগে বিভক্ত করা যেতে পারে:

• W এবং X রাজ্যের মধ্যে মেমরি স্যুইচ করা, সিস্টেম কলের "খরচ" গ্রহণ করে প্রতিরক্ষা.
• একই মেমরির W এবং X ম্যাপিংয়ের একটি জোড়ার মধ্যে উপনাম তৈরি করা।
• সবচেয়ে "নোংরা" বিকল্পের জন্য একটি W|X মেমরি মডেল প্রয়োজন যা একই সাথে রেকর্ডিং এবং সম্পাদনের অনুমতি দেয়।

বর্তমানে, তৃতীয় বিকল্পটি ব্যবহার করে উল্লেখযোগ্যভাবে কম প্রোগ্রাম রয়েছে এবং প্রথম এবং দ্বিতীয়টি ব্যবহার করে আরও বেশি। যাইহোক, যেহেতু W|X JIT (প্রধানত Chromium এবং Iridum) দিয়ে প্রোগ্রাম চালানোর প্রয়োজন ছিল, তাই একটি "wxallowed" ফাইলসিস্টেম মাউন্ট বিকল্প যোগ করা হয়েছিল, যা মেমরি লেখা এবং সম্পাদন উভয়ের জন্য একই সাথে ব্যবহার করার অনুমতি দেয়, যদি এক্সিকিউটেবল ELF ফাইলটি "wxneeded" মার্কার দিয়ে চিহ্নিত করা হয়েছে, এবং অ্যাপ্লিকেশনগুলি নিজেরাও মেকানিজম ব্যবহার করে সুরক্ষিত ছিল অঙ্গীকার и প্রকটিত করা ব্যবহৃত সিস্টেম কলের তালিকা এবং অ্যাপ্লিকেশনে উপলব্ধ ফাইল সিস্টেমের অংশগুলি যথাক্রমে সীমিত করতে।

এই জাতীয় অ্যাপ্লিকেশনগুলিতে দুর্বলতার শোষণকে আরও জটিল করার জন্য, প্রক্রিয়াটিতে একটি সংযোজনের প্রস্তাব করা হয়েছে ম্যাপ_স্ট্যাক, যা একটি লিখনযোগ্য মেমরি পৃষ্ঠা থেকে সিস্টেম কল চালানো হচ্ছে কিনা তা পরীক্ষা করে। পৃষ্ঠাটি লেখার যোগ্য হলে, প্রক্রিয়াটি বন্ধ করতে বাধ্য করা হয়। এইভাবে, একজন আক্রমণকারী সিস্টেম কলগুলিকে কাজে লাগাতে পারবে না এবং JIT বাস্তবায়নে প্রয়োজনীয় গ্যাজেটগুলি খুঁজে বের করার চেষ্টা করতে বা এমনকি ভিতরে সরাসরি সিস্টেম কল স্টাবগুলি সনাক্ত করার আরও কঠিন কাজ করতে বাধ্য হবে। ঘটনাক্রমে লিবিসি লিঙ্ক করা হয়েছে.

ক্রোম/ইরিডিয়াম প্রক্রিয়াগুলি ইতিমধ্যেই অঙ্গীকার এবং উন্মোচন ব্যবহার করে বেশ নির্ভরযোগ্যভাবে সুরক্ষিত, তবে ব্যবহারের ক্ষমতা সরিয়ে ফেলা, উদাহরণস্বরূপ, রাইট(2) সিস্টেম কলের স্পষ্টতই কিছু সুবিধা রয়েছে, কারণ এটি আক্রমণকারীর জন্য অতিরিক্ত অসুবিধা তৈরি করে। যাইহোক, সমস্যাও দেখা দিতে পারে যদি JIT বাস্তবায়ন W|X মেমরি থেকে নেটিভ সিস্টেম কল ব্যবহার করে। যাইহোক, আশা করার কারণ আছে যে এটি হবে না, যেহেতু ABI বেশ কয়েকবার পরিবর্তন করা হয়েছে, কিন্তু কেউ কখনও সমস্যার কথা জানায়নি।

পরিবর্তনগুলি ইতিমধ্যেই ওপেনবিএসডি-কারেন্ট শাখার নিয়মিত স্ন্যাপশটে উপলব্ধ, আগ্রহী প্রত্যেককে পরীক্ষা করার জন্য আমন্ত্রণ জানানো হচ্ছে।

Chrome/Iridium-এ মোডের উপস্থিতি সম্পর্কে সম্পর্কিত সংবাদ থিও থেকে একটি পৃথক মন্তব্যের দাবি রাখে JITless. তার দৃষ্টিকোণ থেকে, এটি কিছু ব্যবহারের মডেলের জন্য গ্রহণযোগ্য, তবে সম্ভবত সবার জন্য নয়, যেহেতু এই মোডটি স্পষ্টতই প্রসেসরের লোড বাড়িয়ে তুলবে। বর্তমানে, Chrome বেশিরভাগ কাজ করবে যদি আপনি /usr/local এর জন্য "wxallowed" অক্ষম করেন, যদিও কিছু এক্সটেনশনের সাথে সমস্যা হতে পারে (ভুতুড়ে একটি উদাহরণ)। একভাবে বা অন্যভাবে, থিও আশা করে যে JITless মোডে পূর্ণাঙ্গ কাজ অদূর ভবিষ্যতে একটি সম্পূর্ণ কার্যকরী অবস্থায় আনা হবে।

উত্স: opennet.ru