paint-brush
AWS फायरक्रैकर VMM की माइक्रोआर्किटेक्चरल सुरक्षा: ख़तरा मॉडलद्वारा@autoencoder
379 रीडिंग
379 रीडिंग

AWS फायरक्रैकर VMM की माइक्रोआर्किटेक्चरल सुरक्षा: ख़तरा मॉडल

द्वारा Auto Encoder: How to Ignore the Signal Noise2m2024/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) बर्क सुनार, वॉर्सेस्टर पॉलिटेक्निक इंस्टीट्यूट वॉर्सेस्टर, एमए, यूएसए {[email protected]}।

लिंक की तालिका

3. ख़तरा मॉडल

हम फायरक्रैकर-आधारित सर्वर रहित क्लाउड प्रणालियों पर लागू होने वाले दो खतरा मॉडल प्रस्तावित करते हैं:


(1) उपयोगकर्ता-से-उपयोगकर्ता मॉडल (चित्र 3): एक दुर्भावनापूर्ण उपयोगकर्ता फायरक्रैकर वीएम के भीतर सैंडबॉक्स किए गए मनमाने कोड को चलाता है और डेटा लीक करने, डेटा इंजेक्ट करने या किसी अन्य उपयोगकर्ता के सैंडबॉक्स किए गए एप्लिकेशन के बारे में जानकारी प्राप्त करने या उस पर नियंत्रण करने का प्रयास करता है। इस मॉडल में, हम विचार करते हैं


(ए) हार्डवेयर का टाइम-स्लाइस्ड शेयरिंग, जहां दो उपयोगकर्ताओं के इंस्टैंस सीपीयू कोर पर बारी-बारी से निष्पादित होते हैं, और


(बी) भौतिक सह-स्थान, जहां दो उपयोगकर्ताओं का कोड एक साथ हार्डवेयर पर चलता है जिसे एक या दूसरे तरीके से साझा किया जाता है (उदाहरण के लिए, एक ही सीपीयू पर दो कोर या एक ही कोर में दो थ्रेड यदि एसएमटी सक्षम है)।


(2) उपयोगकर्ता-से-होस्ट मॉडल (चित्र 4): एक दुर्भावनापूर्ण उपयोगकर्ता होस्ट सिस्टम के कुछ घटक को लक्षित करता है: फायरक्रैकर VMM, KVM, या होस्ट सिस्टम कर्नेल का कोई अन्य भाग। इस परिदृश्य के लिए, हम केवल हार्डवेयर संसाधनों के समय-स्लाइस्ड शेयरिंग पर विचार करते हैं। ऐसा इसलिए है क्योंकि होस्ट केवल तभी कोड निष्पादित करता है जब अतिथि उपयोगकर्ता का VM बाहर निकलता है, उदाहरण के लिए किसी पेज फॉल्ट के कारण जिसे होस्ट कर्नेल या VMM द्वारा संभाला जाना होता है।


दोनों मॉडलों के लिए, हम मानते हैं कि एक दुर्भावनापूर्ण उपयोगकर्ता अपने एप्लिकेशन के रनटाइम वातावरण को नियंत्रित करने में सक्षम है। हमारे मॉडल में, दुर्भावनापूर्ण उपयोगकर्ताओं के पास अतिथि कर्नेल विशेषाधिकार नहीं होते हैं। इसलिए, दोनों मॉडल हमलावर को [1] द्वारा ग्रहण किए गए मॉडल की तुलना में थोड़ा कम विशेषाधिकार देते हैं, जहाँ अतिथि कर्नेल को VMM द्वारा चुना और कॉन्फ़िगर किया जाता है, लेकिन रनटाइम पर समझौता किया जाता है। इसके बजाय, हमारे मॉडल में हमलावर की क्षमताएँ AWS लैम्ब्डा और फ़ार्गेट में फायरक्रैकर की तैनाती में उपयोगकर्ताओं को दी गई क्षमताओं से मेल खाती हैं।