Kisah saat tersandung kerentanan weak keys Debian

Kisah saat terkena kerentanan weak keys Debian

• Pada Maret 2008, penulis bekerja di Engine Yard (EY)
• Saat itu EY membantu GitHub dengan menyediakan infrastruktur gratis
• Seiring GitHub bertumbuh, muncul masalah waktu login SSH yang menjadi lambat
• GitHub mengelola kunci SSH dengan menggunakan file ~/.ssh/authorized_keys, cara standar yang umum dipakai
• Saat pengguna terhubung, SSH membuka file ini dan melakukan pencarian linear untuk menemukan kunci yang cocok dengan kunci yang diajukan pengguna
• Biasanya ini tidak menjadi masalah karena jumlah kunci hanya sedikit, tetapi menjadi lambat ketika pengguna sangat banyak seperti di GitHub

Memutuskan memakai DB MySQL alih-alih file authorized_keys

• Setelah meninjau berbagai alternatif, diputuskan untuk mem-patch OpenSSH agar pencarian kunci dilakukan melalui DB MySQL
• Ini adalah keputusan yang diambil dengan hati-hati, dan banyak upaya dilakukan agar keamanan tidak terganggu
• Diterapkan pada awal April 2008 dan berhasil menyelesaikan masalah kecepatan login SSH

Hal aneh terjadi

• Sebulan kemudian, pada awal Mei, muncul masalah di mana sebagian pengguna bisa mengakses repositori pengguna lain lewat SSH
• Hasil penyelidikan menunjukkan bahwa pengguna yang berbeda memakai kunci dengan fingerprint yang sama
• Hal seperti ini tidak mungkin terjadi kecuali mereka berbagi kunci
• Para pengguna mengatakan mereka tidak saling mengenal dan tidak tahu bagaimana kunci itu bisa bocor
• Masalah yang sama juga ditemukan pada pasangan pengguna lain
• Satu-satunya kesamaan adalah semuanya menggunakan sistem Debian atau Ubuntu

Menemukan penyebabnya

• Pada 13 Mei 2008, semuanya menjadi jelas setelah DSA-1571-1 dipublikasikan
• Seorang maintainer Debian, saat merapikan kode pembangkitan bilangan acak di OpenSSL, secara keliru mengurangi jumlah kemungkinan kunci menjadi sekitar 32.000
• Banyak orang mendaftar ke GitHub dan, mengikuti praktik terbaik, membuat kunci baru, sehingga benturan pun terjadi
• Setelah itu, penulis semakin banyak terlibat dengan masalah ini, termasuk menggunakan kumpulan weak keys yang sudah diketahui untuk menemukan otoritas sertifikat yang bermasalah

Opini GN⁺

• Untuk menemukan kerentanan sepenting ini, dibutuhkan waktu dan energi untuk berpikir “ada yang aneh” lalu menyelidikinya dengan gigih. Biasanya orang tidak punya kelonggaran seperti itu, jadi perlu sedikit keberuntungan.
• Kebanyakan orang dikejar kesibukan sehari-hari sehingga sulit menggali sampai ke akar penyebab masalah. Mengembalikan ruang seperti ini ke industri kita adalah pekerjaan rumah yang penting.
• OpenSSL adalah salah satu library kriptografi yang paling luas digunakan, jadi dampak kerentanan seperti ini sangat besar. Di sini terlihat jelas sisi kuat sekaligus sisi lemah open source.
• Untuk mencegah kerentanan seperti ini, code review dan audit keamanan perlu diperkuat, dan perubahan pada bagian penting harus ditinjau dengan lebih hati-hati. Namun tidak ada metode yang sempurna.
• Meski begitu, open source tetap punya kelebihan karena para ahli bisa langsung menelaah kodenya dan menemukan masalah. Pada program tertutup, bahkan itu pun tidak mungkin dilakukan.

[GN⁺]

Komentar Hacker News

• Luciano Bello secara kebetulan menemukan kerentanan CVE-2008-0166, dan menurut log IRC saat itu diperlukan banyak bilangan prima kecil serta tidak selalu menghasilkan angka yang sama setiap kali
• Secara keseluruhan industri tampaknya cukup beruntung, karena ada seseorang yang memiliki keahlian, waktu, dan energi untuk membuat perbedaan besar pada saat yang tepat. Ini terasa seperti contoh nyata dari statistik "banyak mata" dan "sinar matahari adalah disinfektan". Sekecil apa pun peluang seseorang menemukan bug secara kebetulan, orang-orang memang bisa menemukannya. Sebaliknya, pada kode proprietari/tertutup peluang itu adalah 0
• Perubahan yang menyebabkan kerentanan ini bukanlah sesuatu yang dilakukan terburu-buru. Seorang maintainer mengangkat masalah itu di milis OpenSSL, meminta umpan balik, dan mengusulkan solusi, serta menerima sejumlah masukan termasuk dari upstream. Hasilnya adalah kerentanan yang mengerikan, tetapi ini tampak seperti kasus yang sangat sial karena tak seorang pun menyadari masalahnya
• GitHub menyimpulkan bahwa opsi terbaik adalah menambal OpenSSH agar dapat mengambil kunci yang diindeks berdasarkan sidik jari kunci dari basis data MySQL. Tampaknya MySQL dipilih alih-alih SQLite karena ini memang jenis situasi di mana MySQL bisa menonjol, saat mereka berusaha mempercepat akses ke ~/.ssh/authorized_keys
• Ini membuat orang berpikir tentang kemungkinan hal seperti ini terjadi pada fungsi pembangkitan seed di dompet perangkat keras Bitcoin yang populer, serta dampaknya
• Mendeteksi kunci RSA yang memiliki faktor p atau q bersama dengan menggunakan GCD juga merupakan episode yang menarik
• Terlihat bahwa waktu login SSH yang lambat adalah petunjuk yang layak ditarik untuk berbagai alasan
• OpenSSL RNG di-seed dengan memori stack yang belum diinisialisasi dan PID, dan bahkan tanpa patch Debian pun, melakukan seed hanya dengan PID tampaknya sudah cukup berbahaya
• Penasaran apakah GitHub masih menjalankan OpenSSH yang sudah ditambal
• Kalimat bahwa Ezra Zygmuntowicz memperkenalkan GitHub kepada penulis dan memberinya waktu untuk menggali masalah bersama tim GitHub terasa lucu. Mungkin karena itu terbaca seolah-olah ada masalah besar pada tim GitHub sendiri
• Andai Luciano tidak menemukannya, muncul pertanyaan berapa lama lagi hal itu akan tetap tak terdeteksi. Kemungkinan hanya segelintir tempat seperti GitHub atau penyedia cloud besar yang menyimpan ribuan kunci pengguna yang akan menemukannya secara kebetulan