SBAT-এর সারমর্মের বিশ্লেষণ এবং হালনাগাদ করার সমস্যাসমূহ Windowsযা লোডিংকে প্রভাবিত করেছিল Linux

ম্যাথিউ গ্যারেট, একজন প্রখ্যাত কার্নেল ডেভেলপার Linuxযিনি মুক্ত সফটওয়্যারের উন্নয়নে অবদানের জন্য একসময় ফ্রি সফটওয়্যার ফাউন্ডেশন থেকে পুরস্কার পেয়েছিলেন, তিনি ডিজিটাল স্বাক্ষর বাতিল না করেই বুটলোডারের দুর্বলতা রোধ করার জন্য তৈরি SBAT (সিকিওর বুট অ্যাডভান্সড টার্গেটিং) পদ্ধতির সারমর্ম এবং আপডেটের সাথে সম্পর্কিত সাম্প্রতিক ঘটনায় এর ভূমিকা নিয়ে কথা বলেছেন। Windowsযার ফলে কিছু ডিস্ট্রিবিউশন লোড হওয়া বন্ধ হয়ে গিয়েছিল। Linuxএর সমান্তরালে ইনস্টল করা হয়েছে Windows যেসব সিস্টেমে UEFI Secure Boot সক্রিয় করা আছে, সেখানে। সংক্ষেপে, এর জন্য মাইক্রোসফট এবং কিছু ডিস্ট্রিবিউশনের ডেভেলপার উভয়ই দায়ী; মাইক্রোসফট আপডেটটি পুরোপুরি পরীক্ষা না করেই এমন সব সিস্টেমে এটি প্রয়োগ করেছে যেখানে করা উচিত ছিল না। Linuxযা GRUB-এ দুর্বলতা আবিষ্কৃত হওয়ার পরেও GRUB বুটলোডার এবং SBAT জেনারেশন নম্বর আপডেট করেনি।

নীচে গ্যারেটের নোটের একটি অনুবাদ রয়েছে:

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

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

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

কেন এটি হঠাৎ প্রাসঙ্গিক হয়ে উঠল? SBAT সম্প্রদায়ের সম্মিলিত প্রচেষ্টায় তৈরি করা হয়েছিল। Linux এবং মাইক্রোসফ্ট একটি আপডেট প্রকাশ করার সিদ্ধান্ত নিয়েছে Windowsযা সিস্টেমগুলোকে একটি নির্দিষ্ট স্তরের নিচের নিরাপত্তা প্রজন্মের GRUB সংস্করণগুলোকে বিশ্বাস না করতে নির্দেশ দিয়েছিল। এটি করা হয়েছিল কারণ এই GRUB সংস্করণগুলোতে প্রকৃত নিরাপত্তা দুর্বলতা ছিল, যা আক্রমণকারীদেরকে সিকিওর বুট চেইন ভাঙতে সক্ষম করত। Windowsএবং আমরা এমন ম্যালওয়্যারের বাস্তব উদাহরণ দেখেছি যা এটি করতে চেয়েছিল (ব্ল্যাক লোটাস বুটলোডারের একটি দুর্বলতার সুযোগ নিয়েছিল)। Windowsকিন্তু GRUB দুর্বলতাটিও ঠিক ততটাই কার্যকর ছিল)। নিছক নিরাপত্তার দৃষ্টিকোণ থেকে, এটি একটি সম্পূর্ণ বৈধ আকাঙ্ক্ষা।

এখন, "Something went seriously wrong" মেসেজ এবং এই আপডেটের ফলে বুট করতে না পারার বিষয়ে বলতে গেলে, এটি শিম (Shim) থেকেই আসছে, মাইক্রোসফটের কোনো কোড থেকে নয়। শিম SBAT আপডেটগুলোকে বিবেচনায় রাখে এবং সিস্টেমের অন্যান্য বুটলোডার দ্বারা গৃহীত নিরাপত্তা নীতি লঙ্ঘন না করার জন্য এটি করে থাকে। যদিও মাইক্রোসফট একটি SBAT আপডেট প্রকাশ করেছে, এর জন্য বুটলোডারটিই দায়ী। Linux এর ফলে, এটি GRUB-এর পুরোনো সংস্করণগুলো চালু করতে অস্বীকার করে। সবকিছু ঠিকঠাক কাজ করে।

মানুষেরা যে সমস্যার সম্মুখীন হয়েছেন তা হলো একাধিক বন্টন Linux নতুন প্রজন্মের নিরাপত্তা সহ GRUB-এর সংস্করণ প্রকাশ করা হয়নি, এবং তাই GRUB-এর এই সংস্করণগুলিকে অসুরক্ষিত বলে মনে করা হয় (এটি উল্লেখ্য যে GRUB মাইক্রোসফট দ্বারা নয়, বরং ডিস্ট্রিবিউশনগুলি নিজেরাই সাইন করে, তাই এখানে বাইরে থেকে আসা কোনো ল্যাগ নেই)। মাইক্রোসফটের পরিকল্পনা অনুযায়ী, আপডেটটি Windows আপডেটটি শুধুমাত্র চলমান সিস্টেমগুলিতে SBAT আপডেট প্রয়োগ করার কথা ছিল। Windowsএবং ইনস্টল করা ডিস্ট্রিবিউশনটি GRUB ও SBAT জেনারেশন আপডেট না করা পর্যন্ত যেকোনো ডুয়াল-বুট ইনস্টলেশন আক্রমণের ঝুঁকিতে থাকতো। দুর্ভাগ্যবশত, যেমনটা এখন স্পষ্ট, এটি উদ্দেশ্য অনুযায়ী কাজ করেনি, এবং অন্তত কিছু ডুয়াল-বুট সিস্টেম আপডেটটি প্রয়োগ করার পরেও ডিস্ট্রিবিউশনটির Shim, GRUB লোড করতে অস্বীকার করেছে।

মূল কথাটা কী? মাইক্রোসফট (স্বাভাবিক কারণেই) চায়নি Windows GRUB-এর একটি দুর্বল সংস্করণ ব্যবহার করে আক্রমণ করা যেতে পারে, যাকে ধোঁকা দিয়ে যথেচ্ছ কোড চালানো এবং তারপর কার্নেলে একটি বুটকিট প্রবেশ করানো সম্ভব। Windows বুট করার সময়। মাইক্রোসফট একটি আপডেট প্রকাশ করে এটি করেছিল। Windowsযা SBAT ভেরিয়েবলটি আপডেট করে নির্দেশ করে যে, এই সিস্টেমগুলিতে GRUB-এর ঝুঁকিপূর্ণ সংস্করণগুলি বুট করা উচিত নয়। Shim ডিস্ট্রিবিউশন দ্বারা প্রদত্ত প্রথম-পর্যায়ের বুটলোডারটি এই ভেরিয়েবলটি পড়ে, GRUB-এর ইনস্টল করা কপি থেকে SBAT পার্টিশনটি পড়ে, বুঝতে পারে যে দুটির মধ্যে সংঘাত রয়েছে, এবং "Something went severely wrong" বার্তাটি দিয়ে GRUB লোড করতে অস্বীকার করে। এই আপডেটটি ডুয়াল-বুট সিস্টেমে প্রয়োগ করার জন্য উদ্দিষ্ট ছিল না, কিন্তু তা সত্ত্বেও এটি প্রয়োগ করা হয়েছিল।

সাধারণভাবে:

1) মাইক্রোসফ্ট এমন সিস্টেমে আপডেটটি প্রয়োগ করেছে যাতে এটি প্রয়োগ করার কথা ছিল না।

২) কিছু বন্টন Linux GRUB-এ দুর্বলতা আবিষ্কৃত হওয়ার পরেও GRUB বুটলোডার এবং SBAT নিরাপত্তা প্রজন্ম আপডেট করা হয়নি।

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

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

যাইহোক, আমি এই প্রক্রিয়াটি বাস্তবায়নের সাথে গভীরভাবে জড়িত ছিলাম। Linux ২০১২ সালে আমি Shim-এর প্রথম প্রোটোটাইপ লিখেছিলাম (যা এখন একটি উল্লেখযোগ্যভাবে উন্নত বুটলোডার, যা আরও বেশি সংখ্যক মানুষ সমর্থন করে এবং যা আমি বেশ কয়েক বছর ধরে স্পর্শ করিনি), তাই আপনি যদি কাউকে দোষ দিতে চান, তাহলে নির্দ্বিধায় আমাকেই দোষ দিতে পারেন। এমনটা হওয়া উচিত ছিল না, এবং আপনি যদি মাইক্রোসফট বা কোনো ডিস্ট্রো না হন... Linuxতাহলে এটা তোমার দোষ নয়। আমি ক্ষমা চাইছি।

উত্স: opennet.ru