Relapse Exploit PS5: Rantai Dua Tahap dari JSC sampai Use-After-Free Kernel

Sebuah proyek riset keamanan bernama Relapse Exploit muncul di publik dan menyasar konsol PlayStation 5 pada rentang firmware 7.00 sampai 13.60. Proyek ini dirilis terbuka dengan lisensi riset, dan menarik untuk dibaca bukan karena aspek konsumennya, melainkan karena rantai eksploitasinya menggambarkan dua kelas bug yang terus berulang di perangkat modern: kebocoran informasi di mesin JavaScript dan kondisi balapan use-after-free di kernel.

Apa yang Dirilis

Repositori Relapse menyatakan dukungan untuk firmware 7.00 hingga 13.60. Alur penggunaannya sederhana secara permukaan: pengguna mengarahkan DNS primer konsol ke sebuah alamat, lalu menjalankan skrip server secara lokal atau membuka halaman yang di-host proyek tersebut dari browser konsol. Setelah berhasil, payload tersimpan di direktori payloads, dan ELF loader mendengarkan pada port 9021.

Catatan stabilitas di dokumentasi proyek jujur soal tingkat keberhasilannya. Tahap browser disebut mungkin butuh beberapa percobaan, dan pengguna diminta memuat ulang halaman bila browser macet. Tahap kernel bahkan bisa menggantung atau memicu panic pada konsol, sehingga disarankan melakukan reboot sebelum mencoba lagi. Ini bukan tanda implementasi yang buruk, melainkan sifat alami eksploitasi memori yang bergantung pada kondisi balapan.

Rantai Eksploitasi: Dua Tahap

Dokumentasi proyek memecah rantai eksploitasinya menjadi dua bagian, dan bagian inilah yang layak dipelajari dari sudut pandang pertahanan.

Tahap browser. Tahap ini memakai kebocoran informasi pada JavaScriptCore (JSC), mesin JavaScript yang dipakai WebKit. Kebocoran itu digabung dengan ketidaksesuaian pada object pool saat operasi structured clone, yang kemudian dipakai untuk merusak sebuah typedarray. Polanya klasik: dua komponen yang masing-masing hanya memberi primitif lemah, tetapi jika digabung memberi kemampuan membaca dan menulis memori di luar batas yang seharusnya.

Tahap kernel. Setelah punya primitif di ruang pengguna, tahap kedua menggabungkan kebocoran alamat dengan kondisi balapan use-after-free pada aio_multi_wait. Hasil akhirnya adalah kemampuan baca dan tulis kernel. Begitu kernel read/write tersedia, batas keamanan perangkat pada dasarnya sudah terbuka.

Perhatikan pola yang berulang di sini. Bug pertama adalah masalah korektness pada manajemen memori mesin JavaScript, kelas kerentanan yang secara historis menjadi sumber sebagian besar eksploitasi browser. Bug kedua adalah use-after-free di jalur sistem yang menangani operasi asinkron, kelas bug yang sangat sulit dihilangkan sepenuhnya karena bergantung pada waktu eksekusi.

Mengapa Rantai Dua Tahap Menjadi Standar

Hampir semua eksploitasi modern untuk perangkat dengan arsitektur keamanan berlapis memakai pola bertingkat. Browser adalah permukaan serangan pertama karena ia memproses konten dari luar dan berjalan di ruang pengguna yang terkurung. Namun sandbox ruang pengguna biasanya cukup kuat untuk mencegah dampak langsung. Karena itu penyerang memerlukan tahap kedua: keluar dari sandbox menuju kernel.

Setiap tahap memerlukan primitif yang berbeda. Tahap browser membutuhkan baca/tulis memori dalam proses, plus cara menghindari mitigasi seperti ASLR. Tahap kernel membutuhkan bug yang bisa dipicu dari ruang pengguna, biasanya use-after-free atau race condition, lalu cara menstabilkan hasilnya. Karena tiap tahap punya probabilitas keberhasilan sendiri, keberhasilan keseluruhan adalah hasil kali keduanya, dan itulah sebabnya dokumentasi menyebut perlunya beberapa percobaan.

Perhatikan implikasi dari perkalian probabilitas itu. Bila satu tahap punya peluang berhasil lima puluh persen dan tahap kedua juga lima puluh persen, peluang keseluruhan hanya dua puluh lima persen. Inilah alasan eksploitasi semacam ini jarang stabil pada percobaan pertama, dan mengapa penyerang biasanya menuliskan skrip yang mencoba berulang kali sambil memulihkan perangkat ke keadaan bersih di antara percobaan. Dari sudut pertahanan, sifat tidak stabil ini justru menguntungkan: ia memberi jendela waktu bagi sistem deteksi untuk mengenali pola percobaan berulang yang mencurigakan.

Implikasi untuk Pertahanan

Bagi tim yang mengembangkan perangkat dengan arsitektur serupa, ada beberapa pelajaran yang bisa diambil.

• Mesin JavaScript tetap jadi permukaan serangan utama. Setiap kebocoran informasi di JIT atau pada operasi yang melibatkan objek terstruktur perlu diperlakukan sebagai temuan serius, bukan sekadar bug fungsional.
• Object pool dan structured clone adalah area sensitif. Ketidaksesuaian tipe pada jalur ini pernah dan masih menjadi sumber primitif eksploitasi.
• Jalur asinkron adalah tempat use-after-free bersembunyi. Operasi yang melibatkan penantian bersama seperti keluarga aio_multi_wait memerlukan audit siklus hidup objek yang sangat teliti.
• Sandbox bukan pengganti perbaikan bug. Isolasi proses mengurangi dampak, tetapi tidak menghilangkan kebutuhan menambal akar masalahnya.

Untuk pengguna konsol sendiri, saran praktisnya sederhana: jangan arahkan perangkat ke DNS atau server yang tidak Anda kenal, karena halaman yang dimuat browser konsol menjalankan kode di lingkungan yang bisa dieksploitasi. Bagi vendor, pelajarannya adalah bahwa keamanan perangkat modern bergantung pada rantai yang utuh. Satu lapisan yang bocor cukup untuk membatalkan asumsi lapisan lainnya.

Anatomi Kerentanan: JSC dan Structured Clone

Untuk memahami mengapa tahap browser bisa berhasil, perlu diketahui bahwa mesin JavaScript modern seperti JavaScriptCore tidak lagi sekadar menerjemahkan kode. Mesin ini memakai kompilasi just-in-time (JIT) untuk mengubah bagian kode yang sering dijalankan menjadi kode mesin native. Optimasi agresif inilah yang membuka ruang bagi bug tipe: ketika JIT menyimpulkan tipe sebuah nilai secara keliru, hasil kompilasinya bisa memperlakukan memori dengan cara yang tidak sesuai dengan isi sebenarnya.

Structured clone adalah mekanisme yang dipakai browser untuk menyalin objek kompleks, misalnya saat mengirim data lewat postMessage antar konteks. Implementasinya melibatkan pengelolaan pool objek agar penyalinan cepat. Ketika ada ketidaksesuaian antara cara objek diklaim dari pool dan cara objek itu sebenarnya dialokasikan, penyerang bisa mendapatkan objek dengan tipe yang salah, dan dari situ menurunkan primitif baca/tulis memori.

Kombinasi dua hal ini, kebocoran informasi lewat JSC dan ketidaksesuaian pool pada structured clone, memberi penyerang fondasi yang dibutuhkan. Perhatikan bahwa masing-masing bug mungkin hanya memberi kemampuan terbatas bila berdiri sendiri. Nilai sebenarnya muncul dari cara keduanya dirangkai.

Anatomi Kerentanan: Use-After-Free di Jalur Asinkron

Di sisi kernel, bug yang dipakai adalah use-after-free pada aio_multi_wait. Use-after-free terjadi ketika sebuah objek memori dibebaskan, tetapi masih ada kode lain yang memegang referensi ke objek tersebut dan menggunakannya. Akibatnya, kode tersebut bisa membaca atau menulis memori yang sudah dipakai ulang untuk keperluan lain.

Yang membuat bug ini menarik adalah posisinya di jalur asinkron. Operasi seperti aio_multi_wait menangani banyak permintaan yang datang bersamaan, dengan siklus hidup objek yang kompleks. Kondisi balapan muncul ketika urutan eksekusi yang tidak terduga membuat objek dibebaskan lebih awal dari yang diasumsikan kode. Inilah sebabnya eksploitasi semacam ini sering tidak stabil dan memerlukan beberapa percobaan.

Kombinasi kebocoran alamat dan use-after-free memungkinkan penyerang menentukan lokasi memori yang tepat, lalu menimpa struktur data yang penting bagi kernel. Begitu kendali atas kernel tercapai, batas keamanan perangkat pada dasarnya sudah tidak berlaku lagi.

Sejarah Singkat Pola yang Sama

Pola dua tahap yang dipakai Relapse bukan hal baru. Eksploitasi konsol generasi sebelumnya, serta eksploitasi browser di platform desktop, berulang kali memakai struktur yang serupa: bug tipe di mesin JavaScript, lalu bug manajemen memori di kernel atau di komponen dengan hak akses lebih tinggi.

Yang menarik untuk dicermati adalah bagaimana industri berevolusi sebagai respons. Mitigasi seperti isolasi situs, sandbox proses terpisah, dan pengacakan tata letak memori (ASLR) semuanya dirancang untuk mempersulit rantai semacam ini. Namun setiap lapisan mitigasi pada akhirnya hanya menambah biaya bagi penyerang, bukan menghilangkan kelas bug-nya. Selama mesin JavaScript masih mengompilasi kode secara agresif dan kernel masih menangani operasi asinkron yang kompleks, kelas bug ini akan terus muncul.

Pelajaran untuk Pengembangan Perangkat

Bagi tim yang membangun perangkat dengan arsitektur serupa, ada beberapa pelajaran yang bisa diambil dari rantai ini. Pertama, audit jalur asinkron secara berkala. Use-after-free pada operasi yang menangani banyak permintaan bersamaan adalah kelas bug yang paling sering lolos dari pengujian fungsional, karena kemunculannya bergantung pada waktu. Pengujian dengan beban bersamaan dan alat deteksi seperti sanitizer memori jauh lebih efektif daripada pengujian satu per satu.

Kedua, perlakukan kebocoran informasi sebagai temuan berprioritas tinggi. Kebocoran yang tampak tidak berbahaya, misalnya hanya mengungkap alamat memori, sering dianggap risiko rendah. Dalam praktiknya, kebocoran itulah yang memungkinkan tahap berikutnya berhasil, karena penyerang memerlukan alamat yang tepat untuk menimpa struktur data.

Ketiga, jangan mengandalkan satu lapisan saja. Rantai Relapse menunjukkan bahwa sandbox browser dan isolasi proses memang menaikkan biaya eksploitasi, tetapi tidak menghilangkan kebutuhan memperbaiki bug di akar. Pertahanan berlapis yang baik mengurangi dampak sekaligus memperlambat penyerang, tetapi tetap memerlukan perbaikan pada sumber masalahnya.

Keempat, catat dan dokumentasikan jalur kode yang sensitif. Sebagian besar waktu audit dihabiskan untuk menemukan di mana masalahnya, bukan untuk memperbaikinya. Tim yang punya inventaris jalur kode sensitif, misalnya semua tempat yang menangani siklus hidup objek di jalur asinkron, akan jauh lebih cepat merespons laporan semacam ini.

Konteks dan Batasan

Proyek ini secara eksplisit menyatakan tujuannya untuk riset keamanan dan pendidikan, serta tidak mendukung pembajakan atau akses tanpa izin. Dokumentasinya juga mencantumkan peringatan risiko yang jelas: ketidakstabilan sistem, kehilangan data, sampai potensi pemblokiran akun. Ini penting dicatat karena eksploitasi kernel pada perangkat konsumen membawa konsekuensi nyata bagi perangkat yang bersangkutan.

Nilai utama rilis semacam ini bagi komunitas pertahanan bukan pada kemampuannya menjalankan kode, melainkan pada dokumentasi rantai eksploitasinya. Deskripsi dua tahap yang ringkas, menyebut komponen spesifik seperti JSC dan aio_multi_wait, memberi titik awal yang konkret untuk audit. Vendor yang membaca laporan seperti ini dengan cepat bisa mengidentifikasi jalur kode yang perlu diperkuat sebelum kelas bug yang sama dipakai ulang pada perangkat generasi berikutnya.

Perlu juga dicatat bahwa eksploitasi semacam ini biasanya bergantung pada versi firmware tertentu. Rentang dukungan 7.00 sampai 13.60 menunjukkan bahwa bug yang dipakai sudah ada sejak cukup lama dan bertahan melewati banyak pembaruan firmware. Bagi vendor, ini pengingat bahwa pembaruan firmware yang hanya menambal sebagian jalur serangan tidak cukup; yang dibutuhkan adalah perbaikan pada akar kelas bug-nya.

Pada akhirnya, Relapse mengingatkan bahwa keamanan platform adalah pekerjaan berkelanjutan. Setiap lapisan, dari mesin skrip di permukaan sampai subsistem asinkron di kernel, harus diasumsikan bisa gagal, dan desain pertahanan yang baik memperhitungkan kegagalan itu alih-alih mengandalkan satu dinding tunggal.

Rekomendasi Tools & Layanan

Kalau lo mau langsung praktikkan panduan di atas, dua layanan yang gue pake sehari-hari: free trial Alibaba Cloud buat coba-coba tanpa biaya di awal, dan ECS instance 9th-gen kalau udah siap naik ke VPS production.