Kutukan Memory Corruption

Ketika berkutat dengan dunia hacking / security, melihat message “memory corruption” itu salah satu faktor pembawa kebahagiaan. Setidaknya nih, walaupun tidak bisa membuat exploit nya tapi bisa trigger memory problem yang mengakibatkan system crash karena memory problem, bisa lah di kasih label embel-embel ‘DOS’, biar kesannya keren gitu.

Nah, ketika sekarang pure di dunia engineering, memory problem tiba-tiba menjadi sesuatu yang selalu menghantui. Baru saja salah satu teknologi yang saya handle di dunia telco masuk ke fase live, sistem mengalami masalah karena salah satu proses nya (sub-process / we called it dispatcher) restart sendiri ketika handle suatu traffic yang ‘unknown’, bahkan salah satu dispatcher ada yang mengalami memory corruption bug sehingga kinerja sistem menjadi terhambat dan tidak bisa memproses traffic.

Jika ini adalah penetration testing dunia security dimana situasi tersebut terjadi akibat dari regression test menggunakan fuzzer, sudah pasti ini adalah kemenangan besar. Client akan bilang ‘wow’, apalagi jika di tamparkan ke muka vendor nya didepan client sehingga mereka beranggapan ‘gile, developer kita yang sudah melakukan regression test saja tidak bisa menemukan bug tersebut namun mereka bisa menemukan, keren juga nih’, tentu tahun depan client akan meminta project pentest lagi hehehe. Tapi klo posisi sebagai engineer, yah, terima sendiri nih tamparan :p.

Yang menarik adalah ketika dalam posisi security profesional (hacker, atau apapun lah sebutan nya), menemukan bug, dan kalaupun berhasil di eksploitasi, kadang kita tidak terlalu peduli dengan bagaimana memperbaiki nya. Oke lah kita bisa trace dan mengatakan hasil akhir bahwa suatu variable perlu di sanitasi, ataupun secara logic perlu diubah, namun dalam dunia engineering terutama developer mereka tidak semudah itu apalagi jika sistem sudah sangat kompleks dimana pengubahan suatu sub-process akan menyebabkan perubahan pada proses lain. Alhasil bug seperti memory corruption membutuhkan waktu cukup lama untuk bisa di perbaiki.

Nah, sebagai engineer yang posisi paling dekat dengan customer, kebetulan saya tidak punya akses langsung ke dunia developer jadi aktivitas yang biasa terjadi adalah menganalisis ketika terjadi suatu masalah (mis: service restarting), dan mencari tau apa penyebabnya. Ketika setelah ditelusuri dengan beragam trik kungfu akhirnya didapatkan bukti bahwa memory corruption maka langsung report ke technical support yang lebih tinggi ataupun developer. Yang menyebalkan adalah kita tidak bisa tahu begitu saja apa penyebab memory corruption, kenapa? karena ini adalah LIVE SYSTEM. Dalam riset security kita bisa saja enable feature trace, sehingga ketika fuzzer hit suatu bug kita bisa analisis hasil trace dan mencari tau root cause nya, tapi jika live system dimana jutaan pengguna handphone operator menjadi taruhan nya, ketika terjadi ya harus langsung ambil langkah jitu sebagai workaround (mis: restart process, restart server) agar sistem bisa kembali seperti semula. Setelah restart? jelas bukti-bukti sub process pernah mengalami memory corruption jadi sangat susah di telusuri kembali. Aplikasi akan melakukan alokasi memory, ketika terjadi leak dan di restart tentu akan me-release alokasi yang sebelumnya dan re-allocate dari awal. Jika sudah begini, memory corruption jadi nightmare terutama ketika customer menanyakan “what is the root cause?”.

Jika biasanya memory corruption adalah mimpi basah, sekarang juga sama-sama basah, tapi basah karena ngeri ditanya apa penyebabnya hehehe…

Note: dengan beralihnya dunia telco ke all-ip seperti sekarang, solusi hampir disetiap bagian adalah IT-based. Dengan mempelajari basic SS7 maka seseorang dapat menggunakan tools seperti scapy untuk membentuk MAP request dan mengirimkan ke mesin-mesin telco di operator (salah satu resource security yang cukup aktif melakukan riset pada dunia telco bisa dilihat dari sini). Dan dengan sedikit fuzzing, saya rasa akan sangat mudah mendapatkan crash dan kondisi DOS.  Well…just sayin :).

Advertisements

3 thoughts on “Kutukan Memory Corruption

  1. mas, apakah bisa di live system tersebut misalnya di analisa cth pk volatile utk memory forensic. Atau misalnya pakai memdump, trus image hsl dump nya di analisa, sehingga tak perlu otak atik di live?

  2. tergantung sistem nya, kadang gak semua live system tersedia beragam tools. biasanya diset minimalis. kalaupun bisa, untuk memdump memory sebesar 36 GB (physical) belum lagi memory swap yang bisa sampe beberapa giga, pastinya butuh waktu cukup lama. sementara failure di live system harus secepatnya diperbaiki saat itu juga.

  3. Beuh brarti ribet juga yah troubleshoot yang gituan. :)) jadi inget dulu pernah jadi kuli di telco.. memang troubleshoot / penanganan masalahnya ribet dan terkesan pake insting daripada baca manual atau cari case study yg sama di google :))

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s