MacOS पर प्रक्रियाओं और कर्नेल एक्सटेंशन की सुरक्षा कैसे करें

नमस्ते, हबर! आज मैं इस बारे में बात करना चाहूंगा कि आप macOS में प्रक्रियाओं को हमलावरों के हमलों से कैसे बचा सकते हैं। उदाहरण के लिए, यह एंटीवायरस या बैकअप सिस्टम के लिए उपयोगी है, खासकर जब से macOS के तहत किसी प्रक्रिया को "मारने" के कई तरीके हैं। कट के अंतर्गत इसके बारे में और सुरक्षा विधियों के बारे में पढ़ें।

किसी प्रक्रिया को "मारने" का क्लासिक तरीका

किसी प्रक्रिया को "मारने" का एक प्रसिद्ध तरीका प्रक्रिया को एक SIGKILL सिग्नल भेजना है। बैश के माध्यम से आप मारने के लिए मानक "kill -SIGKILL PID" या "pkill -9 NAME" को कॉल कर सकते हैं। "किल" कमांड को UNIX के दिनों से जाना जाता है और यह न केवल macOS पर, बल्कि अन्य UNIX-जैसे सिस्टम पर भी उपलब्ध है।

UNIX-जैसी प्रणालियों की तरह, macOS आपको दो - SIGKILL और SIGSTOP को छोड़कर किसी भी प्रक्रिया में किसी भी सिग्नल को रोकने की अनुमति देता है। यह लेख मुख्य रूप से सिगकिल सिग्नल पर एक सिग्नल के रूप में ध्यान केंद्रित करेगा जो एक प्रक्रिया को ख़त्म करने का कारण बनता है।

macOS विशिष्टताएँ

MacOS पर, XNU कर्नेल में किल सिस्टम कॉल psignal(SIGKILL,...) फ़ंक्शन को कॉल करता है। आइए यह देखने का प्रयास करें कि psignal फ़ंक्शन द्वारा यूजरस्पेस में अन्य उपयोगकर्ता क्रियाओं को क्या कहा जा सकता है। आइए कर्नेल के आंतरिक तंत्र में psignal फ़ंक्शन के लिए कॉल को हटा दें (हालाँकि वे गैर-तुच्छ हो सकते हैं, हम उन्हें दूसरे लेख के लिए छोड़ देंगे 🙂 - हस्ताक्षर सत्यापन, मेमोरी त्रुटियाँ, निकास/समाप्ति हैंडलिंग, फ़ाइल सुरक्षा उल्लंघन, आदि) .

आइए फ़ंक्शन और संबंधित सिस्टम कॉल के साथ समीक्षा शुरू करें पेलोड_के साथ समाप्त करें. यह देखा जा सकता है कि क्लासिक किल कॉल के अलावा, एक वैकल्पिक दृष्टिकोण है जो macOS ऑपरेटिंग सिस्टम के लिए विशिष्ट है और BSD में नहीं पाया जाता है। दोनों सिस्टम कॉल के ऑपरेटिंग सिद्धांत भी समान हैं। वे कर्नेल फ़ंक्शन psignal पर सीधे कॉल हैं। यह भी ध्यान दें कि किसी प्रक्रिया को बंद करने से पहले, एक "कैन्सिग्नल" जांच की जाती है - क्या प्रक्रिया किसी अन्य प्रक्रिया को सिग्नल भेज सकती है; उदाहरण के लिए, सिस्टम किसी भी एप्लिकेशन को सिस्टम प्रक्रियाओं को बंद करने की अनुमति नहीं देता है।

static int
terminate_with_payload_internal(struct proc *cur_proc, int target_pid, uint32_t reason_namespace,
				uint64_t reason_code, user_addr_t payload, uint32_t payload_size,
				user_addr_t reason_string, uint64_t reason_flags)
{
...
	target_proc = proc_find(target_pid);
...
	if (!cansignal(cur_proc, cur_cred, target_proc, SIGKILL)) {
		proc_rele(target_proc);
		return EPERM;
	}
...
	if (target_pid == cur_proc->p_pid) {
		/*
		 * psignal_thread_with_reason() will pend a SIGKILL on the specified thread or
		 * return if the thread and/or task are already terminating. Either way, the
		 * current thread won't return to userspace.
		 */
		psignal_thread_with_reason(target_proc, current_thread(), SIGKILL, signal_reason);
	} else {
		psignal_with_reason(target_proc, SIGKILL, signal_reason);
	}
...
}

लॉन्चडी

सिस्टम स्टार्टअप पर डेमॉन बनाने और उनके जीवनकाल को नियंत्रित करने का मानक तरीका लॉन्च किया गया है। कृपया ध्यान दें कि स्रोत MacOS 10.10 तक लॉन्चक्टल के पुराने संस्करण के लिए हैं, उदाहरण के लिए कोड उदाहरण प्रदान किए गए हैं। आधुनिक लॉन्चसीटीएल एक्सपीसी के माध्यम से लॉन्चडी सिग्नल भेजता है, लॉन्चसीटीएल तर्क को इसमें स्थानांतरित कर दिया गया है।

आइए देखें कि वास्तव में एप्लिकेशन कैसे रोके जाते हैं। SIGTERM सिग्नल भेजने से पहले, एप्लिकेशन को "proc_terminet" सिस्टम कॉल का उपयोग करके रोकने का प्रयास किया जाता है।

<launchctl src/core.c>
...
	error = proc_terminate(j->p, &sig);
	if (error) {
		job_log(j, LOG_ERR | LOG_CONSOLE, "Could not terminate job: %d: %s", error, strerror(error));
		job_log(j, LOG_NOTICE | LOG_CONSOLE, "Using fallback option to terminate job...");
		error = kill2(j->p, SIGTERM);
		if (error) {
			job_log(j, LOG_ERR, "Could not signal job: %d: %s", error, strerror(error));
		} 
...
<>

हुड के तहत, proc_terminet, अपने नाम के बावजूद, SIGTERM के साथ न केवल psignal भेज सकता है, बल्कि SIGKILL भी भेज सकता है।

अप्रत्यक्ष हत्या - संसाधन सीमा

एक और सिस्टम कॉल में एक और दिलचस्प मामला देखा जा सकता है प्रक्रिया_नीति. इस सिस्टम कॉल का एक सामान्य उपयोग एप्लिकेशन संसाधनों को सीमित करना है, जैसे कि एक इंडेक्सर के लिए सीपीयू समय और मेमोरी कोटा को सीमित करना ताकि सिस्टम फ़ाइल कैशिंग गतिविधियों से काफी धीमा न हो। यदि कोई एप्लिकेशन अपनी संसाधन सीमा तक पहुंच गया है, जैसा कि proc_apply_resource_actions फ़ंक्शन से देखा जा सकता है, तो प्रक्रिया में एक SIGKILL सिग्नल भेजा जाता है।

हालाँकि यह सिस्टम कॉल संभावित रूप से किसी प्रक्रिया को ख़त्म कर सकता है, लेकिन सिस्टम ने सिस्टम कॉल को कॉल करने वाली प्रक्रिया के अधिकारों की पर्याप्त रूप से जाँच नहीं की है। वास्तव में जाँच कर रहा हूँ वहाँ, लेकिन इस स्थिति को बायपास करने के लिए वैकल्पिक ध्वज PROC_POLICY_ACTION_SET का उपयोग करना पर्याप्त है।

इसलिए, यदि आप एप्लिकेशन के सीपीयू उपयोग कोटा को "सीमित" करते हैं (उदाहरण के लिए, केवल 1 एनएस को चलाने की अनुमति देते हैं), तो आप सिस्टम में किसी भी प्रक्रिया को बंद कर सकते हैं। इस प्रकार, मैलवेयर एंटीवायरस प्रक्रिया सहित सिस्टम पर किसी भी प्रक्रिया को ख़त्म कर सकता है। यह प्रभाव भी दिलचस्प है जो पीआईडी ​​1 (लॉन्चसीटीएल) के साथ एक प्रक्रिया को खत्म करते समय होता है - सिगकिल सिग्नल को संसाधित करने का प्रयास करते समय कर्नेल घबराहट :)

इस समस्या को कैसे सुलझाया जाए?

किसी प्रक्रिया को ख़त्म होने से बचाने का सबसे सीधा तरीका सिस्टम कॉल टेबल में फ़ंक्शन पॉइंटर को बदलना है। दुर्भाग्य से, यह विधि कई कारणों से गैर-तुच्छ है।

सबसे पहले, sysent की मेमोरी लोकेशन को नियंत्रित करने वाला प्रतीक न केवल XNU कर्नेल प्रतीक के लिए निजी है, बल्कि कर्नेल प्रतीकों में भी नहीं पाया जा सकता है। आपको अनुमानी खोज विधियों का उपयोग करना होगा, जैसे कि फ़ंक्शन को गतिशील रूप से अलग करना और उसमें एक पॉइंटर की खोज करना।

दूसरे, तालिका में प्रविष्टियों की संरचना उन झंडों पर निर्भर करती है जिनके साथ कर्नेल संकलित किया गया था। यदि CONFIG_REQUIRES_U32_MUNGING ध्वज घोषित किया जाता है, तो संरचना का आकार बदल दिया जाएगा - एक अतिरिक्त फ़ील्ड जोड़ा जाएगा sy_arg_munge32. यह निर्धारित करने के लिए अतिरिक्त जांच करना आवश्यक है कि कर्नेल को किस ध्वज के साथ संकलित किया गया था, या वैकल्पिक रूप से, ज्ञात के विरुद्ध फ़ंक्शन पॉइंटर्स की जांच करें।

struct sysent {         /* system call table */
        sy_call_t       *sy_call;       /* implementing function */
#if CONFIG_REQUIRES_U32_MUNGING || (__arm__ && (__BIGGEST_ALIGNMENT__ > 4))
        sy_munge_t      *sy_arg_munge32; /* system call arguments munger for 32-bit process */
#endif
        int32_t         sy_return_type; /* system call return types */
        int16_t         sy_narg;        /* number of args */
        uint16_t        sy_arg_bytes;   /* Total size of arguments in bytes for
                                         * 32-bit system calls
                                         */
};

सौभाग्य से, macOS के आधुनिक संस्करणों में, Apple प्रक्रियाओं के साथ काम करने के लिए एक नया API प्रदान करता है। एंडपॉइंट सुरक्षा एपीआई ग्राहकों को अन्य प्रक्रियाओं के लिए कई अनुरोधों को अधिकृत करने की अनुमति देता है। इस प्रकार, आप उपर्युक्त एपीआई का उपयोग करके SIGKILL सिग्नल सहित प्रक्रियाओं के किसी भी सिग्नल को ब्लॉक कर सकते हैं।

#include <bsm/libbsm.h>
#include <EndpointSecurity/EndpointSecurity.h>
#include <unistd.h>

int main(int argc, const char * argv[]) {
    es_client_t* cli = nullptr;
    {
        auto res = es_new_client(&cli, ^(es_client_t * client, const es_message_t * message) {
            switch (message->event_type) {
                case ES_EVENT_TYPE_AUTH_SIGNAL:
                {
                    auto& msg = message->event.signal;
                    auto target = msg.target;
                    auto& token = target->audit_token;
                    auto pid = audit_token_to_pid(token);
                    printf("signal '%d' sent to pid '%d'n", msg.sig, pid);
                    es_respond_auth_result(client, message, pid == getpid() ? ES_AUTH_RESULT_DENY : ES_AUTH_RESULT_ALLOW, false);
                }
                    break;
                default:
                    break;
            }
        });
    }

    {
        es_event_type_t evs[] = { ES_EVENT_TYPE_AUTH_SIGNAL };
        es_subscribe(cli, evs, sizeof(evs) / sizeof(*evs));
    }

    printf("%dn", getpid());
    sleep(60); // could be replaced with other waiting primitive

    es_unsubscribe_all(cli);
    es_delete_client(cli);

    return 0;
}

इसी तरह, एक मैक पॉलिसी को कर्नेल में पंजीकृत किया जा सकता है, जो एक सिग्नल सुरक्षा विधि (पॉलिसी proc_check_signal) प्रदान करती है, लेकिन एपीआई आधिकारिक तौर पर समर्थित नहीं है।

कर्नेल विस्तार सुरक्षा

सिस्टम में प्रक्रियाओं की सुरक्षा के अलावा, कर्नेल एक्सटेंशन (kext) की सुरक्षा भी आवश्यक है। macOS डेवलपर्स को IOKit डिवाइस ड्राइवर आसानी से विकसित करने के लिए एक ढांचा प्रदान करता है। उपकरणों के साथ काम करने के लिए उपकरण प्रदान करने के अलावा, IOKit C++ कक्षाओं के उदाहरणों का उपयोग करके ड्राइवर स्टैकिंग के लिए तरीके प्रदान करता है। यूजरस्पेस में एक एप्लिकेशन कर्नेल-यूजरस्पेस संबंध स्थापित करने के लिए क्लास के एक पंजीकृत उदाहरण को "ढूंढने" में सक्षम होगा।

सिस्टम में क्लास इंस्टेंस की संख्या का पता लगाने के लिए, ioclasscount उपयोगिता है।

my_kext_ioservice = 1
my_kext_iouserclient = 1

कोई भी कर्नेल एक्सटेंशन जो ड्राइवर स्टैक के साथ पंजीकरण करना चाहता है, उसे एक वर्ग घोषित करना होगा जो IOService से विरासत में मिला है, उदाहरण के लिए इस मामले में my_kext_ioservice। उपयोगकर्ता अनुप्रयोगों को कनेक्ट करने से क्लास का एक नया उदाहरण बनता है जो IOUserClient से विरासत में मिलता है, उदाहरण के लिए my_kext_iouserclient।

सिस्टम से ड्राइवर को अनलोड करने का प्रयास करते समय (kextunload कमांड), वर्चुअल फ़ंक्शन "बूल टर्मिनेट (IOOptionBits विकल्प)" कहा जाता है। Kextunload को अक्षम करने के लिए अनलोड करने का प्रयास करते समय समाप्त करने के लिए कॉल पर गलत रिटर्न देना पर्याप्त है।

bool Kext::terminate(IOOptionBits options)
{

  if (!IsUnloadAllowed)
  {
    // Unload is not allowed, returning false
    return false;
  }

  return super::terminate(options);
}

लोड करते समय IsUnloadAllowed ध्वज को IOUserClient द्वारा सेट किया जा सकता है। जब डाउनलोड सीमा होती है, तो kextunload कमांड निम्नलिखित आउटपुट लौटाएगा:

admin@admins-Mac drivermanager % sudo kextunload ./test.kext
Password:
(kernel) Can't remove kext my.kext.test; services failed to terminate - 0xe00002c7.
Failed to unload my.kext.test - (iokit/common) unsupported function.

IOUserClient के लिए भी ऐसी ही सुरक्षा की जानी चाहिए। कक्षाओं के उदाहरणों को IOKitLib उपयोगकर्ता स्थान फ़ंक्शन "IOCatalogueTerminate(mach_port_t, uint32_t फ़्लैग, io_name_t विवरण);" का उपयोग करके अनलोड किया जा सकता है। आप "टर्मिनेट" कमांड को कॉल करते समय गलत रिटर्न दे सकते हैं जब तक कि यूजरस्पेस एप्लिकेशन "मर नहीं जाता", यानी "क्लाइंटडाइड" फ़ंक्शन को कॉल नहीं किया जाता है।

फ़ाइल सुरक्षा

फ़ाइलों की सुरक्षा के लिए, कौथ एपीआई का उपयोग करना पर्याप्त है, जो आपको फ़ाइलों तक पहुंच को प्रतिबंधित करने की अनुमति देता है। Apple डेवलपर्स को दायरे में विभिन्न घटनाओं के बारे में सूचनाएं प्रदान करता है; हमारे लिए, ऑपरेशन KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA और KAUTH_VNODE_DELETE_CHILD महत्वपूर्ण हैं। फ़ाइलों तक पहुंच को प्रतिबंधित करने का सबसे आसान तरीका पथ है - हम फ़ाइल का पथ प्राप्त करने और पथ उपसर्ग की तुलना करने के लिए "vn_getpath" एपीआई का उपयोग करते हैं। ध्यान दें कि फ़ाइल फ़ोल्डर पथों के नाम बदलने को अनुकूलित करने के लिए, सिस्टम प्रत्येक फ़ाइल तक पहुंच को अधिकृत नहीं करता है, बल्कि केवल उस फ़ोल्डर तक पहुंच को अधिकृत करता है जिसका नाम बदला गया है। मूल पथ की तुलना करना और इसके लिए KAUTH_VNODE_DELETE को प्रतिबंधित करना आवश्यक है।

उपसर्गों की संख्या बढ़ने पर इस दृष्टिकोण का नुकसान कम प्रदर्शन हो सकता है। यह सुनिश्चित करने के लिए कि तुलना O(उपसर्ग*लंबाई) के बराबर नहीं है, जहां उपसर्ग उपसर्गों की संख्या है, लंबाई स्ट्रिंग की लंबाई है, आप उपसर्गों द्वारा निर्मित नियतात्मक परिमित ऑटोमेटन (DFA) का उपयोग कर सकते हैं।

आइए उपसर्गों के दिए गए सेट के लिए डीएफए बनाने की एक विधि पर विचार करें। हम प्रत्येक उपसर्ग की शुरुआत में कर्सर को प्रारंभ करते हैं। यदि सभी कर्सर एक ही वर्ण की ओर इंगित करते हैं, तो प्रत्येक कर्सर को एक वर्ण से बढ़ाएँ और याद रखें कि एक ही पंक्ति की लंबाई एक से अधिक हो। यदि अलग-अलग प्रतीकों वाले दो कर्सर हैं, तो कर्सर को उनके द्वारा इंगित प्रतीक के अनुसार समूहों में विभाजित करें और प्रत्येक समूह के लिए एल्गोरिदम दोहराएं।

पहले मामले में (कर्सर के नीचे के सभी अक्षर समान हैं), हमें एक DFA स्थिति मिलती है जिसमें एक ही पंक्ति में केवल एक संक्रमण होता है। दूसरे मामले में, हमें फ़ंक्शन को पुनरावर्ती रूप से कॉल करके प्राप्त बाद के राज्यों में आकार 256 (वर्णों की संख्या और समूहों की अधिकतम संख्या) के संक्रमण की एक तालिका मिलती है।

आइए एक उदाहरण देखें. उपसर्गों के एक सेट के लिए ("/foo/bar/tmp/", "/var/db/foo/", "/foo/bar/aba/", "foo/bar/aac/") आप निम्नलिखित प्राप्त कर सकते हैं डीएफए. यह आंकड़ा केवल अन्य राज्यों की ओर जाने वाले बदलावों को दर्शाता है; अन्य बदलाव अंतिम नहीं होंगे।

डीकेए राज्यों से गुजरने पर, 3 मामले हो सकते हैं।

1. अंतिम स्थिति पर पहुँच गया है - पथ सुरक्षित है, हम संचालन को KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA और KAUTH_VNODE_DELETE_CHILD तक सीमित करते हैं
2. अंतिम स्थिति तक नहीं पहुंचा गया था, लेकिन पथ "समाप्त" हो गया (शून्य टर्मिनेटर पहुंच गया था) - पथ एक मूल है, KAUTH_VNODE_DELETE को सीमित करना आवश्यक है। ध्यान दें कि यदि vnode एक फ़ोल्डर है, तो आपको अंत में '/' जोड़ना होगा, अन्यथा यह इसे फ़ाइल "/foor/bar/t" तक सीमित कर सकता है, जो गलत है।
3. अंतिम स्थिति नहीं पहुंची, रास्ता ख़त्म नहीं हुआ. कोई भी उपसर्ग इससे मेल नहीं खाता, हम प्रतिबंध नहीं लगाते।

निष्कर्ष

विकसित किये जा रहे सुरक्षा समाधानों का लक्ष्य उपयोगकर्ता और उसके डेटा की सुरक्षा के स्तर को बढ़ाना है। एक ओर, यह लक्ष्य Acronis सॉफ़्टवेयर उत्पाद के विकास द्वारा प्राप्त किया गया है, जो उन कमजोरियों को बंद करता है जहां ऑपरेटिंग सिस्टम स्वयं "कमजोर" है। दूसरी ओर, हमें उन सुरक्षा पहलुओं को मजबूत करने की उपेक्षा नहीं करनी चाहिए जिन्हें ओएस पक्ष में सुधार किया जा सकता है, खासकर जब से ऐसी कमजोरियों को बंद करने से उत्पाद के रूप में हमारी अपनी स्थिरता बढ़ती है। भेद्यता की सूचना Apple उत्पाद सुरक्षा टीम को दी गई थी और इसे macOS 10.14.5 (https://support.apple.com/en-gb/HT210119) में ठीक कर दिया गया है।

यह सब केवल तभी किया जा सकता है जब आपकी उपयोगिता आधिकारिक तौर पर कर्नेल में स्थापित की गई हो। यानी बाहरी और अवांछित सॉफ़्टवेयर के लिए ऐसी कोई खामियां नहीं हैं। हालाँकि, जैसा कि आप देख सकते हैं, एंटीवायरस और बैकअप सिस्टम जैसे वैध प्रोग्रामों की सुरक्षा के लिए भी काम की आवश्यकता होती है। लेकिन अब macOS के लिए नए Acronis उत्पादों में सिस्टम से अनलोडिंग के विरुद्ध अतिरिक्त सुरक्षा होगी।

स्रोत: www.habr.com