Stack-Based Buffer Overflow: Penyebab, Deteksi, dan Mitigasi

Stack-Based Buffer Overflow: Penyebab, Deteksi, dan Mitigasi untuk Developer

Stack-based buffer overflow terjadi ketika program menulis data melebihi batas buffer yang berada di stack. Data di sekitarnya dapat rusak, menyebabkan crash, perubahan control flow, atau pada kondisi tertentu eksekusi kode tanpa izin.

Artikel ini berfokus pada pencegahan dan diagnosis di lab milik sendiri, bukan langkah membuat payload eksploitasi.

Contoh Bug

#include
#include

void copy_name(const char *input) {
char name[32];
strcpy(name, input);
printf("name: %s\n", name);
}

strcpy() tidak mengetahui kapasitas destination. Jika input lebih panjang dari buffer, behavior menjadi undefined.

Perbaikan bukan sekadar mengganti semua pemanggilan dengan satu fungsi “aman”. Panjang, terminator, encoding, truncation, dan semantik aplikasi tetap perlu dirancang:

#include

void print_name(const char *input) {
printf("name: %.31s\n", input);
}

Jika data harus disimpan, validasi ukuran sebelum copy dan kembalikan error ketika terlalu panjang. Truncation diam-diam dapat menciptakan collision pada identifier atau keputusan keamanan.

Mengapa Stack Menjadi Sensitif?

Stack frame dapat berisi local variable, saved register, dan metadata control flow. Layout tepat bergantung pada compiler, architecture, ABI, optimization, dan mitigasi.

Karena itu, angka offset dari satu build tidak berlaku universal. Jangan menjadikan layout ilustrasi sebagai kontrak program.

Gunakan Sanitizer saat Development

AddressSanitizer dapat mendeteksi banyak out-of-bounds access:

cc -O1 -g \
-fsanitize=address,undefined \
-fno-omit-frame-pointer \
example.c -o example

Jalankan unit test, integration test, dan fuzz test pada build sanitizer. Sanitizer menambah overhead dan biasanya bukan konfigurasi production, tetapi sangat berguna di CI.

Untuk input parser, fuzzing membantu menemukan kombinasi yang tidak terpikirkan:

bytes acak/terstruktur → parser → sanitizer mendeteksi crash → simpan test case

Setiap crash harus direduksi menjadi regression test setelah diperbaiki.

Mitigasi Compiler dan OS

Mitigasi umum meliputi:

• stack protector/canary;
• NX atau non-executable memory;
• ASLR;
• PIE;
• RELRO;
• control-flow protection pada platform tertentu;
• fortified libc checks.

Mitigasi memperbesar kesulitan eksploitasi, tetapi tidak menghapus bug. Jangan menonaktifkannya pada build release hanya karena test lama gagal.

Konfigurasi bergantung pada toolchain dan distribusi. Periksa flag resmi compiler serta hardening baseline platform, kemudian verifikasi binary yang dihasilkan—bukan hanya build command.

API yang Perlu Diaudit

Pencarian awal dapat menandai:

• gets—sudah dihapus dari standar C modern;
• strcpy dan strcat;
• sprintf;
• scanf dengan %s tanpa batas;
• arithmetic ukuran sebelum malloc atau copy;
• cast signed/unsigned;
• pointer arithmetic;
• parser binary dan protocol.

Tidak setiap pemakaian langsung vulnerable, tetapi semuanya membutuhkan bukti bahwa bounds benar.

snprintf dan length-bounded API tetap dapat disalahgunakan. Periksa return value, ruang untuk null terminator, dan perbedaan “jumlah byte yang ingin ditulis” versus “jumlah byte yang benar-benar ditulis”.

Memory-Safe Language Membantu, tetapi Boundary Tetap Ada

Rust, Java, Go, dan bahasa managed mengurangi banyak kelas memory corruption pada kode aman. Namun risiko tetap dapat muncul pada:

• FFI ke C/C++;
• blok unsafe;
• native dependency;
• deserialization dan logic bug;
• command injection;
• race condition dan authorization.

Migrasi bahasa dapat menjadi strategi jangka panjang, tetapi dependency inventory dan boundary audit tetap diperlukan.

Static Analysis dan Review

Compiler warning harus diperlakukan serius:

cc -Wall -Wextra -Wconversion -Werror example.c

Flag tepat bergantung pada codebase; mengaktifkan semuanya sekaligus pada proyek lama dapat menghasilkan noise. Buat baseline, prioritaskan warning memory dan integer conversion, lalu kurangi debt secara bertahap.

Static analyzer dapat mengikuti aliran ukuran dan pointer yang tidak terlihat dari pencarian teks. Hasil tetap perlu triage: false positive mungkin terjadi, sementara tidak adanya warning bukan bukti kode aman.

Saat review, telusuri asal panjang bersama pointer-nya. Pertanyaan “buffer ini berapa besar?” harus dapat dijawab pada setiap copy. Ukuran dalam element dan ukuran dalam byte tidak boleh tertukar.

Integer Overflow Dapat Mendahului Buffer Overflow

Contoh pola berbahaya:

size_t bytes = count * sizeof(struct item);
void *buffer = malloc(bytes);

Jika perkalian overflow, allocation bisa lebih kecil daripada yang diharapkan, lalu loop berikutnya menulis keluar batas. Periksa sebelum perkalian:

if (count > SIZE_MAX / sizeof(struct item)) {
return ERROR_TOO_LARGE;
}

Batasi pula ukuran input secara bisnis. “Muatan valid secara matematis” belum tentu layak diterima jika dapat menghabiskan memory.

Respons ketika Menemukan Crash

1. Simpan input pemicu secara aman.
2. Reproduksi pada build sanitizer.
3. Tentukan operasi baca/tulis pertama yang keluar batas.
4. Audit jalur serupa, bukan hanya satu call site.
5. Tambahkan regression test.
6. Aktifkan hardening dan perbarui dependency/toolchain.
7. Nilai apakah versi production terdampak.
8. Ikuti coordinated disclosure jika melibatkan software pihak lain.

Jangan memasukkan input sensitif atau exploit proof ke issue publik sebelum patch dan disclosure plan tersedia.

Checklist Pencegahan

• Validasi ukuran pada setiap trust boundary.
• Gunakan arithmetic yang memeriksa overflow.
• Jalankan sanitizer dan fuzzing di CI.
• Pertahankan hardening compiler/linker.
• Minimalkan unsafe/FFI dan review secara khusus.
• Patch dependency native dengan cepat.
• Uji error path serta input kosong, maksimum, dan malformed.

Stack overflow bukan sekadar topik CTF. Bagi developer, nilai utamanya adalah memahami bagaimana satu asumsi panjang yang salah dapat berubah menjadi kerusakan memory dan mengapa defense-in-depth tetap diperlukan.

Referensi

• MITRE CWE-121: Stack-based Buffer Overflow
• CISA: Memory Safe Roadmaps
• Clang: AddressSanitizer
• Clang: UndefinedBehaviorSanitizer
• OWASP: Buffer Overflow