Catatan perev. : Tadi malam, Aleksa Sarai, seorang insinyur kontainer senior di SUSE Linux, mengatakan kepada milis oss-sec tentang kerentanan keamanan runc / LXC kritis yang dapat memungkinkan penyerang dengan akses ke wadah terisolasi untuk mendapatkan hak akses root pada sistem host. Karena masalah itu diidentifikasi dalam implementasi referensi runtime kontainer - runc - itu mempengaruhi banyak sistem kontainer termasuk Docker / Moby, Podman , cri-o (dan Kubernetes sendiri). Detailnya disajikan di bawah ini dalam bentuk menterjemahkan pesan insinyur ke milis.Saya adalah salah satu pengelola runc (runtime kontainer yang mendasarinya digunakan oleh Docker, cri-o, containerd, Kubernetes, dll.). Baru-baru ini diketahui tentang kerentanan yang kami periksa dan tambal.
Peneliti yang menemukan kerentanan:
- Adam Iwaniuk;
- Borys PopΕawski.
Selain itu, Aleksa Sarai (yaitu, saya) menemukan bahwa LXC juga dipengaruhi oleh versi yang lebih canggih dari kerentanan ini.
Ulasan singkat
Kerentanan memungkinkan wadah jahat (dengan interaksi pengguna minimal) untuk menimpa runc host binary dan dengan demikian dapat mengeksekusi kode dengan hak akses root pada host. Tingkat interaksi pengguna sedemikian rupa sehingga memungkinkan Anda untuk menjalankan perintah apa pun (tidak masalah jika penyerang mengontrol perintah) dengan hak akses root di dalam wadah dalam konteks berikut:
- Membuat wadah baru dari gambar yang dikendalikan oleh penyerang;
- Koneksi (
docker exec ) ke wadah yang sudah ada dimana penyerang sebelumnya memiliki akses tulis.
Kerentanan ini
tidak diblokir oleh kebijakan AppArmor default atau kebijakan standar SELinux di Fedora * (karena proses wadah terlihat seperti mereka mulai dengan
container_runtime_t ). Namun, itu
diblokir oleh penggunaan ruang nama pengguna yang benar (di mana akar host tidak memetakan ke ruang nama pengguna wadah).
Vektor CVSSv3 (dengan peringkat 7.2) adalah sebagai berikut:
AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:HMasalah ini diberikan pada
CVE-2019-5736 .
* Masalahnya hanya berlaku untuk paket moby-engine di Fedora. Paket docker , seperti podman , dilindungi dari operasinya, karena mulai proses container_t sebagai container_t .Tambalan
Saya menerapkan patch yang sesuai untuk memperbaiki masalah (
0001-nsenter-clone-proc-self-exe-to-avoid-exposing-host-b.patch ). Ini didasarkan pada cabang
HEAD , meskipun kode di
libcontainer/nsenter/ perubahan sangat jarang sehingga tambalan kemungkinan besar berlaku untuk hampir semua versi lama dari basis kode runc yang Anda hadapi.
Harap dicatat bahwa
tambalan yang saya dorong ke cabang master runc adalah versi modifikasi dari tambalan ini, meskipun mereka secara fungsional identik (jika Anda belum menambal file Anda dengan tambalan yang dilampirkan, sebaiknya gunakan versi upstream).
Kode Eksploitasi Sekunder
Beberapa vendor meminta kode exploit untuk memastikan tambalan menyelesaikan masalah. Karena masalahnya sangat serius (terutama untuk vendor cloud publik), kami memutuskan untuk memberikan kode seperti itu. Eksploitasi yang saya tulis lebih umum daripada kode asli yang disediakan oleh para peneliti dan bekerja untuk LXC (tidak memerlukan modifikasi yang kuat untuk dapat diterapkan ke lingkungan rentan yang dapat dieksekusi lainnya). Rincian tentang cara menggunakan kode eksploitasi disediakan di
README .
Sesuai dengan aturan OpenWall, kode exploit akan dirilis
secara publik 7 hari setelah CRD (mis., 18 Februari 2019).
Jika Anda memiliki runtime kontainer, pastikan tidak terpengaruh oleh kerentanan ini.Dampak pada proyek lain
Perlu dicatat bahwa selama penyelidikan lebih lanjut dari masalah, saya menemukan bahwa LXC memiliki kerentanan yang sama, dan mereka sudah mendorong
patch serupa
dari pengembangan bersama kami. LXC sedikit lebih sulit untuk dioperasikan, tetapi masalahnya sendiri sama.
Sebuah diskusi dengan perwakilan systemd-nspawn mengarah pada kesimpulan bahwa mereka tidak rentan (karena mereka memiliki metode berbeda dalam menghubungkan ke wadah untuk LXC dan runc).
Perwakilan dari Apache Mesos juga menghubungi saya, melaporkan bahwa mereka juga rentan (saya pikir mereka hanya menggunakan kode exploit yang akan dipublikasikan). Sangat mungkin sebagian besar runtime kontainer rentan jika mereka sebelumnya tidak mengambil langkah yang sangat tidak biasa untuk mengurangi dampak potensial mereka.
Berita lainnya
Kami telah mengonfigurasi distribusi pengumuman untuk kerentanan keamanan di masa mendatang: proses bergabungnya dijelaskan di
sini (didasarkan pada milis Kubernetes yang mengumumkan keamanan). Silakan bergabung jika Anda mendistribusikan runtime untuk wadah yang bergantung pada runc (atau proyek OCI lainnya).
PS Dari penerjemah
Masalah CVE-2019-5736 dalam pelacak distribusi Linux populer:
... dan
posting blog Kubernetes (lihat bagian βApa yang Harus Saya Lakukan?β).