macOS IPC - Inter Process Communication
Mach-boodskappe via Havens
Basiese Inligting
Mach gebruik take as die kleinste eenheid vir die deel van hulpbronne, en elke taak kan verskeie drade bevat. Hierdie take en drade word 1:1 gekarteer na POSIX-prosesse en drade.
Kommunikasie tussen take vind plaas via Mach Interproses Kommunikasie (IPC), wat eenrigting kommunikasiekanaal benut. Boodskappe word oorgedra tussen hawens, wat soortgelyk aan boodskaprye optree wat deur die kernel bestuur word.
'n Hawe is die basiese element van Mach IPC. Dit kan gebruik word om boodskappe te stuur en te ontvang.
Elke proses het 'n IPC-tabel, waarin dit moontlik is om die mach-hawens van die proses te vind. Die naam van 'n mach-hawe is eintlik 'n nommer (‘n wyser na die kernel-voorwerp).
'n Proses kan ook 'n hawenaam met sekere regte na 'n ander taak stuur en die kernel sal hierdie inskrywing in die IPC-tabel van die ander taak laat verskyn.
Haweregte
Haweregte, wat definieer watter operasies 'n taak kan uitvoer, is sleutel tot hierdie kommunikasie. Die moontlike haweregte is (definisies vanaf hier):
Ontvangsreg, wat die ontvangs van boodskappe wat na die hawe gestuur is, moontlik maak. Mach-hawens is MPSC (meervoudige-vervaardiger, enkelverbruiker) rye, wat beteken dat daar slegs een ontvangsreg vir elke hawe in die hele stelsel kan wees (in teenstelling met pype, waar meervoudige prosesse almal lêerbeskrywers na die lees-einde van een pyp kan hê).
'n Taak met die Ontvangsreg kan boodskappe ontvang en Sendregte skep, wat dit moontlik maak om boodskappe te stuur. Aanvanklik het slegs die eie taak Ontvangsreg oor sy hawe.
As die eienaar van die Ontvangsreg sterf of dit doodmaak, word die sendreg nutteloos (dood naam).
Sendreg, wat dit moontlik maak om boodskappe na die hawe te stuur.
Die Sendreg kan gekloneer word sodat 'n taak wat 'n Sendreg besit, die reg kan kloon en dit aan 'n derde taak kan toeken.
Let daarop dat haweregte ook deur Mac-boodskappe oorgedra kan word.
Send-eenkeer-reg, wat dit moontlik maak om een boodskap na die hawe te stuur en dan te verdwyn.
Hierdie reg kan nie gekloneer word nie, maar dit kan geskuif word.
Hawestelreg, wat 'n hawe stel aandui eerder as 'n enkele hawe. Die ontkoppeling van 'n boodskap van 'n hawe stel ontkoppel 'n boodskap van een van die hawens wat dit bevat. Hawestelle kan gebruik word om gelyktydig na verskeie hawens te luister, soos
select
/poll
/epoll
/kqueue
in Unix.Dood naam, wat nie 'n werklike hawe reg is nie, maar bloot 'n plekhouer. Wanneer 'n hawe vernietig word, verander alle bestaande hawe regte na die hawe in dood name.
Take kan SEND-regte na ander oordra, wat hulle in staat stel om boodskappe terug te stuur. SEND-regte kan ook gekloneer word, sodat 'n taak die reg kan dupliseer en dit aan 'n derde taak kan gee. Dit, saam met 'n bemiddelende proses wat bekend staan as die opstartsdiens, maak effektiewe kommunikasie tussen take moontlik.
Lêerhawens
Lêerhawens maak dit moontlik om lêerbeskrywers in Mac-hawens in te sluit (deur Mach-haweregte te gebruik). Dit is moontlik om 'n fileport
vanaf 'n gegewe FD te skep deur fileport_makeport
te gebruik en 'n FD vanaf 'n lêerhawe te skep deur fileport_makefd
te gebruik.
Die vestiging van 'n kommunikasie
Soos voorheen genoem, is dit moontlik om regte te stuur deur Mach-boodskappe, maar jy kan nie 'n reg stuur sonder om reeds 'n reg te hê om 'n Mach-boodskap te stuur nie. Hoe word die eerste kommunikasie dan gevestig?
Hiervoor is die opstartsdiens (launchd in Mac) betrokke, aangesien almal 'n SEND-reg na die opstartsdiens kan kry, is dit moontlik om dit te vra vir 'n reg om 'n boodskap na 'n ander proses te stuur:
Taak A skep 'n nuwe hawe, kry die ONTVANG reg daaroor.
Taak A, as die houer van die ONTVANG reg, skep 'n SEND reg vir die hawe.
Taak A vestig 'n verbindings met die opstartsdiens, en stuur dit die SEND reg vir die hawe wat dit aan die begin geskep het.
Onthou dat enigeen 'n SEND reg na die opstartsdiens kan kry.
Taak A stuur 'n
bootstrap_register
boodskap na die opstartsdiens om die gegewe hawe met 'n naam sooscom.apple.taska
te assosieer.Taak B interaksie met die opstartsdiens om 'n opstarts soektog vir die diensnaam (
bootstrap_lookup
) uit te voer. Sodat die opstartsdiens kan reageer, sal taak B 'n SEND reg na 'n hawe wat dit voorheen geskep het binne die soektog-boodskap stuur. As die soektog suksesvol is, dupliseer die bediener die SEND reg wat van Taak A ontvang is en stuur dit na Taak B.
Onthou dat enigeen 'n SEND reg na die opstartsdiens kan kry.
Met hierdie SEND reg is Taak B in staat om 'n boodskap na Taak A te stuur.
Vir 'n tweerigting kommunikasie skep taak B gewoonlik 'n nuwe hawe met 'n ONTVANG reg en 'n SEND reg, en gee die SEND reg aan Taak A sodat dit boodskappe aan TAASK B kan stuur (tweerigting kommunikasie).
Die opstartsdiens kan nie die diensnaam autentiseer wat deur 'n taak beweer word nie. Dit beteken 'n taak kan potensieel enige stelseltaak naboots, soos valse goedkeuring van 'n outorisasiediensnaam en dan elke versoek goedkeur.
Dan stoor Apple die name van stelselverskafde dienste in veilige konfigurasie lêers, geleë in SIP-beskermde gids: /System/Library/LaunchDaemons
en /System/Library/LaunchAgents
. Saam met elke diensnaam word ook die geassosieerde binêre lêer gestoor. Die opstartsdiens sal 'n ONTVANG reg vir elkeen van hierdie diensname skep en behou.
Vir hierdie voorgedefinieerde dienste, verskil die soektogproses effens. Wanneer 'n diensnaam opgesoek word, begin launchd die diens dinamies. Die nuwe werkstroom is as volg:
Taak B inisieer 'n opstarts soektog vir 'n diensnaam.
launchd kontroleer of die taak loop en as dit nie is nie, begin dit.
Taak A (die diens) voer 'n opstarts inligting uit (
bootstrap_check_in()
). Hier skep die opstarts diens 'n SEND reg, behou dit, en oorhandig die ONTVANG reg aan Taak A.launchd dupliseer die SEND reg en stuur dit na Taak B.
Taak B skep 'n nuwe hawe met 'n ONTVANG reg en 'n SEND reg, en gee die SEND reg aan Taak A (die diens) sodat dit boodskappe aan TAASK B kan stuur (tweerigting kommunikasie).
Hierdie proses geld egter slegs vir voorgedefinieerde stelseltake. Nie-stelsel take werk steeds soos aanvanklik beskryf, wat potensieel die moontlikheid vir nabootsing kan toelaat.
Daarom behoort launchd nooit te bots nie, anders sal die hele stelsel bots.
'n Mach-boodskap
Die mach_msg
-funksie, essensieel 'n stelseloproep, word gebruik om Mach-boodskappe te stuur en te ontvang. Die funksie vereis dat die boodskap as die aanvanklike argument gestuur word. Hierdie boodskap moet begin met 'n mach_msg_header_t
-struktuur, gevolg deur die werklike boodskapinhoud. Die struktuur word soos volg gedefinieer:
Prosesse wat 'n ontvangsreg besit, kan boodskappe op 'n Mach-poort ontvang. Omgekeerd word aan die senders 'n stuur of 'n eenmalige stuur reg toegeken. Die eenmalige stuur reg is uitsluitlik vir die stuur van 'n enkele boodskap, waarna dit ongeldig word.
Die aanvanklike veld msgh_bits
is 'n bietjiekaart:
Die eerste bit (mees betekenisvolle) word gebruik om aan te dui dat 'n boodskap kompleks is (meer hieroor hieronder)
Die 3de en 4de word deur die kernel gebruik
Die 5 minst betekenisvolle bits van die 2de byte kan gebruik word vir voucher: 'n ander tipe poort om sleutel/waarde kombinasies te stuur.
Die 5 minst betekenisvolle bits van die 3de byte kan gebruik word vir plaaslike poort
Die 5 minst betekenisvolle bits van die 4de byte kan gebruik word vir afgeleë poort
Die tipes wat in die voucher, plaaslike en afgeleë poorte gespesifiseer kan word is (vanaf mach/message.h):
Byvoorbeeld, MACH_MSG_TYPE_MAKE_SEND_ONCE
kan gebruik word om aan te dui dat 'n stuur-eenmaal-reg afgelei en oorgedra moet word vir hierdie poort. Dit kan ook gespesifiseer word as MACH_PORT_NULL
om te voorkom dat die ontvanger kan antwoord.
Om 'n maklike tweerigting kommunikasie te bereik, kan 'n proses 'n mach-poort spesifiseer in die mach boodskap kop genoem die antwoordpoort (msgh_local_port
) waar die ontvanger van die boodskap 'n antwoord kan stuur op hierdie boodskap.
Let daarop dat hierdie soort tweerigting kommunikasie gebruik word in XPC-boodskappe wat 'n antwoord verwag (xpc_connection_send_message_with_reply
en xpc_connection_send_message_with_reply_sync
). Maar gewoonlik word verskillende poorte geskep soos voorheen verduidelik om die tweerigting kommunikasie te skep.
Die ander velde van die boodskap kop is:
msgh_size
: die grootte van die hele pakkie.msgh_remote_port
: die poort waarop hierdie boodskap gestuur word.msgh_voucher_port
: mach vouchers.msgh_id
: die ID van hierdie boodskap, wat deur die ontvanger geïnterpreteer word.
Let daarop dat mach-boodskappe oor 'n mach-poort
gestuur word, wat 'n enkele ontvanger, veelvuldige stuurder kommunikasiekanaal is wat in die mach-kernel ingebou is. Meer as een proses kan boodskappe stuur na 'n mach-poort, maar op enige punt kan slegs 'n enkele proses daarvan lees.
Boodskappe word dan gevorm deur die mach_msg_header_t
kop gevolg deur die liggaam en deur die trailer (indien enige) en dit kan toestemming verleen om daarop te antwoord. In hierdie gevalle hoef die kernel net die boodskap van die een taak na die ander oor te dra.
'n Trailer is inligting wat deur die kernel by die boodskap gevoeg word (kan nie deur die gebruiker ingestel word nie) wat aangevra kan word in die boodskap ontvangs met die vlae MACH_RCV_TRAILER_<trailer_opt>
(daar is verskillende inligting wat aangevra kan word).
Complekse Boodskappe
Daar is egter ander meer komplekse boodskappe, soos dié wat addisionele poortregte deurgee of geheue deel, waar die kernel ook hierdie voorwerpe na die ontvanger moet stuur. In hierdie gevalle is die mees beduidende bit van die kop msgh_bits
ingestel.
Die moontlike beskrywers om deur te gee is gedefinieer in mach/message.h
:
In 32bits, al die beskrywers is 12B en die beskrywerstipe is in die 11de een. In 64 bits, varieer die groottes.
Die kernel sal die beskrywers van die een taak na die ander kopieer, maar eerste 'n kopie in die kernel-geheue skep. Hierdie tegniek, bekend as "Feng Shui", is misbruik in verskeie aanvalle om die kernel data in sy geheue te laat kopieer sodat 'n proses beskrywers na homself kan stuur. Dan kan die proses die boodskappe ontvang (die kernel sal hulle vrymaak).
Dit is ook moontlik om poortregte na 'n kwesbare proses te stuur, en die poortregte sal net in die proses verskyn (selfs al hanteer hy dit nie).
Mac Ports APIs
Let daarop dat poorte aan die taaknaamruimte gekoppel is, sodat om 'n poort te skep of te soek, die taaknaamruimte ook ondersoek word (meer in mach/mach_port.h
):
mach_port_allocate
|mach_port_construct
: Skep 'n poort.mach_port_allocate
kan ook 'n poortstel skep: ontvangsreg oor 'n groep poorte. Wanneer 'n boodskap ontvang word, word die poort aangedui waarvandaan dit afkomstig is.mach_port_allocate_name
: Verander die naam van die poort (standaard 32-bis integer)mach_port_names
: Kry poortname van 'n teikenmach_port_type
: Kry regte van 'n taak oor 'n naammach_port_rename
: Hernoem 'n poort (soos dup2 vir FD's)mach_port_allocate
: Allokeer 'n nuwe ONTVANG, POORT_STEL of DOOD_NAAMmach_port_insert_right
: Skep 'n nuwe reg in 'n poort waar jy ONTVANG hetmach_port_...
mach_msg
|mach_msg_overwrite
: Funksies wat gebruik word om mach-boodskappe te stuur en te ontvang. Die oorskrywingsweergawe maak dit moontlik om 'n ander buffer vir boodskaponvangst te spesifiseer (die ander weergawe sal dit net hergebruik).
Debug mach_msg
Aangesien die funksies mach_msg
en mach_msg_overwrite
diegene is wat gebruik word om boodskappe te stuur en te ontvang, sal dit moontlik wees om 'n breekpunt daarop te stel om die gestuurde en ontvangsboodskappe te ondersoek.
Begin byvoorbeeld met die foutopsporing van enige toepassing wat jy kan foutopspoor aangesien dit libSystem.B
sal laai wat hierdie funksie sal gebruik.
Om die argumente van mach_msg
te kry, ondersoek die registers. Dit is die argumente (van mach/message.h):
Kry die waardes uit die registre:
Ondersoek die boodskap kop deur die eerste argument te kontroleer:
Daardie tipe mach_msg_bits_t
is baie algemeen om 'n antwoord toe te laat.
Enumerate poorte
Die naam is die versteknaam wat aan die poort gegee word (kyk hoe dit in die eerste 3 byte toeneem). Die ipc-object
is die versteekte unieke identifiseerder van die poort.
Let ook op hoe die poorte met slegs send
regte die eienaar daarvan identifiseer (poortnaam + pid).
Let ook op die gebruik van +
om ander take wat aan dieselfde poort gekoppel is aan te dui.
Dit is ook moontlik om procesxp te gebruik om ook die geregistreerde diensname te sien (met SIP wat gedeaktiveer is weens die behoefte aan com.apple.system-task-port
):
Jy kan hierdie instrument in iOS installeer deur dit af te laai vanaf http://newosxbook.com/tools/binpack64-256.tar.gz
Kodevoorbeeld
Merk op hoe die sender 'n poort toewys, 'n send right skep vir die naam org.darlinghq.example
en dit na die bootstrap server stuur terwyl die sender vir die send right van daardie naam gevra het en dit gebruik het om 'n boodskap te stuur.
Afrikaans Translation:
Hierdie program wys hoe om 'n boodskap te stuur na 'n ander proses deur gebruik te maak van Inter-Process Communication (IPC) in macOS. Die sender proses skep 'n boodskap en stuur dit na die ander proses deur die gebruik van 'n IPC meganisme soos mach_msg
.
Bevoorregte Poorte
Daar is sekere spesiale poorte wat toelaat om sekere sensitiewe aksies uit te voer of toegang te verkry tot sekere sensitiewe data in die geval waar 'n taak die SEND-permissies oor hulle het. Dit maak hierdie poorte baie interessant vanuit 'n aanvaller se perspektief nie net vanweë die vermoëns nie, maar omdat dit moontlik is om SEND-permissies oor take te deel.
Gasheer Spesiale Poorte
Hierdie poorte word voorgestel deur 'n nommer.
SEND regte kan verkry word deur host_get_special_port
te roep en RECEIVE regte deur host_set_special_port
te roep. Nietemin, beide oproepe vereis die host_priv
poort wat slegs root kan toegang verkry. Verder was dit in die verlede vir root moontlik om host_set_special_port
te roep en willekeurige poorte te kap wat byvoorbeeld toegelaat het om kodehandtekeninge te omseil deur HOST_KEXTD_PORT
te kap (SIP voorkom dit nou).
Hierdie is verdeel in 2 groepe: Die eerste 7 poorte word besit deur die kernel waarvan die 1 HOST_PORT
, die 2 HOST_PRIV_PORT
, die 3 HOST_IO_MASTER_PORT
en die 7 is HOST_MAX_SPECIAL_KERNEL_PORT
.
Diegene wat begin vanaf nommer 8 word besit deur stelseldaemons en hulle kan gevind word wat verklaar is in host_special_ports.h
.
Gasheerpoort: As 'n proses SEND-bevoegdheid oor hierdie poort het, kan hy inligting oor die sisteem kry deur sy roetines te roep soos:
host_processor_info
: Kry verwerkerinligtinghost_info
: Kry gasheerinligtinghost_virtual_physical_table_info
: Virtuele/Fisiese bladsytabel (vereis MACH_VMDEBUG)host_statistics
: Kry gasheerstatistiekemach_memory_info
: Kry kernelgeheue-indelingGasheer Priv-poort: 'n Proses met SEND-reg oor hierdie poort kan bevoorregte aksies uitvoer soos die vertoon van opstartdata of probeer om 'n kerneluitbreiding te laai. Die proses moet root wees om hierdie toestemming te kry.
Verder, om die
kext_request
API te roep, is dit nodig om ander toestemmings te hêcom.apple.private.kext*
wat slegs aan Apple-binêre lêers gegee word.Ander roetines wat geroep kan word is:
host_get_boot_info
: Krymachine_boot_info()
host_priv_statistics
: Kry bevoorregte statistiekevm_allocate_cpm
: Allokeer Aaneenlopende Fisiese Geheuehost_processors
: Stuur reg na gasheerverwerkersmach_vm_wire
: Maak geheue residensAangesien root toegang tot hierdie toestemming kan verkry, kan dit
host_set_[special/exception]_port[s]
roep om gasheer spesiale of uitsonderingspoorte te kap.
Dit is moontlik om alle gasheer spesiale poorte te sien deur die volgende te hardloop:
Taak Spesiale Poorte
Hierdie is poorte wat gereserveer is vir bekende dienste. Dit is moontlik om hulle te kry/stel deur task_[get/set]_special_port
te roep. Hulle kan gevind word in task_special_ports.h
:
Van hier:
TASK_KERNEL_PORT[taak-self stuur reg]: Die poort wat gebruik word om hierdie taak te beheer. Gebruik om boodskappe te stuur wat die taak beïnvloed. Dit is die poort wat teruggegee word deur mach_task_self (sien Taak Poorte hieronder).
TASK_BOOTSTRAP_PORT[bootstrap stuur reg]: Die taak se bootstrap poort. Gebruik om boodskappe te stuur wat die terugkeer van ander stelseldienspoorte aanvra.
TASK_HOST_NAME_PORT[host-self stuur reg]: Die poort wat gebruik word om inligting van die gasheer te versoek. Dit is die poort wat teruggegee word deur mach_host_self.
TASK_WIRED_LEDGER_PORT[ledger stuur reg]: Die poort wat die bron noem waaruit hierdie taak sy bedrade kernelgeheue trek.
TASK_PAGED_LEDGER_PORT[ledger stuur reg]: Die poort wat die bron noem waaruit hierdie taak sy verstekgeheue bestuurde geheue trek.
Taak Poorte
Oorspronklik het Mach nie "prosesse" gehad nie, dit het "take" gehad wat meer as 'n houer van drade beskou is. Toe Mach saamgevoeg is met BSD was elke taak gekorreleer met 'n BSD-proses. Daarom het elke BSD-proses die besonderhede wat dit nodig het om 'n proses te wees en elke Mach-taak het ook sy innerlike werking (behalwe vir die nie-bestaande pid 0 wat die kernel_task
is).
Daar is twee baie interessante funksies wat hiermee verband hou:
task_for_pid(target_task_port, pid, &task_port_of_pid)
: Kry 'n STUUR reg vir die taakpoort van die taak wat verband hou met die gespesifiseerdepid
en gee dit aan die aangeduidetarget_task_port
(wat gewoonlik die aanroeperstaak is watmach_task_self()
gebruik het, maar kan 'n STUUR poort oor 'n ander taak wees.)pid_for_task(task, &pid)
: Gegewe 'n STUUR reg vir 'n taak, vind uit aan watter PID hierdie taak verband hou.
Om aksies binne die taak uit te voer, het die taak 'n STUUR
reg na homself nodig deur mach_task_self()
te roep (wat die task_self_trap
(28) gebruik). Met hierdie toestemming kan 'n taak verskeie aksies uitvoer soos:
task_threads
: Kry STUUR reg oor alle taakpoorte van die drade van die taaktask_info
: Kry inligting oor 'n taaktask_suspend/resume
: Ophou of hervat 'n taaktask_[get/set]_special_port
thread_create
: Skep 'n draadtask_[get/set]_state
: Beheer taaktoestanden meer kan gevind word in mach/task.h
Let daarop dat met 'n STUUR reg oor 'n taakpoort van 'n verskillende taak, is dit moontlik om sulke aksies oor 'n verskillende taak uit te voer.
Verder is die taak_poort ook die vm_map
poort wat toelaat om geheue te lees en te manipuleer binne 'n taak met funksies soos vm_read()
en vm_write()
. Dit beteken basies dat 'n taak met STUUR regte oor die taak_poort van 'n ander taak in staat sal wees om kode in daardie taak in te spuit.
Onthou dat omdat die kernel ook 'n taak is, as iemand daarin slaag om 'n STUUR toestemmings oor die kernel_task
te kry, sal dit in staat wees om die kernel enige iets te laat uitvoer (jailbreaks).
Roep
mach_task_self()
aan om die naam vir hierdie poort vir die aanroeperstaak te kry. Hierdie poort word slegs geërf oorexec()
; 'n nuwe taak wat geskep is metfork()
kry 'n nuwe taakpoort (as 'n spesiale geval, kry 'n taak ook 'n nuwe taakpoort naexec()
in 'n suid-binêre). Die enigste manier om 'n taak te skep en sy poort te kry, is om die "poortruil dans" uit te voer terwyl 'nfork()
gedoen word.Hierdie is die beperkings om toegang tot die poort te verkry (vanaf
macos_task_policy
van die binêreAppleMobileFileIntegrity
):As die program die
com.apple.security.get-task-allow
toestemming het, kan prosesse van dieselfde gebruiker toegang tot die taakpoort kry (gewoonlik bygevoeg deur Xcode vir foutopsporing). Die notariseringsproses sal dit nie toelaat vir produksie vrystellings nie.Programme met die
com.apple.system-task-ports
toestemming kan die taakpoort vir enige proses kry, behalwe die kernel. In ouer weergawes was dit genoemtask_for_pid-allow
. Dit word slegs aan Apple-toepassings toegeken.Root kan toegang tot taakpoorte van toepassings kry wat nie met 'n verharde hardloopomgewing saamgestel is nie (en nie van Apple nie).
Die taaknaampoort: 'n Onbevoorregte weergawe van die taakpoort. Dit verwys na die taak, maar laat nie toe om dit te beheer nie. Die enigste ding wat beskikbaar lyk deur dit is task_info()
.
Draadpoorte
Drade het ook geassosieerde poorte, wat sigbaar is vanaf die taak wat task_threads
aanroep en vanaf die verwerker met processor_set_threads
. 'n STUUR reg oor die draadpoort maak dit moontlik om die funksie van die thread_act
subsisteem te gebruik, soos:
thread_terminate
thread_[get/set]_state
act_[get/set]_state
thread_[suspend/resume]
thread_info
...
Enige draad kan hierdie poort kry deur na mach_thread_sef
te roep.
Shellcode-inspuiting in draad via Taakpoort
Jy kan 'n shellkode kry van:
Introduction to ARM64v8Voorregte.plist
Hierdie lêer bevat die voorregte wat aan die toepassing toegeken is vir die interproseskommunikasie (IPC). Die voorregte in hierdie lêer bepaal watter aksies die toepassing mag uitvoer binne die konteks van IPC. Dit is belangrik om die inhoud van hierdie lêer te monitor en te verseker dat slegs die nodige voorregte toegeken word om die veiligheid van die stelsel te handhaaf.
Kompileer die vorige program en voeg die bevoegdhede by om kode in te spuit met dieselfde gebruiker (as nie, sal jy sudo moet gebruik).
Last updated