iOS 26.0 / A17 — TweakSSH Üzerinden Tetiklenen Kernel Data Abort

AliYabuz · Dün 11:26 da

Araştırma durumu: Root cause analizi devam ediyor
Platform: iPhone 15 Pro / A17
iOS: 26.0
XNU: xnu-12377.0.154.0.2~118
Etkilenen component: Henüz belirlenmedi
Gözlenen etki: Kernel Panic → Device Reboot

Selamlar

Son birkaç gündür iOS 26.0 üzerinde A17 / XNU kernel araştırmaları yapıyorum.

Araştırma sırasında iPhone 15 Pro (iPhone16,1 / A17) üzerinde, TweakSSH üzerinden userspace context'inde başlatılan bir test sonucunda cihazın beklenmedik şekilde yeniden başladığını gözlemledim.

Panic raporunun incelenmesi sonucunda olayın sıradan bir userspace crash olmadığı, XNU kernel seviyesinde bir Kernel Data Abort meydana geldiği görüldü.

Önemli: Bu aşamada bulguyu exploit, LPE, sandbox escape, tfp0, kernel R/W veya code execution olarak nitelendirmiyorum. Öncelikli hedef faulting instruction'ı ve root cause'u belirlemek.

Cihaz ve Sistem Bilgileri

Bilgi	Değer
Device	iPhone 15 Pro
Identifier	`iPhone16,1`
SoC	A17
iOS	26.0
Build	`23A5297m`
Darwin	`25.0.0`
XNU	`xnu-12377.0.154.0.2~118`
Kernel	`RELEASE_ARM64_T8122`

Panic Signature

Panic'in ana sebebi:

Kod:

Kernel data abort

İlgili register değerleri:

Kod:

PC:
0xfffffff046897158

FAR:
0x0000000000000058

ESR:
0x0000000096000006

Panic eden task:

Kod:

pid: 5146
process: TweakSSH

Kernel text-exec base:

Kod:

0xfffffff0463b8000

Faulting PC'nin kernel text-exec base'e göre hesaplanan yaklaşık relative offset'i:

Kod:

0x4df158

İlk Teknik Değerlendirme

Panic içerisindeki en dikkat çekici değerlerden biri:

Kod:

FAR = 0x58

Bu değer, faulting instruction'ın çok düşük bir sanal adrese erişim gerçekleştirdiğini gösteriyor.

Ancak yalnızca FAR değerinden bunun kesin olarak bir NULL dereference, UAF veya başka bir memory-safety problemi olduğunu söylemek mümkün değil.

Bunun için öncelikle faulting instruction'ın kendisinin belirlenmesi gerekiyor.

Özellikle faulting instruction'ın hangi register'ı kullandığı ve +0x58 erişiminin nasıl oluştuğu root cause açısından kritik.

FAR = 0x58 önemli bir ipucu, fakat tek başına vulnerability classification değildir.

Gözlenen Akış

Kod:

┌──────────────────────────┐
│        TweakSSH          │
│      userspace / 501     │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│     Kernel interaction   │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│           XNU            │
│      Kernel Data Abort   │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│        FAR = 0x58        │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│       Kernel Panic       │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│       Device Reboot      │
└──────────────────────────┘

SSH / Userspace Context

Test ortamının hangi userspace context'inde çalıştığını ayrıca doğruladım.

SSH üzerinden çalışan process:

Kod:

$ sshpass -p 'tweakssh' ssh \
-o PreferredAuthentications=password \
-o HostKeyAlgorithms=+ssh-rsa \
-o PubkeyAcceptedAlgorithms=+ssh-rsa \
-o StrictHostKeyChecking=no \
-o ConnectTimeout=8 \
[email protected] -p 2222 "id"

uid=501(mobile) gid=501(mobile)

Connection to 192.168.1.139 closed by remote host.

Cihazdan doğrudan alınan kernel bilgisi:

Kod:

$ sshpass -p 'tweakssh' ssh \
-o PreferredAuthentications=password \
-o HostKeyAlgorithms=+ssh-rsa \
-o PubkeyAcceptedAlgorithms=+ssh-rsa \
-o StrictHostKeyChecking=no \
-o ConnectTimeout=8 \
[email protected] -p 2222 "uname -a"

Darwin 25.0.0 Darwin Kernel Version 25.0.0: Tue Jul 15 00:13:43 PDT 2025; root:xnu-12377.0.154.0.2~118/RELEASE_ARM64_T8122 iPhone16,1

Bu çıktılar testin mobile / UID 501 userspace context'inde gerçekleştirildiğini ve cihazın gerçekten xnu-12377.0.154.0.2~118 üzerinde çalıştığını doğruluyor.

SSH'nin kendisini bir vulnerability olarak sunmuyorum. SSH burada yalnızca araştırma binary'sini userspace context'inde çalıştırmak için kullanılan erişim kanalı.

Panic'in Userspace Crash Olmadığının Kontrolü

Buradaki önemli ayrım:

Kod:

TweakSSH userspace crash
        ≠
XNU Kernel Data Abort

Panic kaydında:

Kod:

Kernel data abort

PC  = 0xfffffff046897158
FAR = 0x0000000000000058
ESR = 0x0000000096000006

ve:

Kod:

Panicked task:
pid 5146: TweakSSH

görülüyor.

Dolayısıyla panic eden task'ın TweakSSH olması, fault'un userspace belleğinde meydana geldiği anlamına gelmiyor. Panic, kernel exception seviyesinde raporlanıyor.

Önceki Araştırma — sock_port / CVE-2019-8605

Aynı araştırma kapsamında eski sock_port / CVE-2019-8605 primitive'lerini de A17 / iOS 26 üzerinde kontrol ettim.

Test sırasında beklenen eski leak primitive'leri elde edilemedi.

Örnek sonuçlar:

Kod:

set_minmtu → errno=42 (EPROTONOSUPPORT)

disconnectx → 0

get_minmtu → -1

Beklenen kernel pointer leak gözlemlenmedi.

OOL Mach message spray tarafında da:

Kod:

spray receive failed: (ipc/rcv) msg too large

sonucu alındı.

Dolayısıyla:

Mevcut kernel panic'in eski sock_port / CVE-2019-8605 exploit path'inden kaynaklandığına dair şu aşamada bir kanıt bulunmuyor.

RunningBoard / RBS Araştırması

Ayrıca RunningBoard / RBSProcessHandle tarafında çeşitli erişim kontrolleri gerçekleştirildi.

Özellikle:

Kod:

+[RBSProcessHandle currentProcess]

çağrısının yalnızca mevcut process'i döndürdüğü gözlendi.

Örnek:

Kod:

[+currentProcess] pid=5101 valid=1
identity=app<com.orillc.tweakssh(...)>

[ok] factory reports our own pid (expected)

Selector scan sonucu:

Kod:

=== RBS scan summary ===
reachable=0 info=0 exc=0

Mevcut testlerde cross-process information disclosure elde edilmedi.

Dolayısıyla şu aşamada RunningBoard tarafında doğrulanmış bir cross-process disclosure primitive bulunmuyor.

AIO / Kqueue Araştırması

Aynı araştırma kapsamında XNU AIO / kqueue tarafında da bir probe çalıştırıldı.

Probe şu çıktıyı üretti:

Kod:

[AIO-UAF] === XNU AIO Kevent UAF probe ===
[AIO-UAF] fd=15 pid=426 uid=501
[AIO-UAF] attempt 0
[AIO-UAF] *** DOUBLE-FREE ACHIEVED ***
[AIO-UAF]   ident  = 0x10551e050
[AIO-UAF]   data   = 0x0
[AIO-UAF]   udata  = 0xaa
[AIO-UAF]   ext[0] = 0x0 (errorval)
[AIO-UAF]   ext[1] = 0x1000 (returnval)
[AIO-UAF] === done ===

Ancak probe'un:

Kod:

*** DOUBLE-FREE ACHIEVED ***

mesajı gerçek bir UAF/double-free kanıtı olarak kabul edilmedi.

Çıktıdaki:

Kod:

udata  = 0xaa
ext[0] = 0x0
ext[1] = 0x1000

değerleri normal completion davranışıyla uyumlu.

Ayrıca bu testte:

Doğrulanmış kernel pointer leak gözlemlenmedi.
Kernel address disclosure gözlemlenmedi.
Kontrollü freed-object read gözlemlenmedi.
Doğrulanmış UAF gözlemlenmedi.

Dolayısıyla:

AIO probe şu aşamada doğrulanmış bir UAF olarak değerlendirilmemektedir ve mevcut kernel panic'in kaynağı olarak kabul edilmemektedir.

SSH Stability

Araştırma sırasında embedded SSH servisinde ayrıca bazı instability durumları gözlendi.

Örnek:

Kod:

Corrupted MAC on input.

ssh_dispatch_run_fatal:
Connection to 192.168.1.139 port 2222:
message authentication code incorrect

ve:

Kod:

Connection reset by 192.168.1.139 port 2222

Bunları kernel panic ile aynı olay olarak değerlendirmiyorum.

Embedded SSH servisinin ve araştırma scaffolding'inin davranışı nedeniyle userspace/SSH instability ayrı bir konu olarak ele alınıyor.

SSH connection reset ≠ Kernel panic

Kernel-level bulgu yalnızca panic raporu ile doğrulanıyor.

Crash / Checkpoint Durumu

Test ortamındaki uygulama container'ında ayrıca:

Kod:

Documents/
├── openssh/
└── crash_reports/
    ├── checkpoint_history.txt
    ├── live_breadcrumb.txt
    └── last_checkpoint.txt

dosyaları bulunuyor.

last_checkpoint.txt içeriği:

Kod:

go_exploit_ok

Buradaki go_exploit_ok ifadesini gerçek bir kernel exploit primitive'inin elde edildiğinin kanıtı olarak yorumlamıyorum.

Bu yalnızca mevcut harness'in ilgili aşamayı OK olarak işaretlediğini gösteriyor.

Özellikle AIO probe'unda görülen false-positive başarı mesajı nedeniyle harness checkpoint'leri ile gerçek kernel primitive'lerini ayrı tutuyorum.

Faulting PC / Symbolication

Şu anda araştırmanın en önemli kısmı faulting instruction'ın XNU içerisindeki tam karşılığını belirlemek.

Kod:

Kernel text-exec base:
0xfffffff0463b8000

Faulting PC:
0xfffffff046897158

Relative offset:
0x4df158

Dolayısıyla araştırılması gereken temel adres:

Kod:

__TEXT_EXEC + 0x4df158

Bu offset'in XNU 12377 içerisinde hangi function ve instruction'a karşılık geldiğini belirlemek root cause açısından kritik.

Özellikle şu soruların cevaplanması gerekiyor:

Faulting PC hangi kernel function içerisinde?
Instruction hangi register'ı kullanıyor?
FAR = 0x58 bir load mı yoksa store mu?
Pointer hangi kernel object/state'ten geliyor?
Fault path'i hangi subsystem'e ait?
Fault kullanıcı kontrollü bir state'ten etkilenebiliyor mu?
Aynı fault deterministik olarak yeniden üretilebiliyor mu?
Fault memory-safety bug'ına mı, yoksa normal bir invalid-state path'ine mi işaret ediyor?

Neden FAR = 0x58 Önemli?

0x58 oldukça düşük bir adres olduğu için ilk bakışta NULL-base + offset tarzı bir erişim ihtimalini düşündürüyor.

Fakat yalnızca FAR değerinden:

"NULL dereference var."

sonucuna varmak doğru değil.

Bunun için faulting instruction'ın disassembly'si gerekli.

Instruction'ın hangi register üzerinden +0x58 erişimi yaptığı görüldüğünde fault'un gerçek mekanizması hakkında çok daha güçlü bir değerlendirme yapılabilir.

Bu nedenle mevcut değerlendirmem:

FAR = 0x58 önemli bir ipucu, fakat henüz vulnerability classification değil.

Şu Ana Kadarki Durum

Araştırma yüzeyi	Mevcut sonuç
SSH / TweakSSH	Userspace command execution doğrulandı
User context	mobile / UID 501
XNU	12377.0.154.0.2~118 doğrulandı
sock_port / CVE-2019-8605	Eski leak primitive'leri gözlemlenmedi
RunningBoard	Cross-process disclosure doğrulanmadı
AIO	UAF doğrulanmadı
SSH instability	Gözlemlendi
Kernel Data Abort	Gözlemlendi
Device reboot	Gözlemlendi
Root cause	Henüz belirlenmedi
Exploitability	Henüz belirlenmedi

Topluluktan Görüş

Özellikle XNU / ARM64 kernel debugging konusunda çalışan arkadaşların görüşlerini merak ediyorum.

Şu değerlerle daha önce karşılaşan oldu mu?

Kod:

PC     = 0xfffffff046897158
FAR    = 0x0000000000000058
ESR    = 0x0000000096000006
Offset = 0x4df158

Aynı A17 / XNU 12377 ortamında benzer:

Kod:

Kernel data abort

veya:

Kod:

FAR = 0x58

panic'i gören varsa karşılaştırmak oldukça faydalı olur.

Özellikle aşağıdaki konularda deneyimli arkadaşların yorumları değerli olacaktır:

XNU symbolication
ARM64 exception handling
XNU kernel debugging
Mach / IPC
Kernel panic analysis

Panic Log — İlgili Bölüm

Kod:

panic(cpu 0 caller ...):

Kernel data abort

pc:  0xfffffff046897158
far: 0x0000000000000058
esr: 0x0000000096000006

Panicked task:
pid 5146: TweakSSH

Sonuç

Şimdilik bunu bir exploit olarak nitelendirmiyorum.

Mevcut doğrulanmış davranış:

Kod:

Userspace
    ↓
TweakSSH
    ↓
Kernel interaction
    ↓
XNU
    ↓
Kernel Data Abort
    ↓
FAR = 0x58
    ↓
Kernel Panic
    ↓
Device Reboot

Bir sonraki hedef root cause ve faulting kernel path'ini belirlemek.

Özellikle:

Kod:

0xfffffff046897158

adresinin XNU 12377 içerisindeki gerçek instruction/function karşılığını çözmek, araştırmanın şu anki en kritik noktası.

Eğer bu instruction'ın hangi kernel subsystem'ine ait olduğu ve FAR = 0x58 erişiminin hangi pointer üzerinden gerçekleştiği belirlenebilirse, bunun gerçek bir memory-safety problemi, beklenmeyen bir invalid-state path'i veya başka bir kernel fault mekanizması olup olmadığı çok daha net anlaşılacaktır.

Şimdilik elimizde bir exploit değil; fakat A17 / XNU 12377 üzerinde oldukça ilginç bir kernel-level fault var.

Root cause ortaya çıktığında güvenlik etkisinin ne olduğu çok daha net anlaşılacaktır.

Görüş ve özellikle symbolication konusunda yardımcı olabilecek arkadaşların yorumlarını bekliyorum.

iOS 26.0 / A17 — TweakSSH Üzerinden Tetiklenen Kernel Data Abort

AliYabuz

Kayıtlı Üye

Selamlar

Cihaz ve Sistem Bilgileri

Panic Signature

İlk Teknik Değerlendirme

Gözlenen Akış

SSH / Userspace Context

Panic'in Userspace Crash Olmadığının Kontrolü

Önceki Araştırma — sock_port / CVE-2019-8605

RunningBoard / RBS Araştırması

AIO / Kqueue Araştırması

SSH Stability

Crash / Checkpoint Durumu

Faulting PC / Symbolication

Neden FAR = 0x58 Önemli?

Şu Ana Kadarki Durum

Topluluktan Görüş

Panic Log — İlgili Bölüm

Sonuç

Ekli dosyalar

iOS 26.0 / A17 — TweakSSH Üzerinden Tetiklenen Kernel Data Abort

AliYabuz

Kayıtlı Üye

Selamlar​

Cihaz ve Sistem Bilgileri​

Panic Signature​

İlk Teknik Değerlendirme​

Gözlenen Akış​

SSH / Userspace Context​

Panic'in Userspace Crash Olmadığının Kontrolü​

Önceki Araştırma — sock_port / CVE-2019-8605​

RunningBoard / RBS Araştırması​

AIO / Kqueue Araştırması​

SSH Stability​

Crash / Checkpoint Durumu​

Faulting PC / Symbolication​

Neden FAR = 0x58 Önemli?​

Şu Ana Kadarki Durum​

Topluluktan Görüş​

Panic Log — İlgili Bölüm​

Sonuç​

Ekli dosyalar

Selamlar

Cihaz ve Sistem Bilgileri

Panic Signature

İlk Teknik Değerlendirme

Gözlenen Akış

SSH / Userspace Context

Panic'in Userspace Crash Olmadığının Kontrolü

Önceki Araştırma — sock_port / CVE-2019-8605

RunningBoard / RBS Araştırması

AIO / Kqueue Araştırması

SSH Stability

Crash / Checkpoint Durumu

Faulting PC / Symbolication

Neden FAR = 0x58 Önemli?

Şu Ana Kadarki Durum

Topluluktan Görüş

Panic Log — İlgili Bölüm

Sonuç