🥇 कसरी macOS मा प्रक्रियाहरू र कर्नेल विस्तारहरू सुरक्षित गर्ने

नमस्ते, Habr! आज म तपाइँ कसरी macOS मा आक्रमणकारीहरु द्वारा आक्रमणहरु बाट प्रक्रियाहरु को रक्षा गर्न को बारे मा कुरा गर्न चाहन्छु। उदाहरण को लागी, यो एक एन्टिभाइरस वा ब्याकअप प्रणाली को लागी उपयोगी छ, विशेष गरी macOS अन्तर्गत त्यहाँ प्रक्रिया "मार" गर्न धेरै तरिकाहरू छन्। यो र काट अन्तर्गत सुरक्षा विधिहरू बारे पढ्नुहोस्।

एक प्रक्रिया "मार" को क्लासिक तरिका

प्रक्रियालाई "मार" गर्ने एउटा प्रख्यात तरिका भनेको प्रक्रियामा SIGKILL सिग्नल पठाउनु हो। bash मार्फत तपाईले मार्नको लागि मानक "kill -SIGKILL PID" वा "pkill -9 NAME" लाई कल गर्न सक्नुहुन्छ। "किल" आदेश UNIX को दिन देखि ज्ञात छ र macOS मा मात्र होइन, तर अन्य UNIX-जस्तो प्रणालीहरूमा पनि उपलब्ध छ।

UNIX-जस्तै प्रणालीहरूमा जस्तै, macOS ले तपाईंलाई दुई बाहेक कुनै पनि प्रक्रियामा संकेतहरू रोक्न अनुमति दिन्छ - SIGKILL र SIGSTOP। यो लेख मुख्यतया SIGKILL संकेत मा एक संकेत को रूप मा फोकस हुनेछ कि एक प्रक्रिया मार्न को कारण हो।

macOS विशिष्टताहरू

macOS मा, XNU कर्नेलमा किल सिस्टम कलले psignal(SIGKILL,...) प्रकार्यलाई कल गर्छ। युजरस्पेसमा अन्य प्रयोगकर्ताका कार्यहरूलाई psignal प्रकार्यद्वारा बोलाउन सकिन्छ भनेर हेर्ने प्रयास गरौं। कर्नेलको आन्तरिक मेकानिजमहरूमा psignal प्रकार्यमा कलहरू बाहिर निकालौं (यद्यपि तिनीहरू गैर-तुच्छ हुन सक्छन्, हामी तिनीहरूलाई अर्को लेखको लागि छोड्नेछौं 🙂 - हस्ताक्षर प्रमाणिकरण, मेमोरी त्रुटिहरू, बाहिर निस्कने/टर्मिनेट ह्यान्डलिंग, फाइल सुरक्षा उल्लङ्घनहरू, आदि। ।

प्रकार्य र सम्बन्धित प्रणाली कलको साथ समीक्षा सुरु गरौं terminate_with_payload। यो देख्न सकिन्छ कि क्लासिक किल कलको अतिरिक्त, त्यहाँ एक वैकल्पिक दृष्टिकोण छ जुन 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 सम्म launchctl को पुरानो संस्करणको लागि हो, कोड उदाहरणहरू चित्रण उद्देश्यका लागि प्रदान गरिएको छ। आधुनिक launchctl ले XPC मार्फत प्रक्षेपण संकेतहरू पठाउँछ, launchctl तर्क यसमा सारिएको छ।

आउनुहोस् हेरौं कसरी अनुप्रयोगहरू रोकिन्छन्। SIGTERM सिग्नल पठाउनु अघि, अनुप्रयोगलाई "proc_terminate" प्रणाली कल प्रयोग गरेर रोक्ने प्रयास गरिन्छ।

<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_terminate, यसको नाम भए पनि, SIGTERM सँग psignal मात्र पठाउन सक्दैन, तर SIGKILL पनि।

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

थप रोचक मामला अर्को प्रणाली कलमा देख्न सकिन्छ प्रक्रिया_नीति। यस प्रणाली कलको एक सामान्य प्रयोग भनेको अनुप्रयोग स्रोतहरू सीमित गर्नु हो, जस्तै अनुक्रमणिकाको लागि CPU समय र मेमोरी कोटाहरू सीमित गर्न ताकि फाइल क्यासिंग गतिविधिहरूद्वारा प्रणाली महत्त्वपूर्ण रूपमा ढिलो नहोस्। यदि एप्लिकेसन यसको स्रोत सीमामा पुगेको छ, जस्तै proc_apply_resource_actions प्रकार्यबाट देख्न सकिन्छ, प्रक्रियामा SIGKILL संकेत पठाइन्छ।

यद्यपि यो प्रणाली कलले सम्भावित रूपमा प्रक्रियालाई नष्ट गर्न सक्छ, प्रणालीले प्रणाली कल कल गर्ने प्रक्रियाको अधिकारहरू पर्याप्त रूपमा जाँच गरेन। वास्तवमा जाँच गर्दै अवस्थित थियो, तर यो अवस्था बाइपास गर्न वैकल्पिक झण्डा PROC_POLICY_ACTION_SET प्रयोग गर्न पर्याप्त छ।

तसर्थ, यदि तपाइँ अनुप्रयोगको CPU उपयोग कोटा "सीमित" गर्नुहुन्छ (उदाहरणका लागि, केवल 1 एनएस चलाउन अनुमति दिँदै), त्यसपछि तपाइँ प्रणालीमा कुनै पनि प्रक्रियालाई मार्न सक्नुहुन्छ। यसरी, मालवेयरले एन्टिभाइरस प्रक्रिया सहित प्रणालीमा कुनै पनि प्रक्रियालाई मार्न सक्छ। Pid 1 (launchctl) - SIGKILL संकेत प्रशोधन गर्ने प्रयास गर्दा कर्नेल प्यानिक :) को साथ प्रक्रियालाई मार्दा हुने प्रभाव पनि रोचक छ।

समस्या कसरी समाधान गर्ने?

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

पहिलो, 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 प्रदान गर्दछ। Endpoint Security API ले ग्राहकहरूलाई अन्य प्रक्रियाहरूमा धेरै अनुरोधहरू अधिकृत गर्न अनुमति दिन्छ। यसरी, तपाईंले माथि उल्लिखित 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;
}

त्यस्तै गरी, MAC नीति कर्नेलमा दर्ता गर्न सकिन्छ, जसले संकेत सुरक्षा विधि (polic_check_signal) प्रदान गर्दछ, तर API आधिकारिक रूपमा समर्थित छैन।

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

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

प्रणालीमा वर्ग उदाहरणहरूको संख्या पत्ता लगाउन, त्यहाँ ioclasscount उपयोगिता छ।

my_kext_ioservice = 1
my_kext_iouserclient = 1

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

प्रणालीबाट ड्राइभर अनलोड गर्ने प्रयास गर्दा (kextunload आदेश), भर्चुअल प्रकार्य "बूल टर्मिनेट(IOOptionBits विकल्पहरू)" भनिन्छ। केक्सटुनलोड असक्षम गर्न अनलोड गर्ने प्रयास गर्दा समाप्त गर्न कलमा गलत फर्काउन पर्याप्त छ।

bool Kext::terminate(IOOptionBits options)
{

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

  return super::terminate(options);
}

IsUnloadAllowed झण्डा IOUserClient द्वारा लोड गर्दा सेट गर्न सकिन्छ। जब त्यहाँ डाउनलोड सीमा हुन्छ, केक्सटनलोड आदेशले निम्न आउटपुट फिर्ता गर्नेछ:

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 विवरण);" प्रयोग गरेर कक्षाहरूको उदाहरणहरू अनलोड गर्न सकिन्छ। तपाईले "टर्मिनेट" कमाण्डलाई कल गर्दा गलत फर्काउन सक्नुहुन्छ जबसम्म प्रयोगकर्ता स्पेस अनुप्रयोग "मर्दैन", अर्थात्, "clientDied" प्रकार्यलाई बोलाइएको छैन।

फाइल सुरक्षा

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

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

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

पहिलो अवस्थामा (कर्सरहरू अन्तर्गत सबै क्यारेक्टरहरू समान छन्), हामीले DFA राज्य प्राप्त गर्छौं जसमा एउटै रेखामा एउटा मात्र संक्रमण हुन्छ। दोस्रो केसमा, हामीले 256 साइजको ट्रान्जिसनको तालिका पाउँछौं (अक्षरहरूको संख्या र समूहहरूको अधिकतम संख्या) पछिका राज्यहरूमा पुनरावर्ती रूपमा प्रकार्य कल गरेर प्राप्त हुन्छ।

एउटा उदाहरण हेरौं। उपसर्गहरूको सेटको लागि (“/foo/bar/tmp/”, “/var/db/foo/”, “/foo/bar/aba/”, “foo/bar/aac/”) तपाईंले निम्न प्राप्त गर्न सक्नुहुन्छ DFA। फिगरले अन्य राज्यहरूमा जाने सङ्क्रमणहरू मात्र देखाउँछ; अन्य सङ्क्रमणहरू अन्तिम हुने छैनन्।

DKA राज्यहरू मार्फत जाँदा, त्यहाँ 3 केसहरू हुन सक्छन्।

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

निष्कर्षमा

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

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

स्रोत: www.habr.com

MacOS मा प्रक्रियाहरू र कर्नेल विस्तारहरू कसरी सुरक्षित गर्ने