Bir Sandbox Uygulaması XNU’yu Çökertirse Ne Olur? PAC, KPP, XPC ve CVE-2024-0258 Sonrası Yeni Kernel Araştırmam

[RESEARCH] iOS Kernel’de Sandbox’tan Kernel Panic’e: PAC, KPP, XNU ve CVE-2024-0258 Sonrası Yeni Araştırmam​

Kernel exploit bulundu → jailbreak yapıldı.

Genişletmek için tıkla ...

Burada gerçekten bir security vulnerability var mı?

Genişletmek için tıkla ...

1. Bir Kernel Panic Gördüğünüzde Araştırma Aslında Yeni Başlar​

+----------------------+
| AIO |
+----------+-----------+
|
v
+----------------------+
| EVFILT_AIO |
+----------+-----------+
|
v
+----------------------+
| kevent64 |
+----------+-----------+
|
v
+----------------------+
| XNU |
+----------+-----------+
|
v
+----------------------+
| ARM64 Data Abort |
+----------+-----------+
|
v
+----------------------+
| Kernel Panic |
+----------------------+

Bu davranış normal bir sandboxed iOS application tarafından tetiklenebilir mi?

Genişletmek için tıkla ...

2. Apple Product Security Süreci​

SCENARIO A

Privileged Process
|
v
XNU
|
v
PANIC

SCENARIO B

Sandboxed Application
|
v
Public API
|
v
XNU
|
v
PANIC

Kernel Panic

3. Sandbox Neden Bu Kadar Önemli?​

+---------------------------+
| Sandboxed App |
| |
| Limited privileges |
| Limited filesystem |
| Limited capabilities |
+-------------+-------------+
|
| System APIs
v
+---------------------------+
| XNU / Kernel |
| |
| Higher privilege |
+---------------------------+

Sandboxed Application
|
v
System API
|
v
Kernel
|
v
Subsystem

Kernel Panic
!=
Sandbox Escape

Kernel Panic
!=
Kernel Exploit

Kernel Exploit
!=
Jailbreak

4. Panic Sırasında Ne Görüyoruz?​

FAR = 0x58
ESR = 0x96000006

FAR = 0x58

0x58 gördüm, kesin UAF.

Genişletmek için tıkla ...

Fault
|
v
Faulting Instruction
|
v
Register State
|
v
Pointer Origin
|
v
Kernel Object
|
v
Object Lifetime
|
v
Root Cause

x23 = 0x58

Bu değer neden 0x58?

Genişletmek için tıkla ...

5. İşte Kernel Debugging Burada Gerçekten Eğlenceli Hale Geliyor​

KERNEL PANIC

WHY?

CRASH
|
v
REPRODUCTION
|
v
MINIMIZE
|
v
TRACE PATH
|
v
ROOT CAUSE
|
v
MEMORY STATE
|
v
PRIMITIVE?
|
v
RELIABLE?
|
v
SECURITY IMPACT

6. PAC Neden Jailbreak Araştırmasını Değiştiriyor?​

Pointer
|
v
0xFFFFFFF012345678

Pointer'ı kontrol ediyorum.

Genişletmek için tıkla ...

Control flow'u kontrol ediyorum.

Genişletmek için tıkla ...

Memory Corruption
|
v
Pointer Control?
|
v
Authenticated?
|
v
Useful Primitive?
|
v
Reliable Control?

7. KPP Neden Başka Bir Engel?​

Kernel Bug
|
v
Kernel R/W
|
v
Exploit
|
v
Jailbreak

+----------------------+
| Kernel Vulnerability |
+----------+-----------+
|
v
+----------------------+
| Root Cause |
+----------+-----------+
|
v
+----------------------+
| Memory Primitive |
+----------+-----------+
|
v
+----------------------+
| Reliable? |
+----------+-----------+
|
+----+----+
| |
v v
PAC KPP
| |
+----+----+
|
v
+----------------------+
| Actual Impact |
+----------+-----------+
|
v
+----------------------+
| Exploitability |
+----------+-----------+
|
v
+----------------------+
| Jailbreak |
+----------------------+

Kernel Bug != Kernel R/W
Kernel R/W != Exploit
Exploit != Jailbreak

8. Peki Benim CVE-2024-0258 Araştırmam?​

CVE-2024-0258

ali yabuz

9. XPC Aslında Düşündüğümüzden Daha İlginç​

Process'ler arası iletişim API'si.

Genişletmek için tıkla ...

+----------------------+
| Sandbox App |
| Untrusted Input |
+----------+-----------+
|
| XPC
v
+----------------------+
| Privileged Service |
| |
| Higher Privilege |
+----------+-----------+
|
v
+----------------------+
| Sensitive Operation |
+----------------------+

Input
|
v
Serialization
|
v
Mach IPC
|
v
XPC
|
v
Deserialization
|
v
Validation
|
v
Authorization
|
v
Privileged Operation

10. Araştırmanın Tamamını Yazdım​

Darwin
|
v
XNU
|
v
Mach
|
v
Mach Ports
|
v
IPC
|
v
XPC
|
v
Serialization
|
v
Privileged Service
|
v
Sandbox Boundary

11. XPC Araştırması ile Yeni XNU Araştırmasının Ortak Noktası​

Mach
XPC
libxpc
Serialization
Privileged Services

XNU
AIO
kqueue
EVFILT_AIO
kevent64
ARM64

Trust Boundary​

Sandboxed Process
|
v
XPC
|
v
Privileged Component

Sandboxed Process
|
v
Kernel Interface
|
v
XNU

Daha düşük privilege seviyesindeki bir component, daha yüksek privilege seviyesindeki bir component'e ne gönderiyor ve karşı taraf bunu nasıl işliyor?

Genişletmek için tıkla ...

12. Yeni Kernel Araştırmam CVE Olacak mı?​

Yeni CVE buldum.

Genişletmek için tıkla ...

Root Cause
|
v
Faulting Instruction
|
v
Memory Safety
|
v
Reachability
|
v
Reproducibility
|
v
Security Impact

13. Neden Exploit Detaylarını Paylaşmıyorum?​

Exploit Chain
Privilege Escalation
Kernel R/W
PAC Bypass
KPP Bypass
Weaponization

Research
|
v
Verification
|
v
Vendor Disclosure
|
v
Fix / Advisory
|
v
Public Write-up

14. Araştırmalarımı Takip Etmek İsteyenler İçin​

15. Sonuç​

JAILBREAK

Crash
|
v
Reproduction
|
v
Minimization
|
v
Root Cause
|
v
Primitive
|
v
Reliability
|
v
PAC / KPP / Sandbox
|
v
Exploitability
|
v
Jailbreak

+---------------------------+
| Normal iOS App |
+-------------+-------------+
|
v
+---------------------------+
| Sandbox |
+-------------+-------------+
|
v
+---------------------------+
| AIO / kqueue |
+-------------+-------------+
|
v
+---------------------------+
| EVFILT_AIO |
+-------------+-------------+
|
v
+---------------------------+
| kevent64 |
+-------------+-------------+
|
v
+---------------------------+
| XNU |
+-------------+-------------+
|
v
+---------------------------+
| ARM64 Data Abort |
+-------------+-------------+
|
v
+---------------------------+
| Kernel Panic |
+---------------------------+

Asıl Soru​

Apple'ın security boundary'si tam olarak nerede başlıyor ve nerede bitiyor?

Genişletmek için tıkla ...

Modern iOS jailbreak geliştirmesinde asıl darboğaz sizce artık vulnerability discovery mi?

Yoksa bulunan vulnerability'yi PAC, KPP, sandbox ve diğer modern mitigations karşısında güvenilir bir primitive'e dönüştürmek mi?

Genişletmek için tıkla ...

AliYabuz:

[RESEARCH] iOS Kernel’de Sandbox’tan Kernel Panic’e: PAC, KPP, XNU ve CVE-2024-0258 Sonrası Yeni Araştırmam​

Merhaba JailbreakTR,

Bu konuyu klasik bir “şu açığı buldum” konusu olarak açmak istemedim.

Çünkü modern iOS jailbreak araştırmasının dışarıdan görünen kısmı genellikle çok basit:



Gerçekte ise bu noktaya gelmeden önce çok daha uzun ve ilginç bir süreç var.

Bir crash görüyorsunuz.

Sonra crash'i yeniden üretmeye çalışıyorsunuz.

PoC'yi küçültüyorsunuz.

Hangi process'in bunu tetiklediğini araştırıyorsunuz.

Sandbox içerisinden erişilebilir olup olmadığını kontrol ediyorsunuz.

Register'lara bakıyorsunuz.

Faulting instruction'ı inceliyorsunuz.

Execution path'i takip ediyorsunuz.

Ve ancak bundan sonra şu soruyu sorabiliyorsunuz:



Son dönemde üzerinde çalıştığım XNU araştırması da tam olarak bu noktaya geldi.

Şimdilik exploit veya weaponization detaylarını paylaşmayacağım. Araştırma ve responsible disclosure süreci devam ediyor.

Fakat araştırma sürecinin kendisinin JailbreakTR'deki kernel ve jailbreak araştırmacılarının ilgisini çekebileceğini düşünüyorum.

1. Bir Kernel Panic Gördüğünüzde Araştırma Aslında Yeni Başlar​

Kernel research yapanların çok iyi bildiği bir durum var:

Her kernel panic güvenlik açığı değildir.

Bazıları tamamen beklenen davranışlardan kaynaklanır.

Bazıları assertion'dır.

Bazıları NULL pointer dereference'dır.

Bazıları ise gerçekten araştırmaya değer bir execution path'in göstergesi olabilir.

Benim karşıma çıkan panic ikinci gruba girdi.

Araştırdığım execution path AIO ve kqueue mekanizmalarına kadar uzanıyordu.

Özellikle:

Kod:

+----------------------+
| AIO |
+----------+-----------+
|
v
+----------------------+
| EVFILT_AIO |
+----------+-----------+
|
v
+----------------------+
| kevent64 |
+----------+-----------+
|
v
+----------------------+
| XNU |
+----------+-----------+
|
v
+----------------------+
| ARM64 Data Abort |
+----------+-----------+
|
v
+----------------------+
| Kernel Panic |
+----------------------+

İlk aşamada bu sadece bir crash gibi görünüyor.

Fakat security research açısından asıl sorular burada başlıyor.

Hangi instruction fault verdi?

Hangi register kullanıldı?

Register'ın değeri nereden geldi?

Pointer hangi object'e ait?

Object'in lifetime'ı doğru mu?

Memory daha önce free edilmiş olabilir mi?

Bu execution path hangi process'ler tarafından erişilebilir?

Ve en önemlisi:

2. Apple Product Security Süreci​

İlk aşamada elde ettiğim panic'i Apple Product Security'ye raporladım.

Burada özellikle process ve reachability konusu önemliydi.

Çünkü aşağıdaki iki senaryo aynı sonucu üretebilir:

Kod:

SCENARIO A

Privileged Process
|
v
XNU
|
v
PANIC

ve:

Kod:

SCENARIO B

Sandboxed Application
|
v
Public API
|
v
XNU
|
v
PANIC

İkisinde de sonuç:

Kod:

Kernel Panic

Fakat security impact açısından aralarında çok ciddi fark olabilir.

Bu nedenle PoC'yi küçültmeye başladım.

Gereksiz parçaları çıkardım.

Execution path'i sadeleştirdim.

Ve aynı davranışın normal sandboxed userspace'ten yeniden üretilebildiği daha küçük bir reproduction elde ettim.

Benim için araştırmanın gerçekten ilginç hale geldiği nokta burasıydı.

3. Sandbox Neden Bu Kadar Önemli?​

iOS security modelini çok basitleştirirsek:

Kod:

+---------------------------+
| Sandboxed App |
| |
| Limited privileges |
| Limited filesystem |
| Limited capabilities |
+-------------+-------------+
|
| System APIs
v
+---------------------------+
| XNU / Kernel |
| |
| Higher privilege |
+---------------------------+

Normal beklenti uygulamanın kernel'e doğrudan erişebilmesi değildir.

Ancak uygulamalar çok sayıda public system interface üzerinden kernel'e ulaşabilir:

Kod:

Sandboxed Application
|
v
System API
|
v
Kernel
|
v
Subsystem

Buradaki güvenlik varsayımı oldukça önemli:

Kernel, düşük privilege seviyesinden gelen state'i güvenli şekilde işlemelidir.

Eğer bir execution path beklenmeyen bir memory state oluşturabiliyorsa, araştırılması gereken ciddi bir boundary ortaya çıkar.

Ancak burada önemli bir ayrım var:

Kod:

Kernel Panic
!=
Sandbox Escape

Kernel Panic
!=
Kernel Exploit

Kernel Exploit
!=
Jailbreak

Bu ayrım modern security research açısından oldukça önemli.

4. Panic Sırasında Ne Görüyoruz?​

ARM64 exception state tarafında örneğin:

Kod:

FAR = 0x58
ESR = 0x96000006

gibi değerler dikkat çekiyor.

Burada özellikle:

Kod:

FAR = 0x58

ilk bakışta oldukça ilginç.

Fakat security research'te burada hemen sonuca atlamak büyük hata olur.

Şunu söylemek kolay:



Ama bunu söylemek için yeterli veri yok.

Önce:

Kod:

Fault
|
v
Faulting Instruction
|
v
Register State
|
v
Pointer Origin
|
v
Kernel Object
|
v
Object Lifetime
|
v
Root Cause

zincirinin anlaşılması gerekiyor.

Örneğin belirli bir register'ın:

Kod:

x23 = 0x58

taşıması bize yalnızca bir ipucu verir.

Asıl soru:



Bunu anlamadan vulnerability türünü kesin olarak söylemek doğru değil.

5. İşte Kernel Debugging Burada Gerçekten Eğlenceli Hale Geliyor​

Bir crash loguna bakıp:

Kod:

KERNEL PANIC

demek kolay.

Fakat araştırmacı açısından daha önemli olan:

Kod:

WHY?

sorusudur.

Bir kernel bug'ını araştırırken süreç çoğu zaman şöyle ilerler:

Kod:

CRASH
|
v
REPRODUCTION
|
v
MINIMIZE
|
v
TRACE PATH
|
v
ROOT CAUSE
|
v
MEMORY STATE
|
v
PRIMITIVE?
|
v
RELIABLE?
|
v
SECURITY IMPACT

Bazen ilk crash ile root cause arasında çok büyük fark vardır.

İlk crash yalnızca kapıyı açar.

Asıl araştırma kapının arkasında başlar.

6. PAC Neden Jailbreak Araştırmasını Değiştiriyor?​

Diyelim ki gerçekten kernel memory corruption bulduk.

Eskiden bazı exploitation yöntemleri çok daha doğrudan ilerleyebiliyordu.

Modern Apple platformlarında ise PAC gibi mekanizmalar devreye giriyor.

Pointer Authentication'ı aşırı basitleştirirsek klasik bir pointer'ı:

Kod:

Pointer
|
v
0xFFFFFFF012345678

gibi düşünebiliriz.

PAC kullanılan sistemlerde ise pointer'ın geçerliliği authentication mekanizmalarıyla ilişkilendiriliyor.

Bu yüzden:



ile:



aynı şey değil.

Bunu şöyle düşünebilirsiniz:

Kod:

Memory Corruption
|
v
Pointer Control?
|
v
Authenticated?
|
v
Useful Primitive?
|
v
Reliable Control?

Bir memory corruption elde etmek başka.

Useful primitive elde etmek başka.

Reliable primitive elde etmek ise daha da başka.

İşte modern jailbreak research'ün önemli bir bölümü burada.

7. KPP Neden Başka Bir Engel?​

Bir diğer katman KPP.

Kernel'in kritik bütünlüğünü korumaya yönelik mekanizmalar, elde edilen bir primitive'in doğrudan istediğiniz kernel modification'a dönüştürülmesini zorlaştırıyor.

Bu nedenle:

Kod:

Kernel Bug
|
v
Kernel R/W
|
v
Exploit
|
v
Jailbreak

şeklinde düşünmek artık yeterli değil.

Daha doğru model:

Kod:

+----------------------+
| Kernel Vulnerability |
+----------+-----------+
|
v
+----------------------+
| Root Cause |
+----------+-----------+
|
v
+----------------------+
| Memory Primitive |
+----------+-----------+
|
v
+----------------------+
| Reliable? |
+----------+-----------+
|
+----+----+
| |
v v
PAC KPP
| |
+----+----+
|
v
+----------------------+
| Actual Impact |
+----------+-----------+
|
v
+----------------------+
| Exploitability |
+----------+-----------+
|
v
+----------------------+
| Jailbreak |
+----------------------+

Bu yüzden:

Kod:

Kernel Bug != Kernel R/W
Kernel R/W != Exploit
Exploit != Jailbreak

Bence modern jailbreak araştırmasını eski nesillerden ayıran en önemli noktalardan biri bu.

8. Peki Benim CVE-2024-0258 Araştırmam?​

Burada biraz geriye gitmek gerekiyor.

Apple security research tarafında daha önce Mach IPC ve XPC internals üzerine yoğunlaştım.

Bu araştırmalardan biri Apple tarafından doğrulandı ve:

Kod:

CVE-2024-0258

olarak sonuçlandı.

Apple'ın resmi güvenlik duyurusunda araştırmacı:

Kod:

ali yabuz

olarak kredilendiriliyor.

Apple Security Advisory:

Ziyaretçilere kapalı Giriş yap

CVE-2024-0258 teknik araştırma repository:

Ziyaretçilere kapalı Giriş yap

Bu benim için önemli bir referans noktası çünkü CVE araştırması sırasında XPC, Mach IPC ve sandbox boundaries tarafını oldukça detaylı şekilde inceleme fırsatım oldu.

9. XPC Aslında Düşündüğümüzden Daha İlginç​

XPC'yi yalnızca:



olarak düşünmek eksik kalıyor.

Daha doğru bir bakış:

Kod:

+----------------------+
| Sandbox App |
| Untrusted Input |
+----------+-----------+
|
| XPC
v
+----------------------+
| Privileged Service |
| |
| Higher Privilege |
+----------+-----------+
|
v
+----------------------+
| Sensitive Operation |
+----------------------+

Burada bir trust boundary oluşuyor.

Verinin yolunu düşünelim:

Kod:

Input
|
v
Serialization
|
v
Mach IPC
|
v
XPC
|
v
Deserialization
|
v
Validation
|
v
Authorization
|
v
Privileged Operation

Zincirin herhangi bir noktasında yanlış bir varsayım security problemine dönüşebilir.

CVE-2024-0258 araştırmamın önemli taraflarından biri de bu trust boundary'leri anlamaktı.

10. Araştırmanın Tamamını Yazdım​

Bu konudaki teknik araştırmayı daha sonra Medium üzerinde detaylı bir write-up olarak yayımladım.

Başlık:

Apple XPC Security Internals: Understanding Mach IPC, Sandbox Boundaries, and the Story Behind CVE-2024-0258

Medium:

Ziyaretçilere kapalı Giriş yap

Yazıda özellikle:

Kod:

Darwin
|
v
XNU
|
v
Mach
|
v
Mach Ports
|
v
IPC
|
v
XPC
|
v
Serialization
|
v
Privileged Service
|
v
Sandbox Boundary

zincirini ele alıyorum.

XPC ve Mach IPC tarafına meraklı olanlar için özellikle başlangıç noktası olarak kullanılabilecek bir çalışma.

11. XPC Araştırması ile Yeni XNU Araştırmasının Ortak Noktası​

İlk bakışta iki çalışma tamamen farklı.

Bir tarafta:

Kod:

Mach
XPC
libxpc
Serialization
Privileged Services

Diğer tarafta:

Kod:

XNU
AIO
kqueue
EVFILT_AIO
kevent64
ARM64

Ama aslında ortak bir kavram var:

Trust Boundary​

CVE-2024-0258 tarafında:

Kod:

Sandboxed Process
|
v
XPC
|
v
Privileged Component

Yeni kernel araştırmasında:

Kod:

Sandboxed Process
|
v
Kernel Interface
|
v
XNU

İki araştırmada da aynı temel soruyu soruyorum:



Operating system security research'in en ilginç taraflarından biri bence tam olarak bu.

12. Yeni Kernel Araştırmam CVE Olacak mı?​

Şimdiden kesin konuşmak istemiyorum.

Şu anda atanmış bir CVE numarası yok.

Bu nedenle:



demiyorum.

Daha doğru ifade:

Son kernel araştırmamın CVE assignment sürecine ilerleyebilecek nitelikte olduğunu düşünüyorum.

Şu anda özellikle:

Kod:

Root Cause
|
v
Faulting Instruction
|
v
Memory Safety
|
v
Reachability
|
v
Reproducibility
|
v
Security Impact

üzerinde çalışıyorum.

Eğer root cause ve security impact beklediğim şekilde doğrulanırsa responsible disclosure süreci üzerinden ilerlemesi mümkün.

13. Neden Exploit Detaylarını Paylaşmıyorum?​

Çünkü araştırma devam ediyor.

Özellikle:

Kod:

Exploit Chain
Privilege Escalation
Kernel R/W
PAC Bypass
KPP Bypass
Weaponization

gibi bilgileri araştırma ve disclosure süreci tamamlanmadan paylaşmayı doğru bulmuyorum.

Bir vulnerability'yi public etmek ile responsible disclosure yapmak arasında ciddi bir fark var.

Benim izlediğim yaklaşım:

Kod:

Research
|
v
Verification
|
v
Vendor Disclosure
|
v
Fix / Advisory
|
v
Public Write-up

Önce vulnerability'yi doğru anlamak, sonra impact'i doğrulamak ve daha sonra paylaşmak daha sağlıklı.

14. Araştırmalarımı Takip Etmek İsteyenler İçin​

CVE-2024-0258 teknik araştırması

Ziyaretçilere kapalı Giriş yap

Apple XPC Security Internals

Ziyaretçilere kapalı Giriş yap

Apple Security Advisory

Ziyaretçilere kapalı Giriş yap

GitHub

Ziyaretçilere kapalı Giriş yap

15. Sonuç​

Bence modern jailbreak research'e biraz farklı bakmak gerekiyor.

Çünkü dışarıdan gördüğümüz:

Kod:

JAILBREAK

aslında uzun bir zincirin son noktası.

Gerçekte:

Kod:

Crash
|
v
Reproduction
|
v
Minimization
|
v
Root Cause
|
v
Primitive
|
v
Reliability
|
v
PAC / KPP / Sandbox
|
v
Exploitability
|
v
Jailbreak

Ve bazen ilk satır ile son satır arasında aylarca araştırma olabilir.

CVE-2024-0258 araştırmamda bu yol XPC ve Mach IPC tarafında ilerledi.

Şimdi ise XNU'nun daha alt seviyelerine bakıyorum.

Şu an araştırmada elde edilen tablo kabaca:

Kod:

+---------------------------+
| Normal iOS App |
+-------------+-------------+
|
v
+---------------------------+
| Sandbox |
+-------------+-------------+
|
v
+---------------------------+
| AIO / kqueue |
+-------------+-------------+
|
v
+---------------------------+
| EVFILT_AIO |
+-------------+-------------+
|
v
+---------------------------+
| kevent64 |
+-------------+-------------+
|
v
+---------------------------+
| XNU |
+-------------+-------------+
|
v
+---------------------------+
| ARM64 Data Abort |
+-------------+-------------+
|
v
+---------------------------+
| Kernel Panic |
+---------------------------+

Şimdi çözmeye çalıştığım şey bunun altında ne olduğu.

Eğer yalnızca ilginç bir XNU bug'ıysa bile teknik açıdan değerli bir araştırma.

Eğer gerçek bir memory-safety vulnerability olduğu ortaya çıkarsa konu çok daha farklı bir noktaya gelir.

Security impact de doğrulanırsa CVE sürecine ilerleyebilir.

Ama şu anda bunların hiçbirini olmuş gibi göstermiyorum.

Önce root cause.

Sonra impact.

Sonra disclosure.

Sonra public write-up.

Asıl Soru​

Belki de bu konunun en ilginç tarafı burada.

Bir sandboxed application'ın ulaşabildiği bir kernel interface beklenmeyen bir memory state oluşturabiliyorsa:



Ve JailbreakTR'deki kernel araştırmacılarına sorum:



Özellikle XNU, Mach IPC, PAC, KPP veya kernel exploitation üzerinde çalışan arkadaşların teknik görüşlerini merak ediyorum.

İyi araştırmalar.

Genişletmek için tıkla ...