paint-brush
AWS ফায়ারক্র্যাকার VMM এর মাইক্রোআর্কিটেকচারাল সিকিউরিটি: মাইক্রোআর্কিটেকচারাল অ্যাটাক এবং ডিফেন্সের বিশ্লেষণদ্বারা@autoencoder
466 পড়া
466 পড়া

AWS ফায়ারক্র্যাকার VMM এর মাইক্রোআর্কিটেকচারাল সিকিউরিটি: মাইক্রোআর্কিটেকচারাল অ্যাটাক এবং ডিফেন্সের বিশ্লেষণ

দ্বারা Auto Encoder: How to Ignore the Signal Noise10m2024/06/13
Read on Terminal Reader

অতিদীর্ঘ; পড়তে

এই গবেষণাপত্রটি তদন্ত করে যে ফায়ারক্র্যাকার মাইক্রোআর্কিটেকচারাল আক্রমণের বিরুদ্ধে কতটা নিরাপদ।
featured image - AWS ফায়ারক্র্যাকার VMM এর মাইক্রোআর্কিটেকচারাল সিকিউরিটি: মাইক্রোআর্কিটেকচারাল অ্যাটাক এবং ডিফেন্সের বিশ্লেষণ
Auto Encoder: How to Ignore the Signal Noise HackerNoon profile picture
0-item

লেখক:

(1) জেন ওয়েইসম্যান, ওরচেস্টার পলিটেকনিক ইনস্টিটিউট ওরচেস্টার, এমএ, ইউএসএ {[email protected]};

(2) টমাস আইজেনবার্থ, লুবেক ইউনিভার্সিটি লুবেক, এসএইচ, জার্মানি {[email protected]};

(3) থোর টাইম্যান, লুবেক ইউনিভার্সিটি লুবেক, এসএইচ, জার্মানি {[email protected]};

(4) Berk Sunar, Worcester Polytechnic Institute Worcester, MA, USA {[email protected]}।

লিঙ্কের টেবিল

5. ফায়ারক্র্যাকার মাইক্রোভিমে মাইক্রোআর্কিটেকচারাল আক্রমণ এবং প্রতিরক্ষার বিশ্লেষণ

এই বিভাগে আমরা ফায়ারক্র্যাকার মাইক্রোভিএম-এ বেশ কয়েকটি মাইক্রোআর্কিটেকচারাল সাইড-চ্যানেল এবং অনুমানমূলক আক্রমণ PoC-এর আমাদের বিশ্লেষণ উপস্থাপন করি। আমরা বেয়ার মেটালে এবং ফায়ারক্র্যাকার দৃষ্টান্তে এই PoCs পরীক্ষা করি এবং বিভিন্ন পরিস্থিতিতে প্রাসঙ্গিক মাইক্রোকোড প্রতিরক্ষা পরীক্ষা করি। আমরা একটি Intel Skylake 4114 CPU সহ একটি সার্ভারে আমাদের পরীক্ষা চালাই


সারণী 1: সমস্ত মাইক্রোআর্কিটেকচারাল ডিফেন্স কার্নেল বিকল্পগুলি অক্ষম সহ মেডুসার পার্শ্ব-চ্যানেলগুলির উপস্থিতি। নোট করুন যে ক্যাশে ইনডেক্সিং লিক এবং ব্লক রাইটের সিক্রেট (হলুদে হাইলাইট করা) এর সংমিশ্রণ ফায়ারক্র্যাকার ভিএম-এ কাজ করে কিন্তু বেয়ার মেটালে নয়।


যার ভার্চুয়ালাইজেশন হার্ডওয়্যার এক্সটেনশন এবং এসএমটি সক্ষম। CPU মাইক্রোকোড সংস্করণ 0x2006b06[2] এ চলে। হোস্ট OS হল উবুন্টু 20.04 একটি লিনাক্স 5.10 কার্নেল সহ। আমরা ফায়ারক্র্যাকার v1.0.0 এবং v1.4.0 ব্যবহার করেছি, জুলাই 2023-এর সর্বশেষ সংস্করণ, লিনাক্স কার্নেল 5.4 এর সাথে একটি উবুন্টু 18.04 গেস্ট চালানোর জন্য যা অ্যামাজন দ্বারা সরবরাহ করা হয় দ্রুত-শুরু নির্দেশিকা[3] অনুসরণ করার সময়।


সংক্ষেপে, AWS ফায়ারক্র্যাকারের সাথে প্রদত্ত প্রস্তাবিত উৎপাদন হোস্ট সেটআপ অপর্যাপ্ত যখন ভাড়াটেদেরকে দূষিত প্রতিবেশীদের থেকে রক্ষা করার জন্য আসে। ফায়ারক্র্যাকার তাই তার দাবিকৃত বিচ্ছিন্নতা গ্যারান্টি প্রদান করতে ব্যর্থ হয়। এই কারণ


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


(2) আমরা দেখাই যে ভাড়াটেরা সুপারিশকৃত পাল্টা ব্যবস্থা প্রয়োগ করার সময় Spectre-PHT বা Spectre-BTB এর মাধ্যমে তথ্য ফাঁস থেকে সঠিকভাবে সুরক্ষিত নয়। SMT নিষ্ক্রিয় করার সময়ও Spectre-PHT ভেরিয়েন্টগুলি একটি সমস্যা থেকে যায়৷


(3) আমরা ফায়ারক্র্যাকার v1.0.0 এবং v1.4.0 এর মধ্যে PoC পারফরম্যান্সে কোনও পার্থক্য লক্ষ্য করিনি।


আমরা উপসংহারে পৌঁছেছি যে ফায়ারক্র্যাকার দ্বারা সরবরাহ করা ভার্চুয়ালাইজেশন স্তরটি মাইক্রোআর্কিটেকচারাল আক্রমণগুলিতে খুব কম প্রভাব ফেলে এবং ফায়ারক্র্যাকারের সিস্টেম সুরক্ষা সুপারিশগুলি অপর্যাপ্ত।

5.1 মেডুসা

আমরা আমাদের টেস্ট সিস্টেমের বেয়ার মেটাল এবং ফায়ারক্র্যাকার ভিএম-এ মেডুসা [৩৭] সাইড-চ্যানেলগুলির জন্য মোঘিমির PoCs [৩৫] মূল্যায়ন করেছি (MDS [২৫] এর MLPDS রূপ হিসাবে ইন্টেল দ্বারা শ্রেণীবদ্ধ)। বিভাগ 2.4.2-এ বর্ণিত তিনটি পরিচিত ভেরিয়েন্টের প্রতিটির জন্য একটি লিকিং PoC রয়েছে৷ আমরা PoC লাইব্রেরি থেকে দুটি শিকার প্রোগ্রাম ব্যবহার করেছি:


সারণি 2: মেডুসার আক্রমণ থেকে বেয়ার মেটাল বনাম ফায়ারক্র্যাকারের শিকারদের রক্ষা করার জন্য প্রয়োজনীয় প্রশমন। মনে রাখবেন যে AWS-এর প্রস্তাবিত প্রশমন, nosmt, হাইলাইট করা ক্যাশে ইন্ডেক্সিং/ব্লক রাইটের বৈকল্পিককে বাধা দেয় না যা ফায়ারক্র্যাকার (cf. টেবিল 1) দ্বারা সক্ষম করা হয়েছে, বা ছায়া REP MOV ছাড়া অন্য কোনো রূপ।


• "ব্লক রাইট" প্রোগ্রামটি একটি লুপে পরপর প্রচুর পরিমাণে ডেটা লেখে (যাতে প্রসেসর বারবার স্টোর শনাক্ত করবে এবং তাদের একত্রিত করবে)।


• "REP MOV" প্রোগ্রামটি একই ধরনের অপারেশন করে, কিন্তু REP MOV নির্দেশের পরিবর্তে অনেক নির্দেশের পরিবর্তে ডেটার ছোট ব্লকগুলিকে লুপে সরিয়ে নেয়।


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


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

5.2 RIDL এবং আরও অনেক কিছু

এই বিভাগে, আমরা ভ্যান স্কাইক এট আল-এর 2019 পেপার [50] এর পাশাপাশি প্রদত্ত RIDL PoC প্রোগ্রামগুলির [51] একটি মূল্যায়ন উপস্থাপন করি। RIDL হল MDS আক্রমণের একটি শ্রেণী যা CPU এর ভিতরের বাফার থেকে অনুমানমূলক লোড ব্যবহার করে (ক্যাশে বা মেমরি থেকে নয়)। RIDL PoC সংগ্রহস্থলে কাগজের পরবর্তী সংযোজনে প্রকাশিত আক্রমণের উদাহরণ এবং ফলআউট MDS আক্রমণের একটি রূপও অন্তর্ভুক্ত রয়েছে।


5.2.1 ফলাফল। সারণি 3 RIDL PoCs সম্পর্কে কিছু প্রাথমিক তথ্য দেখায় যা আমরা পরীক্ষা করেছি এবং আক্রমণ প্রতিরোধে প্রাসঙ্গিক পাল্টা ব্যবস্থার কার্যকারিতা। আমরা ফায়ারক্র্যাকার মাইক্রোভিএম সিস্টেমের উচ্চতর হার্ডওয়্যার নিরাপত্তার অ্যামাজনের দাবির মূল্যায়ন করতে বেয়ার মেটাল এবং ফায়ারক্র্যাকারে আক্রমণের তুলনা করেছি। ফায়ারক্র্যাকার সিস্টেমে পরীক্ষা করার জন্য, আমরা হোস্ট সিস্টেম (H) এবং ফায়ারক্র্যাকার গেস্ট কার্নেল (VM) এ সক্রিয় কাউন্টারমেজার ফ্ল্যাগগুলির মধ্যে পার্থক্য করি। nosmt এবং mds কার্নেল ফ্ল্যাগগুলি ছাড়াও, আমরা kaslr, pti, এবং l1tf সহ অন্যান্য প্রাসঙ্গিক পতাকা (cf. বিভাগ 2.4.4, [21]) পরীক্ষা করেছি, কিন্তু খুঁজে পাইনি যে তারা এই প্রোগ্রামগুলির কোনওটির উপর প্রভাব ফেলেছে। আমরা tsx_async_abort প্রশমনকে বাদ দিয়েছি যেহেতু আমরা যে CPU-তে পরীক্ষা করেছি তাতে mds প্রশমন অন্তর্ভুক্ত রয়েছে যা tsx_async_abort কার্নেল পতাকাকে অপ্রয়োজনীয় করে তোলে [20]।


সাধারণভাবে, আমরা দেখেছি যে mds সুরক্ষা RIDL আক্রমণের বেশিরভাগের বিরুদ্ধে পর্যাপ্তভাবে রক্ষা করে না। যাইহোক, এসএমটি নিষ্ক্রিয় করা এই শোষণের বেশিরভাগই প্রশমিত করে। এটি ইন্টেলের [25] এবং লিনাক্স ডেভেলপারদের [21] বিবৃতিগুলির সাথে সামঞ্জস্যপূর্ণ যে হাইপারথ্রেড জুড়ে MDS আক্রমণ প্রতিরোধ করতে SMT অবশ্যই নিষ্ক্রিয় করা আবশ্যক। এই PoC-এর মধ্যে দুটি আউটলায়ার হল alignment_write, যার জন্য হোস্টে nosmt এবং mds উভয়ই প্রয়োজন, এবং pgtable_leak_notsx, যা শুধুমাত্র mds পাল্টা ব্যবস্থা দ্বারা প্রশমিত হয়। alignment_write-এর উপর নির্ভরশীল ফাঁস অনুমান ট্রিগার করার জন্য একটি পৃষ্ঠা টেবিল ফল্ট লিকের পরিবর্তে একটি প্রান্তিককরণ ফল্ট ব্যবহার করে [50]। RIDL পেপার [50] এবং সম্পর্কিত VRS শোষণের ইন্টেলের ডকুমেন্টেশন [26] অন্যান্য PoC-তে পাওয়া পৃষ্ঠা-ফল্ট-ভিত্তিক MFBDS আক্রমণ থেকে এই আক্রমণটিকে ঠিক কী আলাদা করে সে সম্পর্কে স্পষ্ট নয়, তবে আমাদের পরীক্ষামূলক ফলাফলগুলি ইঙ্গিত দেয় যে ফুটো হওয়ার মাইক্রোআর্কিটেকচারাল মেকানিজম। স্বতন্ত্র pgtable_leak_notsx-এর আচরণের জন্য একটি সহজ এবং যুক্তিসঙ্গত ব্যাখ্যা রয়েছে, যা একটি মূল কারণে এই PoC গুলির মধ্যে অনন্য: এটিই একমাত্র শোষণ যা নিরাপত্তা সীমানা অতিক্রম করে (কার্ণেল থেকে পৃষ্ঠার টেবিলের মানগুলি ফাঁস করার পরিবর্তে) একটি একক থ্রেডের মধ্যে আরেকটি থ্রেড। এটা স্বতঃসিদ্ধ যে মাল্টি-থ্রেডিং নিষ্ক্রিয় করা এই একক-থ্রেডেড শোষণে সামান্য প্রভাব ফেলবে। যাইহোক, এমডিএস কাউন্টারমেজার একই থ্রেডের মধ্যে কার্নেল প্রিভিলেজ এক্সিকিউশন থেকে ইউজার-প্রিভিলেজ এক্সিকিউশনে স্যুইচ করার আগে মাইক্রোআর্কিটেকচারাল বাফারগুলিকে ফ্লাশ করে, আক্রমণকারী ব্যবহারকারী কোডটি ফাঁস করার আগে LFB থেকে কার্নেল কোড দ্বারা অ্যাক্সেস করা পৃষ্ঠা টেবিলের ডেটা মুছে দেয়।


মেডুসার বিপরীতে, এই পিওসিগুলির বেশিরভাগই smt অক্ষম করার AWS-এর সুপারিশ দ্বারা প্রশমিত হয়। যাইহোক, মেডুসার মতো, ফায়ারক্র্যাকার ভিএমএম নিজেই এই আক্রমণগুলির বিরুদ্ধে কোনও মাইক্রোআর্কিটেকচারাল সুরক্ষা প্রদান করে না।

5.3 স্পেকটার

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


সারণি 3: RIDL এবং অন্যান্য MDS আক্রমণ থেকে বেয়ার মেটাল বনাম ফায়ারক্র্যাকারের শিকারদের রক্ষা করার জন্য প্রয়োজনীয় প্রশমন। প্রস্তাবিত nosmt প্রশমন বেশিরভাগের বিরুদ্ধে রক্ষা করে কিন্তু এই সব রূপের নয়। ধারণার সমস্ত প্রমাণ একই ফলাফল সহ Firecracker v1.0.0 এবং v1.4.0-এ পরীক্ষা করা হয়েছে।


সিস্টেম অপারেটরদের প্রায়ই পারফরম্যান্স বনাম নিরাপত্তা ট্রেড-অফের জন্য সিদ্ধান্ত নিতে হয়। এই বিভাগে আমরা আগে বর্ণিত উভয় হুমকি মডেলে ফায়ারক্র্যাকার ভাড়াটেদের জন্য উপলব্ধ স্পেকটার আক্রমণের পৃষ্ঠের মূল্যায়ন করি। স্পেকটার আক্রমণের বিস্তৃত পরিসরের মূল্যায়ন করার জন্য, আমরা [15] এ প্রদত্ত PoCs-এর উপর নির্ভর করি। Spectre-PHT, Spectre-BTB, এবং SpectreRSB-এর জন্য, সংগ্রহস্থলে প্রতিটিতে চারটি PoC রয়েছে। আক্রমণকারী যেভাবে BPU-কে ভুল বোঝায় তাতে তাদের পার্থক্য রয়েছে। চারটি সম্ভাবনা হল (1) একই-প্রক্রিয়া–আক্রমণকারীর বিপিইউ-কে বিভ্রান্ত করার জন্য শিকার প্রক্রিয়া বা তার ইনপুটগুলির উপর নিয়ন্ত্রণ রয়েছে–(2) ক্রস-প্রক্রিয়া–আক্রমণকারী শাখার পূর্বাভাসগুলিকে প্রভাবিত করার জন্য একটি পৃথক প্রক্রিয়ায় তার নিজস্ব কোড চালায় ভিকটিম প্রসেস-(ক) ইন-প্লেস-আক্রমণকারী BPU-কে ব্রাঞ্চ নির্দেশনা দিয়ে ভুল করে যেটা একই ভার্চুয়াল অ্যাড্রেসে থাকে যেটা টার্গেট ব্রাঞ্চের মতোই থাকে যেটা আক্রমণকারী শিকারের প্রক্রিয়ায় ভুল অনুমান করতে চায়-(b) এর বাইরে- স্থান–আক্রমণকারী বিপিইউকে শাখা নির্দেশনা দিয়ে ভুল করে যে ঠিকানায় থাকে যা শিকার প্রক্রিয়ার লক্ষ্য শাখার সাথে সঙ্গতিপূর্ণ।


(1) একই-প্রক্রিয়া: আক্রমণকারীর ভিকটিম প্রক্রিয়া বা বিপিইউকে বিকৃত করার জন্য এর ইনপুটগুলির উপর নিয়ন্ত্রণ রয়েছে,


(2) ক্রস-প্রক্রিয়া: আক্রমণকারী তার নিজস্ব কোড চালায় একটি পৃথক প্রক্রিয়ায় শিকার প্রক্রিয়ার শাখার পূর্বাভাসকে প্রভাবিত করতে,


(3) ইন-প্লেস: আক্রমণকারী BPU-কে শাখা নির্দেশনা দিয়ে ভুল করে যেটি লক্ষ্য শাখার মতো একই ভার্চুয়াল ঠিকানায় থাকে যে আক্রমণকারী শিকার প্রক্রিয়ায় ভুল অনুমান করতে চায়


(4) স্থানের বাইরে: আক্রমণকারী BPU-কে শাখা নির্দেশনা দিয়ে ভুল করে যে ঠিকানায় থাকে যা শিকার প্রক্রিয়ার লক্ষ্য শাখার সাথে সঙ্গতিপূর্ণ।


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


5.3.1 ফলাফল। হোস্ট সিস্টেমে এবং ফায়ারক্র্যাকার ভিএম-এর ভিতরে AWS-এর প্রস্তাবিত পাল্টা ব্যবস্থা [8] (ব্যবহৃত লিনাক্স কার্নেলের জন্য ডিফল্ট, cf। চিত্র 5) সক্রিয় করা হয়েছে, আমরা দেখতে পাচ্ছি যে Spectre-RSB হোস্টে এবং ভিএম-এর ভিতরে এবং জুড়ে উভয় ক্ষেত্রেই সফলভাবে প্রশমিত হয়েছে। (cf. টেবিল 4)। অন্যদিকে, Spectre-STL, Spectre-BTB, এবং Spectre-PHT নির্দিষ্ট পরিস্থিতিতে তথ্য ফাঁসের অনুমতি দেয়।


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


Spectre-PHT-এর জন্য, কার্নেল পাল্টা ব্যবস্থার মধ্যে রয়েছে ব্যবহারকারী-পয়েন্টার স্যানিটাইজেশন এবং প্রিভিলেজ লেভেলের সুইচগুলিতে বাধা (ল্যাফেন্স) ব্যবহার করা। তাই আমরা এই উপসংহারে পৌঁছেছি যে SpectrePHT হোস্ট সিস্টেমের জন্য খুব সামান্যই কোনো হুমকি দেয় না। যাইহোক, এই


সারণি 4: স্পেকটার PoCs AWS ফায়ারক্র্যাকার প্রস্তাবিত পাল্টা ব্যবস্থার সাথে চালিত হয় (cf. চিত্র 5 এবং [8])। স্পেকটার আক্রমণ থেকে ভাড়াটিয়াদের রক্ষা করার ক্ষেত্রে এই প্রতিরোধ ব্যবস্থাগুলি - যা ব্যবহার করা লিনাক্স কার্নেলের জন্য ডিফল্ট - অপর্যাপ্ত। ফায়ারক্র্যাকার v1.0.0 এবং v1.4.0 এর সাথে পরীক্ষাগুলি একই ফলাফল দিয়েছে৷


প্রশমন দুটি হাইপারথ্রেডকে একে অপরের থেকে রক্ষা করে না যদি তারা একই শারীরিক কোরে সমান্তরালভাবে কার্যকর করে। এই কারণেই চারটি Spectre-PHT মিস্ট্রেনিং ভেরিয়েন্টগুলি হোস্ট সিস্টেমের পাশাপাশি Firecracker VM-এর ভিতরে সম্পূর্ণরূপে কার্যকরী। সারণি 4 এ দেখা যায়, এসএমটি অক্ষম থাকলেও এটি সত্য থাকে[4]। প্রকৃতপক্ষে, একই শারীরিক থ্রেডে উভয় ভিএম পিন করা স্পেক্টার-পিএইচটি-এর ক্রস-প্রসেস আউট-অফ-প্লেস সংস্করণকে সক্ষম করে যেখানে আমরা SMT ক্ষেত্রে ফাঁস লক্ষ্য করিনি। এটি স্পেকটার-পিএইচটি ব্যবহারকারী-থেকে-ব্যবহারকারীর জন্য একটি উল্লেখযোগ্য হুমকি তৈরি করে।


যখন AWS প্রস্তাবিত পাল্টা ব্যবস্থা সক্ষম করা থাকে তখন Spectre-BTB PoCs আংশিকভাবে কার্যকরী হয়। মূল বৈকল্পিক যা বিটিবিকে একই প্রক্রিয়ায় এবং একই ঠিকানায় ভুল করে দেয় তা সম্পূর্ণরূপে কার্যকর যখন একই-প্রক্রিয়ার বাইরে-স্থানে ভুল হয়


চিত্র 5: স্পেকটার পরীক্ষার সময় হোস্ট এবং গেস্ট কার্নেলে স্পেকটার প্রশমন সক্রিয় করা হয়েছে। এই সেটআপটি হোস্ট প্রোডাকশন সিস্টেমের জন্য AWS দ্বারা সুপারিশ করা হয়েছে [8]।


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


চিত্র 5-এ তালিকাভুক্ত কাউন্টারমেজারগুলি ছাড়াও, হোস্ট কার্নেলে VM এন্ট্রি এবং এক্সিট পয়েন্ট[5]-এ কম্পাইল করা হয়েছে স্পেকটার পাল্টা ব্যবস্থা যা কার্নেল একটি VM প্রস্থান করার সময় হোস্ট কার্নেলে আক্রমণ করা থেকে ক্ষতিকারক গেস্টদের সম্পূর্ণরূপে নিষ্ক্রিয় করতে পারে।


সংক্ষেপে, আমরা বলতে পারি যে লিনাক্সের ডিফল্ট পাল্টা ব্যবস্থা- যা AWS ফায়ারক্র্যাকার দ্বারা সুপারিশ করা হয়- শুধুমাত্র আংশিকভাবে স্পেকটার প্রশমিত করে। সঠিকভাবে, আমরা দেখাই:


• Spectre-PHT এবং Spectre-BTB এখনও AWS-এর প্রস্তাবিত পাল্টা ব্যবস্থার সাথে অতিথি-থেকে-অতিথি পরিস্থিতিতে ভাড়াটেদের মধ্যে তথ্য ফাঁস করতে পারে-যার মধ্যে SMT-অক্ষম করা রয়েছে।


• হোস্ট কার্নেল সম্ভবত ভিএম এন্ট্রি এবং প্রস্থানকে রক্ষা করার জন্য লিনাক্স কার্নেলে সংকলিত অতিরিক্ত সতর্কতা দ্বারা যথেষ্ট সুরক্ষিত। এটি, তবে, ফায়ারক্র্যাকার দ্বারা প্রদত্ত নিরাপত্তা ব্যবস্থার জন্য অর্থোগোনাল।


পরিলক্ষিত সমস্ত ফুটো ফায়ারক্র্যাকার সংস্করণ ব্যবহার করা থেকে স্বাধীন ছিল।


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


সতর্ক পাঠক আশ্চর্য হতে পারেন কেন Spectre-BTB STIBP কাউন্টারমেজার (cf. চিত্র 5) সাথে একটি সমস্যা রয়ে গেছে কারণ এই মাইক্রোকোড প্যাচটি অন্য থ্রেড থেকে উদ্ভূত ভবিষ্যদ্বাণী তথ্য ব্যবহার করা থেকে শাখার পূর্বাভাস বন্ধ করার জন্য ডিজাইন করা হয়েছিল। এটি কিছু সময়ের জন্য আমাদের বিভ্রান্ত করেছিল যতক্ষণ না সম্প্রতি Google একটি নিরাপত্তা পরামর্শ[6] প্রকাশ করেছে যা Linux 6.2-এ একটি ত্রুটি চিহ্নিত করে যা IBRS সক্রিয় থাকা অবস্থায় STIBP প্রশমনকে অক্ষম করে রাখে। আমরা যাচাই করেছি যে কোড বিভাগটি যেটিকে সমস্যার জন্য দায়ী হিসেবে চিহ্নিত করা হয়েছে সেটিও Linux 5.10 সোর্স কোডে রয়েছে। তাই আমাদের অনুমান হল যে Google দ্বারা চিহ্নিত একই সমস্যা আমাদের সিস্টেমেও ঘটে।


এই কাগজটি CC BY-NC-ND 4.0 DEED লাইসেন্সের অধীনে arxiv-এ উপলব্ধ


একটি নতুন সংস্করণে মাইক্রোকোড আপডেট করা আমাদের সিস্টেমে TSX অক্ষম করবে যা TSX-ভিত্তিক MDS ভেরিয়েন্টগুলির সাথে পরীক্ষাকে অসম্ভব করে তুলবে।


[3] https://github.com/firecracker-microvm/firecracker/blob/ dbd9a84b11a63b5e5bf201e244fe83f0bc76792a/docs/getting-started.md


[৪] আক্রমণকারী এবং ভিকটিম প্রসেসকে একই কোরে (1PT)) পিন করে এটি অনুকরণ করা হয়।


[৫] https://elixir.bootlin.com/linux/v5.10/source/arch/x86/kvm/vmx/vmenter.S#L191


[6] https://github.com/google/security-research/security/advisories/GHSA-mj4w6495-6crx