🥇Hur man skyddar processer och kärntillägg i macOS

Hej, Habr! Idag skulle jag vilja prata om hur man kan skydda processer från intrång av illasinnade användare i macOS. Detta är särskilt användbart för antivirusprogram eller backup-system, särskilt med tanke på att det finns flera sätt att "döda" en process under macOS. Läs mer om detta och metoderna för skydd nedan.

Klassiskt sätt att "döda" en process

Ett välkänt sätt att "döda" en process är att skicka en SIGKILL-signal till processen. Via bash kan man använda de standardmässiga kommandona "kill -SIGKILL PID" eller "pkill -9 NAME" för att döda. Kommandot "kill" har funnits sedan UNIX-tiden och är tillgängligt inte bara i macOS utan även i andra UNIX-liknande system.

Precis som i UNIX-liknande system tillåter macOS att fånga upp alla signaler till en process förutom två - SIGKILL och SIGSTOP. Denna artikel kommer fokusera på signalen SIGKILL, vilken är den signal som orsakar att processen dödas.

Specifika egenskaper för macOS

I macOS anropar systemanropet kill i XNU-kärnan funktionen psignal(SIGKILL,…). Låt oss undersöka vilka andra användarhandlingar i userspace som kan anropa funktionen psignal. Vi kommer att utesluta anrop av funktionen psignal i kärnans interna mekanismer (även om de kan vara intressanta, sparar vi dem till en annan artikel 🙂 — signaturkontroll, minnesfel, exit/terminate-hantering, filskyddsöverträdelser osv.).

Vi börjar översikten med funktionen och det motsvarande systemanropet terminate_with_payload. Det är tydligt att förutom det klassiska kill-anropet finns det ett alternativt tillvägagångssätt som är specifikt för operativsystemet macOS och som inte förekommer i BSD. Principerna för hur båda systemanropen fungerar är också liknande. De utgör direkta anrop av kärnfunktionen psignal. Låt oss också notera att innan en process dödas görs en kontroll av “cansignal” – om processen kan skicka en signal till en annan process, tillåter systemet inte att någon applikation dödar systemprocesser till exempel.

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) {
			d/*
		 * psignal_thread_with_reason() kommer att lägga en SIGKILL i kö för den specificerade tråden eller
		 * återvända om tråden och/eller uppgiften redan håller på att avslutas. På ett eller annat sätt,
		 * kommer den aktuella tråden inte att återvända till användarutrymmet.
		 * /
		psignal_thread_with_reason(target_proc, current_thread(), SIGKILL, signal_reason);
	} else {
		psignal_with_reason(target_proc, SIGKILL, signal_reason);
	}
...
}

launchd

Det standardiserade sättet att skapa daemoner vid systemstart och styra deras livstid är launchd. Jag påpekar att källkoden som ges är för en gammal version av launchctl före macOS 10.10, kodexemplen ges enbart som illustration. Den moderna launchctl skickar signaler till launchd via XPC, logiken för launchctl har flyttats dit.

Låt oss titta på hur stopp av applikationer verkligen utförs. Innan en SIGTERM-signal skickas försöker systemanropet “proc_terminate” att stoppa applikationen.

<launchctl src/core.c>
...
	error = proc_terminate(j->p, &sig);
	if (error) {
		job_log(j, LOG_ERR | LOG_CONSOLE, "Kunde inte avsluta uppdrag: %d: %s", error, strerror(error));
		job_log(j, LOG_NOTICE | LOG_CONSOLE, "Använder fallback-alternativ för att avsluta uppdrag...");
		error = kill2(j->p, SIGTERM);
		if (error) {
			job_log(j, LOG_ERR, "Kunde inte signalera uppdrag: %d: %s", error, strerror(error));
		} 
...
<>

Under huven kan proc_terminate, trots sitt namn, skicka inte bara psignal med SIGTERM, utan också SIGKILL.

Indirekt dödande — resursbegränsning

Ett mer intressant fall kan ses i ett annat systemanrop process_policy. Det standardiserade användandet av detta systemanrop är resursbegränsningar för applikationer, exempelvis för indexerare begränsning av kvoten för processortid och minne, så att systemet inte avsevärt fördröjs av filens cachenoteringar. Om applikationen når resursbegränsningen, som man kan se från funktionen proc_apply_resource_actions, så skickas en SIGKILL-signal till processen.

Trots att detta systemanrop potentiellt kan utföra dödande av processen, har systemet inte korrekt kontrollerat rättigheterna för den process som kallar systemanropet. Faktum är att kontrollen existerade, men det är tillräckligt att använda det alternativa flaggan PROC_POLICY_ACTION_SET för att kringgå detta villkor.

Om man "begränsar" CPU-användningen av en applikation (till exempel genom att tillåta att endast 1 ns körs), kan man döda vilket process som helst i systemet. En skadlig programvara kan döda vilken process som helst, inklusive antivirusprocessen. Det är också intressant att notera effekten av att döda processen med pid 1 (launchctl) — kernel panic uppstår när man försöker hantera signalen SIGKILL 🙂

Hur löser man problemet?

Det mest uppenbara sättet att förhindra dödandet av en process är att ersätta pekaren till funktionen i systemanropstabellen. Tyvärr är detta tillvägagångssätt inte trivialt av många anledningar.

För det första är symbolen som ansvarar för sysent-positionen i minnet inte bara en privat symbol i XNU-kärnan, utan kan också inte hittas bland kärnsymbolerna. Man måste använda heuristiska sökmetoder, till exempel dynamisk disassemblage av funktionen och leta efter pekaren där.

För det andra beror strukturen för poster i tabellen på flaggorna med vilka kärnan har byggts. Om flaggan CONFIG_REQUIRES_U32_MUNGING har deklarerats, kommer storleken på strukturen att ändras — ett extra fält läggs till. sy_arg_munge32. Det är nödvändigt att utföra en ytterligare kontroll av vilket flagga kärnan har kompilerats med, som ett alternativ kan man jämföra pekarna till funktionerna med kända.

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
                                         */
};

Lyckligtvis erbjuder Apple i moderna versioner av macOS ett nytt API för arbete med processer. Endpoint Security API tillåter klienter att godkänna många förfrågningar till andra processer. På så sätt kan man blockera alla signaler till processer, inklusive signalen SIGKILL genom det ovan nämnda API:t.

#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;
}

På liknande sätt kan man i kärnan registrera en MAC Policy, som tillhandahåller en metod för skydd mot signaler (policy proc_check_signal), men API:t stöds inte officiellt.

Skydd av kärntillägg

Förutom att skydda processerna i systemet är skyddet av själva kärnexpansionen (kext) också nödvändigt. macOS erbjuder ett ramverk för utvecklare för att enkelt kunna utveckla enhetsdrivrutiner med IOKit. Förutom att tillhandahålla verktyg för att arbeta med enheter möjliggör IOKit metoder för att stapla drivrutiner (driver stacking) med hjälp av instanser av C++-klasser. Applikationen i userspace kan "hitta" en registrerad klassinstans för att etablera en koppling mellan kernel och userspace.

För att upptäcka antalet klassinstanser i systemet finns det ett verktyg som heter ioclasscount.

my_kext_ioservice = 1
my_kext_iouserclient = 1

Varje kärnexpansion som vill registrera sig i drivrutinsstapeln måste deklarera en klass som ärver från IOService, som i exemplet my_kext_ioservice. Anslutningen av användarapplikationer medför skapandet av en ny klassinstans som ärver från IOUserClient, i exemplet my_kext_iouserclient.

Vid försök att avlasta drivrutinen från systemet (kommandot kextunload) anropas den virtuella funktionen "bool terminate(IOOptionBits options)". Det räcker med att returnera false vid anropet av terminate-funktionen för att förhindra kextunload.

bool Kext::terminate(IOOptionBits options)
{

  if (!IsUnloadAllowed)
  {
    \/\/ Avlastning är inte tillåten, returnerar false
    return false;
  }

  return super::terminate(options);
}

Flaggan IsUnloadAllowed kan ställas in av IOUserClient vid laddning. Vid begränsningar för avlastning kommer kommandot kextunload att returnera följande utdata:

admin@admins-Mac drivermanager % sudo kextunload .\/test.kext
Lösenord:
(kernel) Kan inte ta bort kext my.kext.test; tjänster kunde inte avslutas - 0xe00002c7.
Misslyckades med att avlasta my.kext.test - (iokit\/common) otillåten funktion.

En liknande skyddsåtgärd krävs också för IOUserClient. Klassinstanser kan avlastas med användarutrymmesfunktionen IOKitLib "IOCatalogueTerminate(mach_port_t, uint32_t flag, io_name_t description);". Det går att returnera false vid anropet av kommandot "terminate" så länge användarutrymmesapplikationen inte "dör", dvs. tills funktionen "clientDied" anropas.

Skydd av filer

För att skydda filer räcker det att använda Kauth API, vilket möjliggör begränsad åtkomst till filer. Apple erbjuder utvecklare notifikationer om olika händelser i scopet, för oss är viktiga operationer KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA och KAUTH_VNODE_DELETE_CHILD. Att begränsa åtkomst till filer är enklast att göra efter sökväg — vi använder API:et "vn_getpath" för att hämta sökvägen till filen och gör en jämförelse av prefixet. Observera att för att optimera omdöpning av sökvägar till mappar med filer, auktoriserar systemet inte åtkomst till varje fil, utan endast till den mapp som döpts om. Det är nödvändigt att jämföra den överordnade sökvägen och begränsa KAUTH_VNODE_DELETE för den.

En nackdel med detta tillvägagångssätt kan vara låg prestanda när antalet prefix ökar. För att undvika att jämförelsen blir O(prefix*length), där prefix är antal prefix och length är strängens längd, kan vi använda en deterministisk ändlig automat (DEA) byggd på prefix.

Låt oss överväga metoden för att bygga DEA för denna uppsättning av prefix. Initiera pekarna i början av varje prefix. Om alla pekare pekar på samma symbol, öka varje pekare med en symbol och kom ihåg att längden på den gemensamma strängen ökar med en. Om det finns två pekare med olika symboler, dela pekarna i grupper efter symbolen de pekar på och upprepa algoritmen för varje grupp.

I det första fallet (när alla symboler under pekarna är desamma) får vi ett DEA-tillstånd som har en enda övergång för den gemensamma strängen. I det andra fallet får vi en övergångstabell av storlek 256 (antal symboler och maximalt antal grupper) för de följande tillstånden, erhållna genom rekursivt anrop av funktionen.

Låt oss överväga ett exempel. För uppsättningen av prefix (“/foo/bar/tmp/”, “/var/db/foo/”, “/foo/bar/aba/”, “foo/bar/aac/”) kan vi få följande DEA. I bilden visas endast övergångarna som leder till andra tillstånd, andra övergångar kommer inte att vara slutgiltiga.

När vi passerar genom DEA-tillstånden kan tre fall uppstå.

Det slutliga tillståndet har uppnåtts — vägen är skyddad, vi begränsar operationerna KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA och KAUTH_VNODE_DELETE_CHILD.
Det slutgiltiga tillståndet nåddes inte, men vägen "slutade" (nollterminator nåddes) — vägen är överordnad, KAUTH_VNODE_DELETE måste begränsas. Observera att om vnode är en mapp måste "\/" läggas till i slutet, annars kan det begränsas till filen "\/foor\/bar\/t", vilket är felaktigt.
Det slutgiltiga tillståndet nåddes inte, vägen slutade inte. Inga av prefixen matchar detta, vi inför inga begränsningar.

Slutsats

Syftet med de utvecklade säkerhetslösningarna är att höja nivån på användarsäkerhet och deras data. Å ena sidan uppnås detta syfte genom att utveckla programvaran Acronis, som täcker de sårbarheter där operativsystemet själv är "svagt". Å andra sidan bör man inte förbise de säkerhetsaspekter som kan förbättras på OS-sidan, särskilt eftersom stängning av sådana sårbarheter ökar vår egen motståndskraft som produkt. Sårbarheten rapporterades av Apple Product Security Team och åtgärdades i macOS 10.14.5 (https://support.apple.com/en-gb/HT210119).

Allt detta kan endast göras om din verktyg var officiellt installerad i kärnan. Det vill säga för extern och oönskad mjukvara finns inga sådana bakdörrar. Men som du ser, även för skydd av legitima program som antivirus och backup-system, krävs det åtgärder. Men nu kommer nya produkter från Acronis för macOS att ha extra skydd mot avlastning från systemet.

Källa: habr.com