Pengembang sistem operasi seluler AuroraOS (cabang dari sistem operasi Sailfish, dikembangkan oleh perusahaan Open Mobile Platform) berbagi perbaikan untuk kerentanan yang mereka deteksi di memcpy. Penghapusan kerentanan kritis (CVE-2020-6096) di Glibc, yang memanifestasikan dirinya hanya pada platform ARMv7.
Informasi tentang kerentanan terungkap pada bulan Mei, tetapi hingga beberapa hari terakhir, perbaikan tidak tersedia, meskipun kerentanan diberi tingkat bahaya yang tinggi dan ada prototipe eksploit yang berfungsi yang memungkinkan untuk mengatur eksekusi kode.
Eksploitasi disiapkan bertindak selama pemrosesan dalam fungsi memcpy () dan memmove () untuk data berformat tertentu.
Pentingnya Glibc adalah bahwa pustaka ini mendefinisikan panggilan sistem dan fungsi dasar lainnya selain digunakan oleh hampir semua program.
Tentang masalahnya
Kerentanan terwujud dalam implementasi memcpy () dan memmove () dalam bahasa assembly untuk ARMv7 dan itu disebabkan oleh pemrosesan yang tidak benar dari nilai-nilai negatif dari parameter yang menentukan luas area.
Masalah dengan pengembangan tambalan dimulai ketika SUSE dan Red Hat mengumumkan bahwa platform mereka tidak terpengaruh karena masalah ini, karena mereka tidak mengkompilasi untuk sistem ARMv7 32-bit dan tidak berpartisipasi dalam pembuatan tambalan.
Pengembang dari banyak distribusi yang disematkan tampaknya mempercayai tim Glibc, dan juga tidak mengambil bagian aktif dalam menyiapkan tambalan.
solusi
Huawei menawarkan opsi untuk sebuah tambalan untuk segera memblokir masalah, yang mencoba untuk mengganti instruksi assembler yang beroperasi pada operand bertanda (bge dan blt) dengan analog unsigned (blo dan bhs).
Pemelihara Glibc mengembangkan rangkaian pengujian untuk menguji kondisi yang berbeda untuk terjadinya kesalahan, setelahnya yang ternyata patch Huawei tidak sesuai dan tidak memproses semua kemungkinan kombinasi data masukan.
Sejak AuroraOS memiliki build 32-bit untuk ARM, yang pengembang memutuskan untuk menutup kerentanan mereka sendiri dan mengusulkan solusi kepada komunitas.
Kesulitannya adalah, perlu dituliskan implementasi yang efektif assembler fungsi dan mempertimbangkan beberapa opsi untuk argumen input.
Implementasinya telah ditulis ulang menggunakan instruksi yang tidak ditandatangani. Tambalan tersebut ternyata kecil, tetapi masalah utamanya adalah mempertahankan kecepatan eksekusi dan menghapus penurunan kinerja dari fungsi memcpy dan memmove, sambil mempertahankan kompatibilitas dengan semua kombinasi nilai masukan.
Di awal Juni, dua solusi disiapkan, lulus kerangka uji pemeliharaan Glibc dan rangkaian pengujian internal Aurora. Pada 3 Juni, salah satu opsi dipilih dan diserahkan ke milis Glibc.
Seminggu kemudian, pendekatan serupa lainnya diusulkan, yang memperbaiki masalah dalam implementasi multiarch, yang sebelumnya coba diperbaiki Huawei. Sebulan mengambil pengujian dan legalisasi mengingat pentingnya tambalan.
Pada 8 Juli, perbaikan diterima di cabang utama dari rilis glibc 2.32 mendatang. Aplikasi ini mencakup dua tambalan:
- Yang pertama untuk aplikasi Multiarch pembentukan memori untuk ARMv7
- Yang kedua untuk implementasi assembler umum dari memcpy () dan memmove () untuk ARM.
Masalahnya memengaruhi jutaan perangkat ARMv7 Linux dan tanpa pembaruan yang tepat, pemilik berisiko menghubungkan mereka ke jaringan (layanan dan aplikasi yang tersedia di jaringan yang menerima input tanpa batasan ukuran dapat diserang).
Misalnya, eksploitasi yang disiapkan oleh peneliti yang menemukan kerentanan menunjukkan bagaimana menyerang server http terintegrasi ke dalam sistem informasi mobil dengan mengirimkan permintaan GET yang sangat besar dan mendapatkan akses root ke sistem.
Solusi paket untuk Debian dan Ubuntu belum dirilis y kerentanan tetap tidak diperbaiki selama hampir dua bulan sejak pengungkapan publik dan lima bulan sejak pengembang Glibc diberitahukan.