Buffer Overflow

Buffer Overflow ?

Buffer overflow adalah satu titik lemah yang sering ada. Tidak ada satu software pun, cepat atau lambat tidak dihampiri oleh titik lemah buffer overflow. Pasal’a, satu penyebab buffer overflow adalah prinsip aktifitas dari setiap software, yakni hasil salinan data yang dikirim oleh user dari suatu tempat ke tempat lainnya. Jika developer suatu program menguji semua data sebelum disalin, maka bisa jadi buffer overflow masuk ke dalam library yang digunakan oleh program tersebut.

Buffer overflow bisa disalahgunakan dengan dua alasan. Selain program yang berhubungan atau keseluruhan system ditabrakkan, satu Denial of Service dikeluarkan atau satu Code tranfer diimplementasikan. Untuk suatu penyerangan, implementasi Code lebih hebat lagi, dimana selanjutnya satu Denial of Service bisa dikeluarkan sewaktu-waktu. Yang sangat menarik adalah, buffer overflow dalam program, yang berjalan dengan privilegies tinggi, yakni Root pada Unix/Linux Systems dan Administrator pada Windows Systems. Namun hak bagi user normal juga penting, karena berasal dari sana lah titik lemah selanjut’a bisa disalahgunakan untuk mendapatkan privilegies tinggi dengan lebih mudah lagi.

Contoh sangat berbahaya, buffer overflow dalam program yang bisa diakses melalui network, seperti servers atau TCP/IP stack. Di sini ada satu contoh titik lemah yang ditemukan pada bulan April dalam Mailserver MailEnable. Melalui satu header yang dasar’a telah disiapkan, satu buffer overflow dimunculkan dan selanjut’a Code diimplementasikan juga. Sebuah program yang menyalahgunakan titik lemah ini (satu yang dikenal sebagai Exploit), telah dipublikasikan dalam Internet. Alhasil, satu “pintu belakang” ditutup, dan melalui pintu tersebut itulah aggressor bisa mengambil alih kontrol melalui komputer yang terhubung.

Bagi para aggressor, titik lemah tersebut mempunyai dua keuntungan, yakni mereka bisa menyelewengkan’a, dan tidak bergantung pada aksi user manapun. Lalu, mereka bisa menentukan komputer mana yang ingin diserang. Pada titik lemah yang digambarkan di bawah, seorang aggressor paling tidak memilih user tertentu, yang dikirimi’a satu email yang dipersiapkan untuk penyalahgunaan suatu titik lemah tersebut. Ia tidak mengetahui, di komputer yang mana email tersebut dibaca.

Kategori lain’a adalah buffer overflow dalam library. Ini yang disalahgunakan, dimana data yang telah siap dikeluarkan oleh suatu program, supaya bisa memanggil function yang berhubungan dengan library. Contoh tertentu dari kategori ini, yaitu titik lemah dalam Microsoft JPEG processing dalam GDI+. Titik lemah yang muncul pada September 2004 ini bisa disalahgunakan melalui satu foto JPEG yang telah disiapkan, untuk menjalankan code tertentu. Untuk itu, foto tertentu harus’a hanya dibuka dalam satu aplikasi, yang menggunakan library yang berhubungan. Pembacaan email atau website, yang berisi foto tersebut, telah cukup. Sesaat setelah publikasi titik lemah melalui Microsoft, muncullah gambar pertama di Internet, yang menyalahgunakan titik lemah tersebut, untuk menginstal satu trojaner dan juga membuka “pintu belakang”.

Bahaya tertentu pada titik lemah dalam libraries terdiri dari satu sistem yang telah di-patch menjadi sensitif, jika satu program pada installation’a menukar koreksi library melalui satu versi lama yang sensitif dan selanjut’a menginstall’a. Biasa’a user juga tidak mengetahui, apakah satu program tertentu menggunakan satu library sensitif dan functions yang berhubungan. Selanjut’a bahaya akibat titik lamah ini sulit ditentukan oleh user itu sendiri.

Buffer overflow dalam program aplikasi biasa’a disalahgunakan melalui file yang telah disiapkan. Satu actual provider pada kategori ini adalah satu titik lemah dalam Word. Satu dokumen yang telah disiapkan, menggiring ke satu buffer overflow, dan melalui’a code transfer disediakan. File semacam bisa dikirim misal’a melalui email atau ditawarkan untuk bisa didownload pada satu website. Code transfer diimplementasikan dengan seijin user. Jika ini bekerja sesuai ijin administrator, maka aggressor mendapatkan kontrol penuh mengenai komputer yang berhubungan.

Titik Lemah Search Dalam Binaries

Fault Injection
Pada Fault Injection, program yang diteliti dipanggil dengan parameter yang ekstrim dan tidak biasa’a dan/atau ditempati oleh variabel environment pada value yang ada. Jika program itu berisi satu titik lemah buffer overflow, akan muncul reaksi tak terbayangkan pada input-nya, umum’a berupa satu crash. Namun, sebalik’a jika program berjalan lagi secara normal, maka tidak akan ditemukan buffer overflow yang bisa dimanfaatkan melalui parameter yang telah disebutkan, atau bisa juga diakibatkan parameter yang tersedia dahulu belum cukup besar.

Pada satu sisi, suatu program bisa dipanggil secara manual dengan parameter tertentu, dan di sisi lain’a terdapat test program spesial untuk itu. Di sini dibedakan antara host-based dan network-based programs.

Host-based programs contoh’a adalah BFBTester dan Sharefuzz. BFBTester (Brute Force Binary Tester) ternyata bisa memanipulasi parameter single dan jamak atau variabel Environment. Sharefuzz berfungsi tanpa melakukan search ke titik lemah buffer overflow pada processing variabel environment.

Network-based programs contoh’a adalah Hailstorm atau Spike. Hailstorm melakukan search titik lemah dalam web application. Selain melakukan pencarian terhadap buffer overflow, program itu juga mencari weak point Cross Site Scripting dan SQL Injection. Sedang Spike melayani penelitian protokol network dan program yang terhubung dengan’a.

Dynamic Analisys
Pada analisis dinamis, maksud’a analisis selama run time, 2 tipe program digunakan: yaitu Tracer dan Debugger.

Saru Tracer melakukan log peredaran suatu program. Protokol yang dibuat diuji coba selanjut’a pada kasus tertentu seperti buffer yang belum diuni coba. Ini juga memungkinkan perekonstruksian penggunaan dari variabel, yang kelak melakukan uji coba dengan bantuan Fault Injection sesuai tujuan’a.

Satu Debugger tidak bisa melakukan log peredaran tersebut seperti satu Tracer, namun justru manipulasi’a. Manipulasi yang mungkin terjadi tercapai dari pengalihan Instruction Pointer hingga ke perubahan variabel dan instruksi. Contoh untuk Debugger adalah Gnu Debugger gdb dan SoftICE.

Reverse Engineering
Pada Reverse Engineering, source code dikembangkan untuk satu program yang ada. Untuk itu program tersebut dirangkai atau didekompilasi. Satu program yang sering digunakan untuk itu, adalah interaktive Dissassembler IDA-Pro. Interactive dalam hal ini maksud’a adalah bahwa developer selama perangkaian memutuskan sendiri apakah data diinterpretasikan sebagai data atau code. Sebagai hasil’a, didapatkan source code Binary dalam Assembler. Di dalam’a seperti tertulis pada Sourcecode Audit, dapat dicari fungsi panggilan yang menjadi penyebab. BugScam, satu development untuk IDA Pro, juga membantu.

Satu Contoh
Satu program yang hanya tersedia secara binary diteliti untuk mengetahui ada tidaknya titik lemah buffer overflow. Contoh’a mengenai satu Editor, yang dipanggil melalui command lines dengan nama dari file yang bisa dibuka. Pertama-tama bisa dicoba dengan bantuan Fault Injection menampilkan satu reaksi yang tidak biasa, seperti:

tester edit `perl -e ‘print “A”x1024′`

Jika ada yang datang menghampiri buffer overflow, maka satu Segmentation fault segera dilaporkan. Mungkin hasil ini sudah memenuhi dan diketahui lebih banyak lagi. Jika satu nama file yang ekstrim mengarah ke satu buffer overflow, mungkin masih ada titik lemah lain’a yang serupa. Dalam kasus ini, satu penelitian seputar variabel environment sangat menarik. Namun, parameter command line lain’a adalah Test object yang sangat berguna. Untuk memudahkan pencarian, sekarang contoh’a bisa digunakan BFBTester:

tester bfbtester -a edit
*** Crash ***
args: -h [05120]
envs:
Signal: 11 ( Segmentation fault )
Core? Yes

Program tersebut terganjal pada pemanggilan dengan option -h dan satu parameter yang panjangnya 5.120 indikasi dengan satu segmenting error. Jika seseorang masih ingin mengetahui, ia bisa mencari tahu seputar peredaran program dengan satu Debugger. Juga muncul pertanyaan yang paling menarik, apakah ini mengenai serangkaian Denial of Service weak point atau apakah penampilan transferred code. Yang penting untuk ini adalah overwriting untuk peredaran program dari variabel yang penting.

Buffer Overflow Tracking

Untuk menelusuri titik lemah buffer overflow, terdapat dua kemungkinan, yakni pencarian dalam source code dan analisis binaries. Developer biasa’a memilih pencarian dalam source code, sejak tersedia untuk mereka. Namun demikian, analisis binaries bagi mereka tetaplah berarti, contoh’a jika titik lemah diumpamakan dalam libraries gabungan.

Sourcecode Audit

Pada prinsip’a, di sini source code diteliti tahap demi tahap berdasarkan posisi code yang mencurigakan. Jika yang dicari hanya titik lemah buffer overflow’a, maka baru besaran pasti dari semua buffer overflow yang diteliti, lalu beringsut pada proses lanjutan lain’a. Pencarian manual ini tentu saja adalah metode yang tergolong rumit, namun terbilang yang paling aman.

Untuk automatic tools, terhadap dua tahap yang harus dilakukan, yakni analisis syntaktis atau leksikalis dan semantis. Pada analisis syntaktis, dicari berdasarkan fungsi berbahaya yang potensial, selama aliran data pada analisis semantis dianalisis.

Analisis Syntaktis

Sarana pendukung yang paling sederhana untuk pencarian berdasarkan panggilan function berbahaya adalah search function dari editor dan grep Tool yang digunakan. Karena developer harus mencari berdasarkan setiap function’a satu persatu, maka penggunaan untuk analisis syntaktis, tidak bisa dianggap gampang. Hal ini sangat tepat untuk program² spesial, seperti flawfinder untuk C dan C++ serta RATS untuk C, C++, Perl, PHP dan Python. Kedua’a menggunakan satu database dengan fungsi yang berpotensi berbahaya dan titik lemah yang ditemukan, yaitu petunjuk untuk efek dan bantuan yang memungkinkan.
Contoh:

Test-Programm test.c

#include

int main (int argc, char *argv[])
{
char puffer[8];
if (argc > 1)
strcpy (puffer, argv[1]);
return 0;
}

Tampilan flawfinder

ceilers flawfinder test.c
Flawfinder version 1.26, (C) 2001-2004 David A. Wheeler.
Number of dangerous functions in C/C++ ruleset: 158
Examining test.c
test.c:6: [4] (buffer) strcpy:
Does not check for buffer overflows when copying to destination.
Consider using strncpy or strlcpy (warning, strncpy is easily misused).
test.c:4: [2] (buffer) char:
Statically-sized arrays can be overflowed. Perform bounds checking,
use functions that limit length, or ensure that the size is larger than
the maximum possible length.

Hits = 2
[...]
Not every hit is necessarily a security vulnerability.
There may be other security vulnerabilities; review your code!

Sejak dari analisis syntaktis, semua panggilan function juga ditampilkan, dimana sebelum’a parameter diuji coba hanya jika ada banyak peringatan kesalahan.

Analisis Semantis

Pada analisis semantis, aliran data dianalisis. Ini merupakan bagian dari compiling procedure. gcc-Compiler menampilkan, contohnya pada indikasi option -Wall, dan juga warning pada penggunaan functions yang tidak pasti. Namun ada juga program tersendiri untuk analisis semantis. Satu contoh untuk tool semacam itu adalah Splint. Splint menguji, apakah hipotesis tertentu yang dispesifikasikan sebagai “annotations” dalam source code, mengena. Annotations untuk function strcpy(s1, s2) terlihat contoh’a seperti berikut ini:

void /*@alt char * @*/ strncpy
(/*@unique@*/ /*@out@*/ /*@returned@*/ char *s1, char *s2, size_t n)
/*@modifies *s1@*/
/*@requires maxSet(s1) >= ( n – 1 ); @*/
/*@ensures maxRead (s2) >= maxRead(s1) /\ maxRead (s1) <= n;@*/;

Klausal requires menuntut, bahwa buffer yang diberikan sebagai s1 haruslah cukup besar, untuk merekord s2. Dalam Klausal ensure sudah pasti jumlah tanda terbaca dari s1 dan s2 harus sama besar berdasarkan panggilan’a. Pada kasus-kasus yang di dalam’a besaran s2 tidak dikenali, function strncpy(s1, s2, n) digunakan. Annotations’a terlihat sebagai berikut:

void /*@alt char * @*/ strncpy
(/*@unique@*/ /*@out@*/ /*@returned@*/ char *s1, char *s2, size_t n)
/*@modifies *s1@*/
/*@requires maxSet(s1) >= ( n – 1 ); @*/
/*@ensures maxRead (s2) >= maxRead(s1) /\ maxRead (s1) <= n;@*/;

Klausal requires menuntut, bahwa buffer yang diberikan sebagai s1 harus’a cukuplah besar, untuk merekam jumlah copying indication. Klausal ensure menetapkan, bahwa tanda nn disalin dari s1 ke s2. Metode untuk analisis source code mencukupi pada sebagian besar kasus untuk menemukan titik lemah. Jika source code tidak tersedia, maka hanya analisis binaries-lah yang akan membantu.

Buffer Overflow Defense

Pada umum’a, mengubah dasar system sehingga bisa melindungi aplikasi dari masalah- masalah keamanan yang rentan adalah ide yang paling bagus. Beberapa dari ukuran keamanan yang popular dapat dikelompokkan kedalam kategori seperti dibawah ini:

* Canary-based defenses. Yaitu meliputi Stack Guard (seperti yang digunakan oleh Immunix), ssp/ProPolice (digunakan oleh OpenBSD), dan Microsoft’s /GS option.

* Non-executing stack defenses. Yaitu meliputi Solar Designer’s non-exec stack patch (yang digunakan oleh OpenWall) dan exec shield (digunakan oleh RedHat/Fedora).

* Pendekatan lain’a. Yaitu meliputi libsafe (yang digunakan mandrake) dan pendekatan split-stack.

Sayang’a, semua pendekatan yang telah dilakukan selama ini masih mempunyai kelemahan, sehingga tidak ada “obat mujarab” untuk menangani buffer overflow, tapi pendekatan- pendekatan diatas sudah dapat sangat membantu.