- Apple işletim sistemlerinin XNU çekirdeği temelde tek bir güven alanı sunuyordu
- Son dönemde, çekirdek mimarisinin ayrıştırılması ve mikrokernelleşme yoluyla güvenlik açıklarının etkisini azaltmaya yönelik değişiklikler yapılıyor
- 2023’te kullanıma sunulan Secure Page Table Monitor (SPTM), çekirdek işlevlerinin ayrılmasını ve yeni bir güven alanı yapısının oluşmasını sağladı
- Exclaves ve Trusted Execution Monitor (TXM) gibi güncel güvenlik mekanizmaları SPTM temeli üzerinde hayata geçiriliyor
- Bu tür yapısal iyileştirmeler, çekirdek ihlali yaşansa bile tüm sistem güveninin anında çökmesine yol açmıyor
Genel Bakış
Apple işletim sistemlerinin kalbi olan XNU çekirdeği, hibrit çekirdek olarak anılsa da pratikte tüm sistem işlevlerinin tek bir ayrıcalıklı güven bölgesinde toplandığı bir tür monolitik yapı olarak çalışıyordu. Bu nedenle çekirdek ihlali durumunda tüm sistemin anında ciddi tehdit altına girmesi gibi bir sorun vardı. Son dönemde Apple, çekirdeği daha fazla bölümlere ayırıp mikrokernel benzeri bir tasarıma yaklaştıracak iyileştirmeler yapıyor; örneğin sayfa tablosu manipülasyonu veya kriptografiyle ilgili kritik işlevleri çekirdek alanının dışına taşıyor.
Başlıca değişim motivasyonu ve araştırma yönü
- Güvenliği güçlendirmek için çekirdek yapısının iyileştirilmesi ihtiyacı öne çıkıyor
- Çekirdek açıklarının istismarı durumunda tüm sisteme verilen zararı en aza indirmek hedefleniyor
- SPTM gibi yeni mekanizmaların gerçekte nasıl tasarlanıp çalıştığını bilimsel olarak inceleyen önceki çalışmalar yetersiz
- Bu makale, kamuya açıklanmamış bu yeni özellikleri sistematik biçimde inceleyerek mevcut tüm güvenlik mekanizmalarının etkileşimini ve etkisini düzenliyor
SPTM (Secure Page Table Monitor) temel mekanizması
- SPTM, Guarded Level 2 (en üst ayrıcalık seviyesi) üzerinde Guarded Execution Feature (GXF) ile birlikte çalışan, sistemdeki en yüksek yetkili bileşendir
- GXF, mevcut AArch64 istisna seviyesi yapısına yatay koruma seviyeleri ekleyerek sistemin hassas faaliyetlerini XNU’nun doğrudan erişiminden izole eder
- SPTM, frame retyping ve bellek eşleme kuralları temelinde bir güven alanı (domain of trust) sağlayarak her işlev için ayrı alanlar oluşturur
- Bu güven alanının öne çıkan örnekleri arasında TXM (kod imzalama ve yetki doğrulama) ile Exclaves (yeni nesil alan ayrımı güvenlik özelliği) yer alır
Exclaves ve iletişim mekanizması
- Exclaves, bağımsız bir güven bölgesinde çalışan bir yürütme ortamıdır ve SPTM tabanlı bellek koruma ile denetim yapısına dayanır
- Exclaves ile sistem arasındaki iletişim, xnuproxy (güvenli istek işleyicisi) ve Tightbeam IPC çatısı gibi çeşitli yöntemlerle gerçekleştirilir
- Tightbeam; endpoint oluşturma, mesaj tamponları ve istemci-sunucu bağlantıları gibi karmaşık bir IPC yapısına sahiptir
- Exclaves’in gerçek kullanım örnekleri arasında gizlilik göstergelerinin (kayıt, ses kullanımı vb. göstergeler) kontrolü de incelenir
Güvenlik güçlendirmesi ve gelecek görünümü
- Kritik sistem işlevleri XNU’nun doğrudan erişiminden ayrıldıkça, çekirdek ihlal edilse bile tüm sistemin güven düzeyini koruyan ek önlemler sağlanıyor
- SPTM, Exclaves ve TXM arasındaki etkileşimin ayrıntılı analizi, önceye göre çok daha güçlü katmanlı bir koruma yapısının oluştuğunu gösteriyor
- Makalenin sonucunda SPTM sonrası durum, gelecekteki güvenlik iyileştirme olasılıkları, kalan sınırlamalar ve sonraki araştırma yönleri kısaca sunuluyor
Yapı ve derin içerik rehberi
1. Bölüm: Motivasyon–Hedef–Yapı
- Apple’ın çekirdek ayrıştırma hamlelerinin tarihsel bağlamı ve bu araştırmanın gerekliliği
- Çalışmanın katkılarının vurgulanması
2. Bölüm: Arka plan ve temeller
- AArch64 mimarisi üzerindeki istisna seviyeleri, bellek erişim modeli ve Apple yongalarına özgü koruma teknikleri (Fast Permission Restrictions, Page Protection Layer, Guarded Execution Feature, Shadow Permission Remap Register) tanıtılıyor
- Önceki güvenlik araştırmaları ve sınırları özetleniyor
3. Bölüm: Analiz ortamı
- Hedef donanım, firmware, araçlar, semboller ve Apple’a özgü register’lar açıklanıyor
4. Bölüm: Genel mimari tasarım özeti
- EL (istisna seviyesi) ve GL’yi (yatay koruma seviyesi) kapsayan tüm sistem yapısı görselleştiriliyor
5. Bölüm: SPTM’nin derin yapısı
- SPTM’nin temel bileşenleri, başlatılması, çağrı yöntemi (çekirdek, TXM, Secure Kernel) ile header/dispatch table ayrıntılı biçimde anlatılıyor
- SPTM içindeki olay işleme, GENTER ve SVC/HVC (hypervisor call) işleme akışı ele alınıyor
- Frame retyping mantığı; çağrı ve doğrulama, tip/alan bazlı geçerlilik kontrolleri, SPRR (Permission Remapping) güncellemesi ve çağrının tamamlanması gibi adımlarla açıklanıyor
- Sayfa eşleme süreci ve güvenlik düzenekleri inceleniyor
6. Bölüm: Secure Kernel’in rolü
- Secure Kernel ve SPTM çağrıları ile SVC işleme gibi güvenli işletim temelleri ele alınıyor
7. Bölüm: Exclaves sistemi
- Exclaves, Exclavecore ve ExclaveKit gibi temel bileşenler
- Exclave bellek ve kaynak yönetimi, alan bazlı gruplama, conclave (alt bölge) durum makinesi ve kullanıcı alanı etkileşimi
- Endpoint oluşturma ve zamanlama, Mach portları, seL4 tarzı IPC, xnuproxy, Tightbeam gibi iletişim yöntemleri ile gerçek kullanım örnekleri (ör. gizlilik göstergesi)
8. Bölüm: TXM (Trusted Execution Monitor)
- TXM’nin SPTM ile entegrasyon şekli, dispatch, retyping ve korumalı alan işletim yapısı
- TXM’nin güvenlik sorumlulukları ve çağrı işleme yaklaşımı
9~10. Bölüm: Genel tartışma ve sonuç
- SPTM ve Exclaves’in devreye girmesiyle ortaya çıkan güvenlik sonuçları, mevcut sınırlamalar ve geleceğe dönük yönelimler
- Araştırmanın kapanışı ile kaynaklar ve terim açıklamaları içeren ekler sunuluyor
Temel terimler açıklaması
- XNU: Apple işletim sistemlerinin çekirdek bileşeni; “X is Not Unix” ifadesinin kısaltması
- SPTM: Bellek koruması ve ayrıştırma yoluyla güven alanları sağlayan temel modül
- TXM: Kod imzası doğrulama gibi hassas görevlerden sorumlu güvenlik denetleyicisi
- Exclaves: Ayrı fiziksel ve mantıksal alanlarda izole biçimde çalışan güvenli yürütme ortamları
- Tightbeam IPC: Exclaves ile sistem arasında güvenli iletişim sağlayan çatı
- GXF/GL: AArch64 tabanlı koruma istisna seviyelerine eklenen, Guarded Level temelli yatay güven alanı denetim işlevi
Sonuç
Modern iOS’un güvenlik yapısı, SPTM, TXM ve Exclaves ekseninde güvenin ayrıştırılması ve görevlerin bölüştürülmesi yönünde evriliyor. Bu katmanlı koruma modeli, çekirdek alt katmanlarındaki ihlal riskini belirgin biçimde azaltıyor ve gelecekteki güvenlik tehditlerine karşı daha sağlam bir teknik temel sunuyor.
1 yorum
Hacker News yorumu
SEAR ve Apple ekibinin iOS güvenliği konusunda gerçekten harika bir iş çıkardığını düşünüyorum; bu açıdan büyük övgüyü hak ediyorlar
Donanım seviyesinden başlayıp tüm yığına güvenlik özellikleri yerleştirme çabaları etkileyici, ayrıca gerçek dünyadaki saldırı exploit'lerini inceleyip bunları engellemenin yollarını da sürekli araştırıyorlar
Örneğin PPL gibi özellikleri devreye aldılar ama kusursuz olmadığı sonucuna vardıklarında cesurca bırakıp yeni tekniklere yöneliyorlar
Apple dikey entegre bir yapıya sahip olduğu için bunları yapmak Android'e kıyasla çok daha kolay. Android tarafında donanım üreticileriyle (QC, Mediatek) iş birliği yapmak, ardından linux kernel, AOSP, LLVM upstream gibi birçok aşamadan geçmek gerekiyor
Pointer Authentication Codes(PAC) da iyi bir örnek. Apple, “biz yapalım” yaklaşımıyla kendi LLVM branch'ini koruyarak bunu devreye aldı ve gerçekten de gerçek dünyadaki saldırılara dayanan saldırı tekniklerini hafifletip sorunu çözdü
Apple ürünlerini satın alma nedenim yalnızca güvenlik ve gizliliklerinin güçlü olması değil; Apple'ın bu özellikleri para kazanmak için mutlaka yapmak zorunda olmamasına rağmen tutkuyla ve içtenlikle ilerletmesi
Gerçekte bu, pazarlama tanıtımının ötesine geçiyor; jailbreaking topluluğundaki en iyi hacker'ları güvenlik ekibine alıyor, Private Relay, private mail, trusted compute, multi-party inference gibi yenilikler getiriyor
Elbette Apple'ın ikiyüzlü tutumunun sorunlu yönleri de açık. Örneğin VPN'e izin vermesi (Apple sunucularına giden trafik hariç), gizlilik varsayılanları (Wi‑Fi calling veya “journaling suggestions” hariç) gibi konular hayal kırıklığı yaratıyor
Fiilen Apple ve bazı telekom ortaklarına karşı güvende olmama şartı eklenmiş olsa da, yine de Google tarafı “Google veya Google reklam satın alanlar dışındaki herkese karşı güvenli” gibi hissettiriyor; bu yüzden Apple'ın çok daha ileride olduğunu düşünüyorum
Muazzam mühendislik çabasına rağmen, iMessage içinde şüpheli kodun hâlâ kernel'de çalışabildiği yollar var ve bu yüzden 0-click exploit'ler varlığını sürdürüyor
Bu çabaların getirdiği bir diğer avantaj da şu: Apple, güvenliği güçlendirilmiş yeni bir işlemcide bir kod yolu yalnızca bir kez çalıştırılsa bile tüm platformların güvenliği doğal olarak yükseliyor
Teorik olarak yalnızca statik analizle yakalanması zor sorunlar daha kolay tespit edilebiliyor ve basit crash'lerin ötesinde daha derin içgörüler elde edilebiliyor
Google da aslında birkaç yıl önce MTE ekleyebilirdi, ancak bunu Android sertifikasyonunun bir parçası olarak OEM'lere zorunlu kılmak istemedi
Tıpkı OS güncellemelerinde olduğu gibi benzer bir tarih tekerrür ediyor
Apple'ın şu anda güvenliğe önem vermesinin nedeni yalnızca kullanıcıları korumak değil
Özünde, kullanıcıların onaylanmamış yazılımları kendilerinin çalıştırmasını veya jailbreak gibi şeyleri zorlaştırarak App Store tekelini sürdürmek istiyor
Sonuçta kullanıcının çıkarından çok şirketin çıkarını öncelediğini düşünüyorum
iOS güvenliği hakkında ne zaman bir şey okusam, karmaşıklığı beni hep şaşırtıyor
Donanım katmanı, kernel katmanı, çeşitli sandboxing teknikleri derken oldukça fazla katman birikmiş durumda
Bunun “geçmişteki güven varsayımlarına dayalı bir tasarımın üzerine eklenmiş geçici çözümler” olup olmadığını merak ediyorum
Baştan tasarlansa daha basit hale getirilebilir miydi, gerçekten böyle tasarlanmış işletim sistemleri var mı diye düşünüyorum
Bir platform ne kadar çeşitli kullanım senaryolarını desteklerse, açıklar da o kadar kaçınılmaz olur
Buna verilen yanıt da defence-in-depth yaklaşımıdır
iOS, MacOS tabanlıdır; MacOS da NeXT'ten gelir ve kökeni Unix'tir
Başlangıçta düşük kullanıcı güveni varsayımıyla tasarlanmıştı
Zaman içinde kullanıcıya duyulan güvenin derecesi değişti; son dönemde ise her zaman bağlı ağ özellikleri ve Spectre sonrası yeni tehditler gibi unsurlar nedeniyle giderek daha karmaşık hale geldi
Tarihsel tasarım kararlarına eklenmiş geçici çözümler olup olmadığı sorusuna gelirsek, bence evet
Bu, Unix güvenlik modelinin ve C dili tabanlı sistem programlamasının sınırlamalarını telafi etme çabasının sonucu
Eğer en baştan yeniden tasarlansaydı capability architecture gibi yaklaşımlarla karmaşıklık azaltılabilirdi, ancak POSIX uyumluluğu sorunları yüzünden pratikte çoğu örnek akademik ya da hobi düzeyinde kalıyor
Tamamen yeni bir modele geçildiğinde mevcut Unix programlarının büyük kısmını doğrudan terk etmek gerekeceği için, fiili benimsenmesi son derece zor
seL4, hızlı, güvenli ve resmî olarak doğrulanmış bir microkernel mimarisidir
Yüksek seviyeli erişim kontrolü, sanal makine desteği gibi alanlarda çok başarılı
seL4 microkernel mimarisi açıklama yazısı
Ancak “geri kalan kısım” eksik olduğu için, gerçek bir işletim sisteminden çok araştırma amaçlı bir yapıya daha yakın olduğunu düşünüyorum
İkisini birden denemek mümkün değil mi diye düşünüyorum
"donanım güvenliği"nin de kendine özgü güven varsayımları var ama sonuçta o da sabit kodlanmış bir yazılım; dolayısıyla karmaşıklık arttıkça hata olasılığı da birlikte artıyor
Apple, bu yılki Hexacon Ivan Krstić Keynote'ta bug bounty programını güçlendireceğini duyurdu
ilgili resmî blog
Düzenli güncellemeler veya uygulama çalıştırma sırasında düz metin (şifrelenmemiş) bağlantı sorunlarının hâlâ çözülüp çözülmediğini merak ediyorum
ilgili referans materyal