TL; ডিআর. এই নিবন্ধে, আমরা পাঁচটি জনপ্রিয় লিনাক্স ডিস্ট্রিবিউশনের বাক্সের বাইরে কাজ করে এমন শক্ত করার স্কিমগুলি অন্বেষণ করি। প্রতিটির জন্য, আমরা ডিফল্ট কার্নেল কনফিগারেশন নিয়েছি, সমস্ত প্যাকেজ লোড করেছি এবং সংযুক্ত বাইনারিগুলিতে নিরাপত্তা স্কিমগুলি বিশ্লেষণ করেছি। বিবেচিত বিতরণগুলি হল OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 এবং 7, পাশাপাশি উবুন্টু 14.04, 12.04 এবং 18.04 LTS।

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

পর্যালোচনায় দেখা গেছে যে ওএস এবং অ্যাপ্লিকেশন স্তরে উবুন্টু 18.04-এ সর্বাধিক সংখ্যক সুরক্ষা পদ্ধতি প্রয়োগ করা হয়েছে, তারপরে ডেবিয়ান 9। অন্যদিকে, OpenSUSE 12.4, CentOS 7 এবং RHEL 7 এছাড়াও মৌলিক সুরক্ষা স্কিমগুলি বাস্তবায়ন করে, এবং স্ট্যাক সংঘর্ষ সুরক্ষা ডিফল্ট প্যাকেজের অনেক ঘন সেটের সাথে আরও ব্যাপকভাবে ব্যবহৃত হয়।

ভূমিকা

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

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

সিভিই এবং নিরাপত্তা

আমরা সকলেই "বছরের সবচেয়ে দুর্বল অ্যাপ্লিকেশন" বা "সবচেয়ে দুর্বল অপারেটিং সিস্টেম" এর মতো শিরোনাম সহ নিবন্ধগুলি দেখেছি। সাধারণত তারা দুর্বলতা সম্পর্কে রেকর্ডের মোট সংখ্যার পরিসংখ্যান প্রদান করে CVE (সাধারণ দুর্বলতা এবং এক্সপোজার), থেকে প্রাপ্ত ন্যাশনাল ভালনারেবিলিটি ডেটাবেস (NVD) থেকে , NIST এবং অন্যান্য উত্স। পরবর্তীকালে, এই অ্যাপ্লিকেশন বা ওএসগুলিকে CVE-এর সংখ্যা অনুসারে র‌্যাঙ্ক করা হয়। দুর্ভাগ্যবশত, যদিও CVEগুলি সমস্যাগুলি ট্র্যাক করার জন্য এবং বিক্রেতা এবং ব্যবহারকারীদের জানানোর জন্য খুব দরকারী, তারা সফ্টওয়্যারটির প্রকৃত নিরাপত্তা সম্পর্কে খুব কমই বলে৷

উদাহরণ হিসেবে, লিনাক্স কার্নেলের জন্য গত চার বছরে CVE-এর মোট সংখ্যা এবং উবুন্টু, ডেবিয়ান, রেড হ্যাট এন্টারপ্রাইজ লিনাক্স এবং ওপেনসুস নামে পাঁচটি সর্বাধিক জনপ্রিয় সার্ভার বিতরণ বিবেচনা করুন।

Рис। 1

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

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

Рис। 2

কর্ম

এই নিবন্ধে আমরা নিম্নলিখিত প্রশ্নের উত্তর দিতে চাই:

• বিভিন্ন লিনাক্স ডিস্ট্রিবিউশনের নিরাপত্তা কি? কার্নেল এবং ব্যবহারকারী স্থান অ্যাপ্লিকেশনে কোন সুরক্ষা ব্যবস্থা বিদ্যমান?
• ডিস্ট্রিবিউশন জুড়ে সময়ের সাথে সাথে নিরাপত্তা ব্যবস্থা গ্রহণ কীভাবে পরিবর্তিত হয়েছে?
• প্রতিটি বিতরণের জন্য প্যাকেজ এবং লাইব্রেরির গড় নির্ভরতা কী?
• প্রতিটি বাইনারি জন্য কি সুরক্ষা প্রয়োগ করা হয়?

বিতরণ নির্বাচন

এটি দেখা যাচ্ছে যে বিতরণ ইনস্টলেশনের সঠিক পরিসংখ্যান খুঁজে পাওয়া কঠিন, যেহেতু বেশিরভাগ ক্ষেত্রে ডাউনলোডের সংখ্যা প্রকৃত ইনস্টলেশনের সংখ্যা নির্দেশ করে না। যাইহোক, ইউনিক্স ভেরিয়েন্টগুলি বেশিরভাগ সার্ভার সিস্টেম তৈরি করে (ওয়েব সার্ভারে 69,2%, দ্বারা পরিসংখ্যান W3techs এবং অন্যান্য উত্স) এবং তাদের শেয়ার ক্রমাগত বাড়ছে। এইভাবে, আমাদের গবেষণার জন্য আমরা প্ল্যাটফর্মের বাক্সের বাইরে উপলব্ধ বিতরণগুলিতে মনোনিবেশ করেছি গুগল ক্লাউড. বিশেষ করে, আমরা নিম্নলিখিত OS নির্বাচন করেছি:

বিতরণ/সংস্করণ
কোর
নির্মাণ করুন

OpenSUSE 12.4
4.12.14-95.3-ডিফল্ট
#1 SMP বুধ 5 ডিসেম্বর 06:00:48 UTC 2018 (63a8d29)

ডেবিয়ান 9 (প্রসারিত)
4.9.0-8-amd64
#1 SMP ডেবিয়ান 4.9.130-2 (2018-10-27)

CentOS 6.10
2.6.32-754.10.1.el6.x86_64
#1 SMP মঙ্গলবার 15 জানুয়ারী 17:07:28 UTC 2019

CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP শুক্র 1 ফেব্রুয়ারী 14:54:57 UTC 2019

Red Hat Enterprise Linux সার্ভার 6.10 (সান্তিয়াগো)
2.6.32-754.9.1.el6.x86_64
#1 SMP বুধবার 21 নভেম্বর 15:08:21 EST 2018

Red Hat Enterprise Linux সার্ভার 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP বৃহস্পতিবার 15 নভেম্বর 17:36:42 UTC 2018

উবুন্টু 14.04 (বিশ্বস্ত তাহর)
4.4.0–140-জেনারিক

#166~14.04.1-উবুন্টু এসএমপি শনিবার 17 নভেম্বর 01:52:43 ইউটিসি 20…

উবুন্টু 16.04 (জেনিয়াল জেরাস)
4.15.0–1026-gcp
#27~16.04.1-উবুন্টু এসএমপি শুক্র 7 ডিসেম্বর 09:59:47 UTC 2018

উবুন্টু 18.04 (বায়োনিক বিভার)
4.15.0–1026-gcp
#27-উবুন্টু এসএমপি বৃহস্পতিবার 6 ডিসেম্বর 18:27:01 ইউটিসি 2018

টেবিল 1

Анализ

আসুন ডিফল্ট কার্নেল কনফিগারেশন, সেইসাথে বাক্সের বাইরে প্রতিটি ডিস্ট্রিবিউশনের প্যাকেজ ম্যানেজারের মাধ্যমে উপলব্ধ প্যাকেজের বৈশিষ্ট্যগুলি অধ্যয়ন করি। এইভাবে, আমরা শুধুমাত্র প্রতিটি ডিস্ট্রিবিউশনের ডিফল্ট মিরর থেকে প্যাকেজ বিবেচনা করি, অস্থির সংগ্রহস্থল (যেমন ডেবিয়ান 'টেস্টিং' মিরর) এবং তৃতীয় পক্ষের প্যাকেজগুলি (যেমন স্ট্যান্ডার্ড মিরর থেকে এনভিডিয়া প্যাকেজ) থেকে প্যাকেজগুলি উপেক্ষা করে। উপরন্তু, আমরা কাস্টম কার্নেল সংকলন বা নিরাপত্তা-কঠিন কনফিগারেশন বিবেচনা করি না।

কার্নেল কনফিগারেশন বিশ্লেষণ

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

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

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

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

অ্যাপ্লিকেশন বিশ্লেষণ

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

বিতরণ

মোট, আমরা সমস্ত ডিস্ট্রিবিউশনের জন্য 361 প্যাকেজ ডাউনলোড করেছি, শুধুমাত্র ডিফল্ট মিরর থেকে প্যাকেজগুলি বের করে। আমরা ELF এক্সিকিউটেবল ছাড়া প্যাকেজগুলিকে উপেক্ষা করেছি, যেমন সোর্স, ফন্ট, ইত্যাদি। ফিল্টার করার পরে, 556 প্যাকেজ রয়ে গেছে, যার মধ্যে মোট 129 বাইনারি রয়েছে। ডিস্ট্রিবিউশন জুড়ে প্যাকেজ এবং ফাইলের ডিস্ট্রিবিউশন চিত্রে দেখানো হয়েছে। 569.

Рис। 3

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

Рис। 4

প্রায় সব ডিস্ট্রিবিউশনে, 60% প্যাকেজের অন্তত 10টি নির্ভরতা থাকে। উপরন্তু, কিছু প্যাকেজের উল্লেখযোগ্যভাবে বড় সংখ্যক নির্ভরতা রয়েছে (100 টিরও বেশি)। বিপরীত প্যাকেজ নির্ভরতার ক্ষেত্রেও একই কথা প্রযোজ্য: প্রত্যাশিত হিসাবে, কয়েকটি প্যাকেজ বিতরণে অন্যান্য অনেক প্যাকেজ দ্বারা ব্যবহৃত হয়, তাই নির্বাচিত কয়েকটিতে দুর্বলতা উচ্চ ঝুঁকিপূর্ণ। উদাহরণ স্বরূপ, নিম্নোক্ত সারণী SLES, Centos 20, Debian 7 এবং Ubuntu 9-এ সর্বাধিক সংখ্যক বিপরীত নির্ভরতা সহ 18.04টি প্যাকেজের তালিকা করে (প্রতিটি সেল প্যাকেজ এবং বিপরীত নির্ভরতার সংখ্যা নির্দেশ করে)।

টেবিল 3

আকর্ষণীয় ঘটনা. যদিও বিশ্লেষণ করা সমস্ত OSs x86_64 আর্কিটেকচারের জন্য তৈরি করা হয়েছে, এবং বেশিরভাগ প্যাকেজের আর্কিটেকচারকে x86_64 এবং x86 হিসাবে সংজ্ঞায়িত করা হয়েছে, প্যাকেজগুলিতে প্রায়শই অন্যান্য আর্কিটেকচারের জন্য বাইনারি থাকে, যেমন চিত্র 5 এ দেখানো হয়েছে। XNUMX.

Рис। 5

পরবর্তী বিভাগে, আমরা বিশ্লেষিত বাইনারিগুলির বৈশিষ্ট্যগুলি নিয়ে আলোচনা করব।

বাইনারি ফাইল সুরক্ষা পরিসংখ্যান

সর্বনিম্নভাবে, আপনাকে আপনার বিদ্যমান বাইনারিগুলির জন্য নিরাপত্তা বিকল্পগুলির একটি মৌলিক সেট অন্বেষণ করতে হবে। বেশ কিছু লিনাক্স ডিস্ট্রিবিউশন স্ক্রিপ্ট সহ আসে যা এই ধরনের চেক সঞ্চালন করে। উদাহরণস্বরূপ, ডেবিয়ান/উবুন্টুর এমন একটি স্ক্রিপ্ট রয়েছে। এখানে তার কাজের একটি উদাহরণ:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

স্ক্রিপ্ট পাঁচটি পরীক্ষা করে সুরক্ষা ফাংশন:

• পজিশন ইন্ডিপেনডেন্ট এক্সিকিউটেবল (PIE): কার্নেলে ASLR সক্রিয় থাকলে র্যান্ডমাইজেশন অর্জনের জন্য একটি প্রোগ্রামের পাঠ্য বিভাগটি মেমরিতে সরানো যেতে পারে কিনা তা নির্দেশ করে।
• স্ট্যাক সুরক্ষিত: স্ট্যাক সংঘর্ষের আক্রমণ থেকে রক্ষা করার জন্য স্ট্যাক ক্যানারিগুলি সক্ষম করা হয়েছে কিনা।
• Fortify Source: অনিরাপদ ফাংশনগুলি (উদাহরণস্বরূপ, strcpy) তাদের আরও সুরক্ষিত প্রতিরূপগুলির সাথে প্রতিস্থাপিত হয় কিনা এবং রানটাইমে চেক করা কলগুলি তাদের অচেক করা অংশগুলির সাথে প্রতিস্থাপিত হয় (উদাহরণস্বরূপ, __memcpy_chk এর পরিবর্তে memcpy)।
• শুধুমাত্র-পঠন স্থানান্তর (RELRO): পুনঃস্থাপন সারণী এন্ট্রিগুলিকে শুধুমাত্র পঠনযোগ্য হিসাবে চিহ্নিত করা হয় যদি সেগুলি সম্পাদন শুরু হওয়ার আগে ট্রিগার করা হয়।
• অবিলম্বে বাইন্ডিং: প্রোগ্রাম এক্সিকিউশন শুরু হওয়ার আগে রানটাইম লিঙ্কার সমস্ত পদক্ষেপের অনুমতি দেয় কিনা (এটি সম্পূর্ণ RELRO-এর সমতুল্য)।

উপরের প্রক্রিয়াগুলি কি যথেষ্ট? দুর্ভাগ্যক্রমে না. উপরের সমস্ত প্রতিরক্ষাকে বাইপাস করার জন্য পরিচিত উপায় রয়েছে, তবে প্রতিরক্ষা যত শক্ত হবে আক্রমণকারীর জন্য বার তত বেশি। উদাহরণ স্বরূপ, RELRO বাইপাস পদ্ধতি PIE এবং অবিলম্বে বাঁধাই কার্যকর হলে প্রয়োগ করা আরও কঠিন। একইভাবে, একটি কার্যকরী শোষণ তৈরি করতে সম্পূর্ণ ASLR-এর জন্য অতিরিক্ত কাজ প্রয়োজন। যাইহোক, অত্যাধুনিক আক্রমণকারীরা ইতিমধ্যেই এই ধরনের সুরক্ষা পূরণের জন্য প্রস্তুত: তাদের অনুপস্থিতি মূলত হ্যাককে দ্রুততর করবে। তাই এই ব্যবস্থাগুলিকে প্রয়োজনীয় বিবেচনা করা অপরিহার্য সর্বনিম্ন.

আমরা অধ্যয়ন করতে চেয়েছিলাম কতগুলি বাইনারি ফাইল প্রশ্নে বন্টনগুলি এই এবং তিনটি অন্যান্য পদ্ধতি দ্বারা সুরক্ষিত:

• অনির্বাহযোগ্য বিট (NX) যে কোনো অঞ্চলে মৃত্যুদন্ড কার্যকর করা রোধ করে যা কার্যকর করা উচিত নয়, যেমন স্ট্যাক হিপ ইত্যাদি।
• RPATH/RUNPATH মিলিত লাইব্রেরিগুলি খুঁজে পেতে ডায়নামিক লোডার দ্বারা ব্যবহৃত এক্সিকিউশন পাথ বোঝায়। প্রথম এক বাধ্যতামূলক যেকোন আধুনিক সিস্টেমের জন্য: এর অনুপস্থিতি আক্রমণকারীদের নির্বিচারে মেমরিতে পেলোড লিখতে এবং এটিকে কার্যকর করতে দেয়। দ্বিতীয়টির জন্য, ভুল এক্সিকিউশন পাথ কনফিগারেশনগুলি অবিশ্বস্ত কোড প্রবর্তন করতে সাহায্য করে যা অনেকগুলি সমস্যার কারণ হতে পারে (যেমন বিশেষাধিকার বৃদ্ধিএবং অন্যান্য সমস্যা).
• স্ট্যাক সংঘর্ষ সুরক্ষা এমন আক্রমণগুলির বিরুদ্ধে সুরক্ষা প্রদান করে যা স্ট্যাকের মেমরির অন্যান্য অংশগুলিকে (যেমন হিপ) ওভারল্যাপ করে। সাম্প্রতিক শোষণ অপব্যবহার দেওয়া সিস্টেমড হিপ সংঘর্ষের দুর্বলতা, আমরা অনুভব করেছি যে আমাদের ডেটাসেটে এই প্রক্রিয়াটি অন্তর্ভুক্ত করা উপযুক্ত।

সুতরাং, আর কোনো ঝামেলা ছাড়াই, আসুন সংখ্যায় নেমে আসি। সারণি 4 এবং 5 যথাক্রমে এক্সিকিউটেবল ফাইল এবং বিভিন্ন ডিস্ট্রিবিউশনের লাইব্রেরির বিশ্লেষণের একটি সারাংশ রয়েছে।

• আপনি দেখতে পাচ্ছেন, বিরল ব্যতিক্রমগুলি সহ, NX সুরক্ষা সর্বত্র প্রয়োগ করা হয়েছে। বিশেষ করে, CentOS, RHEL এবং OpenSUSE-এর তুলনায় উবুন্টু এবং ডেবিয়ান ডিস্ট্রিবিউশনে এর সামান্য কম ব্যবহার লক্ষ করা যায়।
• স্ট্যাক ক্যানারিগুলি অনেক জায়গায় অনুপস্থিত, বিশেষ করে পুরানো কার্নেলের সাথে বিতরণে। সেন্টোস, আরএইচইএল, ডেবিয়ান এবং উবুন্টুর সর্বশেষ বিতরণে কিছু অগ্রগতি দেখা যাচ্ছে।
• ডেবিয়ান এবং উবুন্টু 18.04 বাদ দিয়ে, বেশিরভাগ ডিস্ট্রিবিউশনে দুর্বল PIE সমর্থন রয়েছে।
• OpenSUSE, Centos 7 এবং RHEL 7-এ স্ট্যাকের সংঘর্ষ সুরক্ষা দুর্বল এবং অন্যগুলিতে কার্যত অস্তিত্বহীন।
• আধুনিক কার্নেল সহ সমস্ত ডিস্ট্রিবিউশনে RELRO-এর জন্য কিছু সমর্থন রয়েছে, যার মধ্যে উবুন্টু 18.04 এগিয়ে রয়েছে এবং ডেবিয়ান দ্বিতীয় স্থানে রয়েছে।

ইতিমধ্যে উল্লিখিত হিসাবে, এই টেবিলের মেট্রিকগুলি বাইনারি ফাইলের সমস্ত সংস্করণের গড়। আপনি যদি কেবলমাত্র ফাইলগুলির সর্বশেষ সংস্করণগুলি দেখেন তবে সংখ্যাগুলি আলাদা হবে (উদাহরণস্বরূপ, দেখুন PIE বাস্তবায়নের সাথে ডেবিয়ান অগ্রগতি) অধিকন্তু, বেশিরভাগ ডিস্ট্রিবিউশনগুলি সাধারণত পরিসংখ্যান গণনা করার সময় বাইনারিতে কয়েকটি ফাংশনের নিরাপত্তা পরীক্ষা করে, কিন্তু আমাদের বিশ্লেষণে দেখায় যে ফাংশনগুলি শক্ত হয়ে গেছে। তাই, যদি 5টি ফাংশনের মধ্যে 50টি একটি বাইনারিতে সুরক্ষিত থাকে, তাহলে আমরা এটিকে 0,1 স্কোর দেব, যা শক্তিশালী করা ফাংশনের 10% এর সাথে মিলে যায়।

সারণি 4. চিত্রে দেখানো এক্সিকিউটেবল ফাইলের নিরাপত্তা বৈশিষ্ট্য। 3 (নির্বাহযোগ্য ফাইলের মোট সংখ্যার শতাংশ হিসাবে প্রাসঙ্গিক ফাংশন বাস্তবায়ন)

সারণি 5. চিত্রে দেখানো লাইব্রেরির নিরাপত্তা বৈশিষ্ট্য। 3 (গ্রন্থাগারের মোট সংখ্যার শতাংশ হিসাবে প্রাসঙ্গিক ফাংশন বাস্তবায়ন)

তাহলে কি অগ্রগতি আছে? অবশ্যই আছে: এটি পৃথক বিতরণের পরিসংখ্যান থেকে দেখা যেতে পারে (উদাহরণস্বরূপ, ডেবিয়ান), পাশাপাশি উপরের টেবিল থেকে। চিত্রে একটি উদাহরণ হিসাবে। চিত্র 6 উবুন্টু এলটিএস 5 এর তিনটি ধারাবাহিক বিতরণে সুরক্ষা ব্যবস্থার বাস্তবায়ন দেখায় (আমরা স্ট্যাক সংঘর্ষ সুরক্ষা পরিসংখ্যান বাদ দিয়েছি)। আমরা লক্ষ্য করেছি যে সংস্করণ থেকে সংস্করণে আরও বেশি সংখ্যক ফাইল স্ট্যাক ক্যানারি সমর্থন করে এবং আরও বেশি সংখ্যক বাইনারি সম্পূর্ণ RELRO সুরক্ষা সহ পাঠানো হয়।

Рис। 6

দুর্ভাগ্যবশত, বিভিন্ন ডিস্ট্রিবিউশনে বেশ কিছু এক্সিকিউটেবল ফাইলের এখনও উপরের কোনো সুরক্ষা নেই। উদাহরণস্বরূপ, উবুন্টু 18.04-এর দিকে তাকালে, আপনি এনজেটি বাইনারি (একটি গেটি প্রতিস্থাপন), পাশাপাশি mksh এবং lksh শেল, পিকোলিস্প ইন্টারপ্রেটার, এনভিডিয়া-কুডা-টুলকিট প্যাকেজগুলি (জিপিইউ-এক্সিলারেটেড অ্যাপ্লিকেশনগুলির জন্য একটি জনপ্রিয় প্যাকেজ) লক্ষ্য করবেন। যেমন মেশিন লার্নিং ফ্রেমওয়ার্ক), এবং klibc -utils। একইভাবে, ম্যান্ডোস-ক্লায়েন্ট বাইনারি (একটি প্রশাসনিক সরঞ্জাম যা আপনাকে এনক্রিপ্ট করা ফাইল সিস্টেমের সাথে মেশিনগুলিকে স্বয়ংক্রিয়ভাবে রিবুট করতে দেয়) পাশাপাশি rsh-redone-client (rsh এবং rlogin-এর পুনরায় প্রয়োগ) NX সুরক্ষা ছাড়াই শিপ, যদিও তাদের SUID অধিকার রয়েছে: (. এছাড়াও, বেশ কিছু স্যুড বাইনারিতে মৌলিক সুরক্ষা যেমন স্ট্যাক ক্যানারিগুলির অভাব রয়েছে (উদাহরণস্বরূপ, Xorg প্যাকেজ থেকে Xorg.wrap বাইনারি)।

সারাংশ এবং সমাপ্তি মন্তব্য

এই নিবন্ধে, আমরা আধুনিক লিনাক্স বিতরণের বেশ কয়েকটি নিরাপত্তা বৈশিষ্ট্য তুলে ধরেছি। বিশ্লেষণে দেখা গেছে যে সর্বশেষ উবুন্টু এলটিএস ডিস্ট্রিবিউশন (18.04) তুলনামূলকভাবে নতুন কার্নেল, যেমন উবুন্টু 14.04, 12.04 এবং ডেবিয়ান 9 এর মতো বিতরণগুলির মধ্যে সবচেয়ে শক্তিশালী OS এবং অ্যাপ্লিকেশন স্তর সুরক্ষা প্রয়োগ করে। যাইহোক, পরীক্ষা করা বিতরণগুলি CentOS, RHEL এবং OpenSUSE আমাদের সেটে ডিফল্টভাবে তারা প্যাকেজের একটি ঘন সেট তৈরি করে এবং সর্বশেষ সংস্করণে (CentOS এবং RHEL) ডেবিয়ান-ভিত্তিক প্রতিযোগীদের (ডেবিয়ান এবং উবুন্টু) তুলনায় তাদের স্ট্যাক সংঘর্ষ সুরক্ষার শতাংশ বেশি। CentOS এবং RedHat সংস্করণগুলির তুলনা করে, আমরা 6 থেকে 7 সংস্করণ পর্যন্ত স্ট্যাক ক্যানারি এবং RELRO বাস্তবায়নে বড় উন্নতি লক্ষ্য করি, তবে গড়ে CentOS RHEL-এর তুলনায় আরও বেশি বৈশিষ্ট্য প্রয়োগ করেছে। সাধারণভাবে, সমস্ত ডিস্ট্রিবিউশনের PIE সুরক্ষার প্রতি বিশেষ মনোযোগ দেওয়া উচিত, যা ডেবিয়ান 9 এবং উবুন্টু 18.04 ব্যতীত, আমাদের ডেটাসেটের বাইনারিগুলির 10% এরও কম ক্ষেত্রে প্রয়োগ করা হয়।

পরিশেষে, এটি লক্ষ করা উচিত যে যদিও আমরা গবেষণাটি ম্যানুয়ালি পরিচালনা করেছি, সেখানে অনেক সুরক্ষা সরঞ্জাম উপলব্ধ রয়েছে (যেমন Lynis, বাঘ, হাবল), যা বিশ্লেষণ করে এবং অনিরাপদ কনফিগারেশন এড়াতে সাহায্য করে। দুর্ভাগ্যবশত, এমনকি যুক্তিসঙ্গত কনফিগারেশনে শক্তিশালী সুরক্ষা শোষণের অনুপস্থিতির গ্যারান্টি দেয় না। এই কারণেই আমরা দৃঢ়ভাবে বিশ্বাস করি যে এটি নিশ্চিত করা অত্যাবশ্যক রিয়েল টাইমে আক্রমণের নির্ভরযোগ্য পর্যবেক্ষণ এবং প্রতিরোধ, শোষণের নিদর্শনগুলিতে ফোকাস করা এবং তাদের প্রতিরোধ করা।

উত্স: www.habr.com