Eksperimen Penghapusan Stack Canary

Feb 27 2023

Terinspirasi oleh Walter Harold Bishop, dalam posting ini saya akan mencoba menemukan cara yang lebih baik untuk melindungi integritas alamat pengirim dibandingkan dengan tumpukan burung kenari. Harap dicatat bahwa saya tidak percaya apa yang ada dalam pikiran saya adalah solusi yang tepat.

Saya tidak suka kenari tumpukan karena mereka tidak benar-benar menyelesaikan akar penyebab masalahnya. Bahkan halaman Wikipedia menempatkannya dalam perspektif yang benar. Izinkan saya mengutip:

Teknik ini dapat sangat meningkatkan kesulitan mengeksploitasi stack buffer overflow

"Meningkatkan kesulitan mengeksploitasi". Itu tidak memperbaiki masalah. Ini meningkatkan kesulitan eksploitasi.

Pada saat menulis postingan ini, tahunnya adalah 2023. Anda masih dapat melakukan hal berikut:

#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[]) {
    char *payload =
        "AAAAAAAAAAAAAAAA"
        "AAAAAAAAAAAAAAAA"
        "AAAAAAAAAAAAAAAA"
        "AAAAAAAAAAAAAAAA"
        "AAAAAAAAAAAAAAAA"
        "AAAAAAAAAAAAAAAA"
        "AAAAAAAAAAAAAAAA"
        "AAAAAAAAAAAAAAAA";
    char buffer[32];
    memcpy(buffer, payload, (int)strlen(payload));
    printf("%s\n", buffer);
}

(lldb) target create "./test"
Current executable set to '/Users/zsoltimre/DEVEL/EXPERIMENT/Virtual-CPU/test' (arm64).
(lldb) r
Process 15890 launched: '/Users/zsoltimre/DEVEL/EXPERIMENT/Virtual-CPU/test' (arm64)
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Process 15890 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x19c4c4bb0)
    frame #0: 0x000000019c4c4bb0 libsystem_c.dylib`__chk_fail_overflow + 24
libsystem_c.dylib`:
->  0x19c4c4bb0 <+24>: brk    #0x1
libsystem_c.dylib`:
    0x19c4c4bb4 <+0>:  pacibsp 
    0x19c4c4bb8 <+4>:  stp    x29, x30, [sp, #-0x10]!
    0x19c4c4bbc <+8>:  mov    x29, sp
Target 0: (test) stopped.

Saya memutuskan untuk menyelidiki dan bereksperimen dengan sesuatu yang lain. Bagaimana jika kami menghapus alamat pengirim sepenuhnya dari tumpukan? Pada tingkat tinggi, itu berarti penyerang tidak akan dapat mengubah alur eksekusi atau menghentikan program dengan memodifikasi alamat pengirim. Saya akui solusi semacam itu ada harganya, tetapi itu menyelesaikan masalah.

Jadi, ide saya dan bukti konsep yang terlalu disederhanakan singkatnya:

Alamat pengembalian disimpan di area memori khusus (RSTACK) yang berperilaku seperti tumpukan. RSTACK bersifat read-only untuk kode pengguna. Hanya CPU yang dapat mendorong dan memunculkan nilai dari RSTACK. Di PoC ini diberlakukan dengan menggunakan array khusus .
Ada register tautan khusus (Return Pointer / RP) yang mengarah ke atas RSTACK. Daftar ini hanya dapat dibaca untuk kode pengguna. Hanya CPU yang dapat mengubah nilainya.
Instruksi CALL* dan RET* CPU mengelola RSTACK.
Tidak ada instruksi lain yang dapat menulis ke RSTACK.

Kondisi awal CPU

Mari kita lihat seperti apa status CPU dan memori tepat setelah instruksi CALL.

Kemudian, jika kita membiarkan instruksi dari alamat 7 mengeksekusi dan merusak tumpukan saat mengeksekusi instruksi RET terakhir, kita akan mendarat tepat di tempat yang kita inginkan, di alamat 4. Apa pun yang kita lakukan dengan tumpukan, kita selalu dapat kembali dan melanjutkan eksekusi.

Dalam aplikasi kehidupan nyata, kemungkinan besar kerusakan nilai pada tumpukan akan menyebabkan masalah lain (mis. pembagian dengan nol atau dereferensi penunjuk nol) yang akan menyebabkan crash program. Oleh karena itu, solusi ini tidak mengatasi semua penolakan masalah layanan. Tetapi,