Memperbaiki kerentanan tidak langsung adalah salah satu tugas yang kompleks, membosankan, dan, sejujurnya, membosankan yang tidak ingin disentuh oleh siapa pun. Tidak ada seorang pun kecuali Dihancurkan, kelihatannya. Tentu, ada banyak cara untuk melakukannya secara manual, tetapi dapatkah itu dilakukan secara otomatis dengan risiko kerusakan minimal? Tim Debricks memutuskan untuk mencari tahu.
Hutan yang penuh dengan pohon rapuh
Jadi, di mana Anda bahkan mulai?
Pertama, perlu ada cara untuk memperbaiki kerentanan, yang, untuk ketergantungan tidak langsung, tidak ada jalan di taman. Kedua, itu perlu dilakukan dengan cara yang aman, atau, tanpa ada yang melanggar.
Anda lihat, dependensi tidak langsung diperkenalkan jauh di dalam pohon dependensi dan sangat sulit untuk mendapatkan versi persis yang Anda inginkan. Seperti yang pernah dikatakan oleh Kepala Litbang Debricks, “Anda memutar kenop dengan bermain-main dengan dependensi langsung Anda dan berdoa kepada Torvalds bahwa paket tidak langsung yang benar telah diselesaikan. Ketika Torvalds menguntungkan Anda, Anda harus mengorbankan beberapa penyimpanan cloud kepada paman Bob untuk memastikan pembaruan tidak merusak aplikasi Anda.”
Dengan kata lain, seharusnya ada cara yang lebih mudah dan tidak membuat stres untuk melakukannya.
Dalam artikel ini, kami akan memandu Anda melalui bagaimana memecahkan kerentanan transitif dapat dilakukan secara manual dan, menjelang akhir, menunjukkan solusi Debricks, yang memungkinkan Anda melakukannya secara otomatis. Jika Anda benar-benar hanya tertarik dengan solusinya, saya sarankan Anda mulai menggulir.
Operasi presisi pada pohon ketergantungan Anda
Selama fase penelitian proyek basis data grafik, atau, bagaimana Debricked hari ini memperbaiki kerentanan open source Anda dengan kecepatan cahaya, tim menemukan beberapa artikel yang menjelaskan cara memperbaiki kerentanan tidak langsung di NPM.
Seperti yang disebutkan dalam artikel tersebut, paket `minimist` dipengaruhi oleh kerentanan, yaitu CVE-2021-44906 dan CVE-2020-7598.
Keduanya merupakan kerentanan “Pencemaran Prototipe”, yang berarti bahwa argumen tidak dibersihkan dengan benar. Untungnya, pengelola `minimist` memperbaiki kerentanan ini di versi 1.2.6.
Sayangnya, `mocha` versi 7.1.0 menyelesaikan `minimist` 0.0.8, yang berada dalam kisaran rentan dari kerentanan ini. Seperti yang disarankan oleh penulis artikel ini, kerentanan ini dapat diperbaiki dengan beberapa cara berbeda.
Tetapi! Bagaimana dengan melanggar perubahan?
Saran pertama adalah cukup memicu pembaruan semua “dependensi tidak langsung”, yang berarti bahwa kita tidak akan benar-benar mengubah versi `mocha`. Untuk melakukan pembaruan ini, cukup jalankan `npm update`, hapus file `npm.lock` Anda, dan jalankan `npm install`. Ini membuat ulang pohon dependensi dengan versi terbaru yang memungkinkan (sesuai dengan batasan) dari dependensi tidak langsung Anda. Dengan metode ini, risiko melanggar perubahan sangat rendah karena Anda sebenarnya tidak memperbarui dependensi root Anda, hanya dependensi tidak langsung Anda.
Perubahan pemutusan terjadi ketika fungsionalitas atau antarmuka paket tidak kompatibel dengan penerusan, yang berarti bahwa pembaruan pada paket dapat menyebabkan aplikasi Anda rusak. Perubahan pemutusan umum adalah penghapusan kelas/fungsi, perubahan argumen ke fungsi, atau perubahan lisensi (hati-hati dengan yang itu!).
Tetapi hidup tidak selalu semudah ini, dan pembaruan sederhana dari pohon ini tidak akan menyelesaikan kerentanan. Masalahnya adalah `mkdirp` sebenarnya telah mengunci versi `minimist` mereka ke 0.0.8. Ini berarti bahwa kontributor `mkdirp` telah sampai pada kesimpulan bahwa mereka tidak kompatibel dengan versi `minimist` yang lebih baru, dan memaksa pembaruan `minimist` dapat menyebabkan perubahan terputus antara `mkdirp` dan `minimist`.
Pikirkan … grafik!
Jadi, pertanyaan jutaan dolar adalah: versi `mocha` apa yang harus digunakan, yang pada gilirannya mengalir ke versi `minimist` yang aman tanpa merusak pohon ketergantungan? Ini sebenarnya adalah masalah grafik, yang telah dijelaskan dalam artikel ini.
Algoritma grafik apa yang akan menyelesaikan masalah ini? Bagaimana NPM menyelesaikan dependensi bisa sedikit rumit, karena mereka diizinkan untuk “membagi” pohon dependensi. Ini berarti bahwa mereka dapat memiliki beberapa versi dari satu ketergantungan untuk memastikan bahwa kita selalu memiliki pohon yang kompatibel. Untuk mengatasi kerentanan, kita perlu memastikan bahwa semua instance `minimist` aman dengan memperbarui semua root yang dapat menetes ke `minimist`.
Algoritma yang digunakan untuk memecahkan masalah ini disebut “All Max Paths Safe”. Dengan menelusuri grafik ketergantungan dan mempertahankan versi maksimal, sambil memangkas semua versi lain dari paket itu di setiap persimpangan, kita dapat membuat representasi perkiraan pohon ketergantungan kita. Jika perkiraannya aman, itu berarti pohon asli kita juga akan aman!
Dengan menjalankan algoritme ini untuk semua versi potensial `mocha`, kami menemukan peningkatan terkecil untuk memperbaiki kerentanan ini. Untuk mendapatkan kecepatan yang kami inginkan untuk algoritme ini, tim harus membuat prosedur Neo4j kustom, yang dapat menangani pencarian lebih dari 100 versi root dengan kedalaman pencarian 30+ dalam ~150 milidetik. Cepat, ya?
Dalam hal ini, kita tidak perlu mencari terlalu jauh… karena 7.1.1 dari `mocha` aman! Ini hanya pembaruan tambalan, yang menunjukkan bahwa risiko melanggar perubahan sangat rendah. Untuk kasus yang tidak terlalu rumit (seperti contoh ini), ‘npm audit’ dapat membantu Anda dengan perintah ‘npm audit fix’ yang fantastis.
Jangan ad-hoc, masuki cara kerja pub-sub-manusia!
Sekarang, jika Anda sampai sejauh ini (selamat, sangat mengesankan) dan berpikir, “ini terdengar sangat rumit dan seperti banyak pekerjaan,” jangan khawatir – Anda bukan satu-satunya. Untungnya, semua ini terjadi sepenuhnya secara otomatis di alat Debricks saat mengklik tombol kecil ini:
Sampai sekarang, ini tersedia untuk Javascript. Segera, dukungan akan diperluas ke Java, Golang, C#, Python dan PHP.
Jika Anda belum menjadi pengguna Debricks, tunggu apa lagi? Ini gratis untuk pengembang tunggal, tim yang lebih kecil, dan proyek sumber terbuka (dan jika Anda adalah organisasi yang lebih besar, jangan takut. Ada uji coba gratis yang murah hati). Daftar gratis di sini.