Beberapa konteks tentang bug:CVE-2014-6271
Bash mendukung ekspor tidak hanya variabel shell, tetapi juga fungsi shell
ke instance bash lainnya, melalui lingkungan proses ke
proses anak (tidak langsung). Versi bash saat ini menggunakan variabel
lingkungan yang dinamai dengan nama fungsi, dan definisi fungsi
dimulai dengan “() {” dalam nilai variabel untuk menyebarkan definisi fungsi
melalui lingkungan. Kerentanan terjadi karena
bash tidak berhenti setelah memproses definisi fungsi; itu
terus mengurai dan menjalankan perintah shell mengikuti definisi fungsi
. Misalnya, pengaturan variabel lingkunganVAR=() { ignored; }; /bin/idakan mengeksekusi /bin/id ketika lingkungan diimpor ke dalam proses bash
.
Sumber:http://seclists.org/oss-sec/2014/q3/650
Kapan bug tersebut diperkenalkan, dan patch apa yang memperbaikinya sepenuhnya? (Lihat CVE-2014-7169)
Apa saja versi rentan di luar yang disebutkan dalam CVE (awalnya) (3.{0..2} dan 4.{0..3})?
Apakah kode sumber kereta telah digunakan kembali di proyek lain?
Informasi tambahan diperlukan.
Terkait:Apa artinya env x='() { :;}; command' bash do dan mengapa tidak aman?
Jawaban yang Diterima:
TL;DR
Kerentanan shellshock sepenuhnya diperbaiki di
- Di cabang bash-2.05b:2.05b.10 ke atas (termasuk patch 10)
- Di cabang bash-3.0:3.0.19 ke atas (termasuk patch 19)
- Di cabang bash-3.1:3.1.20 ke atas (termasuk patch 20)
- Di cabang bash-3.2:3.2.54 ke atas (termasuk patch 54)
- Di cabang bash-4.0:4.0.41 ke atas (termasuk patch 41)
- Di cabang bash-4.1:4.1.14 ke atas (termasuk patch 14)
- Di cabang bash-4.2:4.2.50 ke atas (termasuk patch 50)
- Di cabang bash-4.3:4.3.27 ke atas (termasuk patch 27)
Jika bash Anda menampilkan versi yang lebih lama, vendor OS Anda mungkin masih menambalnya sendiri, jadi sebaiknya periksa.
Jika:
env xx='() { echo vulnerable; }' bash -c xx
menunjukkan "rentan", Anda masih rentan. Itulah satu-satunya tes yang relevan (apakah parser bash masih terbuka ke kode di apa saja variabel lingkungan).
Detail.
Bug tersebut merupakan implementasi awal dari fungsi ekspor/impor yang diperkenalkan pada 5 Agustus 1989 oleh Brian Fox, dan pertama kali dirilis di bash-1.03 sekitar sebulan kemudian pada saat bash tidak digunakan secara luas, sebelum keamanan begitu banyak perhatian dan HTTP dan web atau Linux bahkan ada.
Dari ChangeLog di 1.05:
Fri Sep 1 18:52:08 1989 Brian Fox (bfox at aurel) * readline.c: rl_insert (). Optimized for large amounts of typeahead. Insert all insertable characters at once. * I update this too irregularly. Released 1.03. [...] Sat Aug 5 08:32:05 1989 Brian Fox (bfox at aurel) * variables.c: make_var_array (), initialize_shell_variables () Added exporting of functions.
Beberapa diskusi di gnu.bash.bug dan comp.unix.questions sekitar waktu itu juga menyebutkan fitur tersebut.
Sangat mudah untuk memahami bagaimana hal itu terjadi.
bash mengekspor fungsi dalam env vars seperti
foo=() {
code
}
Dan saat impor, yang harus dilakukan adalah menafsirkannya dengan = diganti dengan spasi… kecuali bahwa ia tidak boleh menafsirkannya secara membabi buta.
Itu juga rusak di bash (berlawanan dengan kulit Bourne), variabel skalar dan fungsi memiliki ruang nama yang berbeda. Sebenarnya jika Anda memiliki
foo() { echo bar; }; export -f foo
export foo=bar
bash akan dengan senang hati menempatkan keduanya di lingkungan (ya entri dengan nama variabel yang sama) tetapi banyak alat (termasuk banyak shell) tidak akan menyebarkannya.
Orang juga akan berpendapat bahwa bash harus menggunakan BASH_ awalan namespace untuk itu karena env vars hanya relevan dari bash ke bash. rc menggunakan fn_ awalan untuk fitur serupa.
Cara yang lebih baik untuk mengimplementasikannya adalah dengan meletakkan definisi semua variabel yang diekspor ke dalam variabel seperti:
BASH_FUNCDEFS='f1() { echo foo;}
f2() { echo bar;}...'
Itu masih perlu dibersihkan tetapi setidaknya itu tidak bisa lebih dieksploitasi daripada $BASH_ENV atau $SHELLOPTS …
Ada tambalan yang mencegah bash dari menafsirkan apa pun selain definisi fungsi di sana (https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081.html), dan itulah yang telah diterapkan di semua keamanan pembaruan dari berbagai distribusi Linux.
Namun, bash masih menafsirkan kode di sana dan bug apa pun di penerjemah dapat dieksploitasi. Salah satu bug tersebut telah ditemukan (CVE-2014-7169) meskipun dampaknya jauh lebih kecil. Jadi akan ada patch lain segera hadir.
Hingga perbaikan pengerasan yang mencegah bash untuk menafsirkan kode dalam variabel apa pun (seperti menggunakan BASH_FUNCDEFS pendekatan di atas), kami tidak akan tahu pasti apakah kami tidak rentan dari bug di parser bash. Dan saya yakin akan ada perbaikan pengerasan yang dirilis cepat atau lambat.
Edit 28-09-2014
Dua bug tambahan di parser telah ditemukan (CVE-2014-718{6,7}) (perhatikan bahwa sebagian besar shell pasti memiliki bug di parser mereka untuk kasus sudut, itu tidak akan menjadi masalah jika parser itu tidak 'tidak terkena data yang tidak dipercaya).
Sementara semua 3 bug 7169, 7186 dan 7187 telah diperbaiki di patch berikut, Red Hat mendorong untuk perbaikan hardening. Di patch mereka, mereka mengubah perilaku sehingga fungsi diekspor dalam variabel yang disebut BASH_FUNC_myfunc() kurang lebih mendahului keputusan desain Chet.
Chet kemudian menerbitkan perbaikan itu sebagai tambalan bash upstreams resmi.
Patch pengerasan itu, atau variannya sekarang tersedia untuk sebagian besar distribusi Linux utama dan akhirnya berhasil masuk ke Apple OS/X.
Itu sekarang menambah kekhawatiran untuk setiap env var sewenang-wenang yang mengeksploitasi parser melalui vektor itu termasuk dua kerentanan lain di parser (CVE-2014-627{7,8}) yang diungkapkan kemudian oleh Michał Zalewski (CVE-2014-6278 menjadi hampir seburuk CVE-2014-6271) untungnya setelah kebanyakan orang punya waktu untuk menginstal patch pengerasan
Bug di pengurai juga akan diperbaiki, tetapi sekarang tidak lagi menjadi masalah karena pengurai tidak lagi mudah terpapar masukan yang tidak tepercaya.
Perhatikan bahwa meskipun kerentanan keamanan telah diperbaiki, kemungkinan kita akan melihat beberapa perubahan di area itu. Perbaikan awal untuk CVE-2014-6271 telah merusak kompatibilitas mundur karena berhenti mengimpor fungsi dengan . atau : atau / atas nama mereka. Itu masih dapat dideklarasikan oleh bash yang membuat perilaku tidak konsisten. Karena berfungsi dengan . dan : dalam nama mereka biasanya digunakan, kemungkinan tambalan akan memulihkan menerima setidaknya yang dari lingkungan.
Mengapa tidak ditemukan sebelumnya?
Itu juga sesuatu yang saya herankan. Saya dapat memberikan beberapa penjelasan.
Pertama, saya pikir jika peneliti keamanan (dan saya bukan peneliti keamanan profesional) secara khusus mencari kerentanan di bash, mereka kemungkinan besar akan menemukannya.
Misalnya, jika saya seorang peneliti keamanan, pendekatan saya dapat berupa:
- Lihat di mana
bashmendapat masukan dari dan apa yang dilakukannya dengannya. Dan lingkungannya sangat jelas. - Lihat di tempat mana
bashinterpreter dipanggil dan pada data apa. Sekali lagi, itu akan menonjol. - Pengimporan fungsi yang diekspor adalah salah satu fitur yang dinonaktifkan saat
bashadalah setuid/setgid, yang menjadikannya tempat yang lebih jelas untuk dilihat.
Sekarang, saya curiga tidak ada yang berpikir untuk mempertimbangkan bash (penerjemah) sebagai ancaman, atau bahwa ancaman itu bisa saja terjadi.
bash juru bahasa tidak dimaksudkan untuk memproses masukan yang tidak dipercaya.
Shell skrip (bukan penerjemah) sering dilihat dari sudut pandang keamanan. Sintaks shell sangat canggung dan ada begitu banyak peringatan dengan penulisan skrip yang andal (pernah melihat saya atau orang lain menyebutkan operator split+glob atau mengapa Anda harus mengutip variabel misalnya?) sehingga cukup umum untuk menemukan kerentanan keamanan dalam skrip yang memproses data tidak tepercaya.
Itulah mengapa Anda sering mendengar bahwa Anda tidak boleh menulis skrip shell CGI, atau skrip setuid dinonaktifkan di sebagian besar Unices. Atau Anda harus ekstra hati-hati saat memproses file di direktori yang dapat ditulisi dunia (misalnya, lihat CVE-2011-0441).
Fokusnya adalah pada skrip shell, bukan penerjemah.
Anda dapat mengekspos penerjemah shell ke data yang tidak tepercaya (memberi makan data asing sebagai kode shell untuk ditafsirkan) melalui eval atau . atau memanggilnya pada file yang disediakan pengguna, tetapi Anda tidak memerlukan kerentanan di bash untuk mengeksploitasinya. Cukup jelas bahwa jika Anda meneruskan data yang tidak bersih untuk diinterpretasikan oleh shell, shell akan menginterpretasikannya.
Jadi Shell dipanggil dalam konteks tepercaya. Itu diberikan skrip tetap untuk ditafsirkan dan lebih sering daripada tidak (karena sangat sulit untuk menulis skrip yang andal) data tetap untuk diproses.
Misalnya, dalam konteks web, shell mungkin dipanggil dalam sesuatu seperti:
popen("sendmail -oi -t", "w");
Apa yang mungkin salah dengan itu? Jika ada yang salah, itu tentang data yang diumpankan ke sendmail itu, bukan bagaimana baris perintah shell itu sendiri diuraikan atau data tambahan apa yang diumpankan ke shell itu. Tidak ada alasan Anda ingin mempertimbangkan variabel lingkungan yang diteruskan ke shell itu. Dan jika Anda melakukannya, Anda menyadari itu semua env vars yang namanya dimulai dengan "HTTP_" atau CGI env vars yang terkenal seperti SERVER_PROTOCOL atau QUERYSTRING tidak ada yang berhubungan dengan shell atau sendmail.
Dalam konteks elevasi hak istimewa seperti ketika menjalankan setuid/setgid atau melalui sudo, lingkungan umumnya dipertimbangkan dan ada banyak kerentanan di masa lalu, sekali lagi tidak terhadap shell itu sendiri tetapi terhadap hal-hal yang meningkatkan hak istimewa seperti sudo (lihat misalnya CVE-2011-3628).
Misalnya, bash tidak mempercayai lingkungan saat setuid atau dipanggil oleh perintah setuid (pikirkan mount misalnya yang memanggil pembantu). Secara khusus, ini mengabaikan fungsi yang diekspor.
sudo tidak membersihkan lingkungan:semua secara default kecuali untuk daftar putih, dan jika dikonfigurasi tidak, setidaknya daftar hitam beberapa yang diketahui mempengaruhi shell atau lainnya (seperti PS4 , BASH_ENV , SHELLOPTS …). Itu juga membuat daftar hitam variabel lingkungan yang kontennya dimulai dengan () (itulah sebabnya CVE-2014-6271 tidak mengizinkan eskalasi hak istimewa melalui sudo ).
Tetapi sekali lagi, itu untuk konteks di mana lingkungan tidak dapat dipercaya:variabel apa pun dengan nama dan nilai apa pun dapat disetel oleh pengguna jahat dalam konteks itu. Itu tidak berlaku untuk server web/ssh atau semua vektor yang mengeksploitasi CVE-2014-6271 di mana lingkungan dikendalikan (setidaknya nama variabel lingkungan dikendalikan…)
Sangat penting untuk memblokir variabel seperti echo="() { evil; }" , tapi bukan HTTP_FOO="() { evil; }" , karena HTTP_FOO tidak akan dipanggil sebagai perintah oleh skrip shell atau baris perintah apa pun. Dan apache2 tidak akan pernah menyetel echo atau BASH_ENV variabel.
Cukup jelas beberapa variabel lingkungan harus dimasukkan dalam daftar hitam dalam beberapa konteks berdasarkan nama mereka , tetapi tidak ada yang berpikir bahwa mereka harus dimasukkan dalam daftar hitam berdasarkan konten their (kecuali untuk sudo ). Atau dengan kata lain, tidak ada yang mengira bahwa env vars arbitrer bisa menjadi vektor untuk injeksi kode.
Mengenai apakah pengujian ekstensif saat fitur ditambahkan dapat menangkapnya, menurut saya itu tidak mungkin.
Saat Anda menguji fitur , Anda menguji fungsionalitas. Fungsionalitas bekerja dengan baik. Jika Anda mengekspor fungsi dalam satu bash doa, itu diimpor dengan baik di tempat lain. Pengujian yang sangat menyeluruh dapat menemukan masalah saat variabel dan fungsi dengan nama yang sama diekspor atau saat fungsi tersebut diimpor di lokal yang berbeda dari yang diekspor.
Tetapi untuk dapat menemukan kerentanannya, ini bukan tes fungsionalitas yang harus Anda lakukan. Aspek keamanan harus menjadi fokus utama, dan Anda tidak akan menguji fungsionalitasnya, tetapi mekanisme dan bagaimana hal itu dapat disalahgunakan.
Ini bukanlah sesuatu yang sering dipikirkan oleh para pengembang (terutama pada tahun 1989), dan pengembang shell dapat dimaafkan karena menganggap perangkat lunaknya tidak mungkin dapat dieksploitasi jaringan.