Bagaimana cara menambal kerentanan shellshock pada sistem Ubuntu yang sudah usang yang tidak dapat saya tingkatkan?


22

Saya memiliki sistem yang saya kelola dari jarak jauh (2 zona waktu) yang menjalankan Ubuntu 9.04, ceria. Karena berbagai alasan, terutama karena saya benar-benar ragu untuk mencoba melakukan peningkatan distribusi dari jauh, saya tidak dapat meningkatkannya ke versi yang lebih baru. Jelas itu tidak lagi didukung dan tidak ada tambalan resmi. Apakah ada instruksi yang tersedia tentang bagaimana saya bisa menambal kode dan mengkompilasi ulang bash sendiri untuk menghapus kerentanan shellshock?


5
Penelitian apa yang telah Anda lakukan tentang hal ini? Solusi paling sederhana adalah membangun kembali dan menambalnya sendiri. Anda mungkin harus menerima ini hanya waktu untuk memperbarui server.
Ramhound

Ya, itu pilihan mundur saya. Server sedang dalam perjalanan keluar, saya hanya mencoba untuk tetap pincang sampai dana masuk untuk penggantinya. Jika saya ada di tempat, saya akan menggigit peluru dan melakukan pembaruan, tetapi saya sangat jarang melakukannya tanpa hambatan, dan tanpa dapat menanganinya saya lebih suka tidak mengambil risiko bahwa jika saya tidak memiliki untuk.
Claus

Hanya mendapatkan beberapa kata kunci pada halaman sehingga orang dapat menemukan ini. Juga bekerja untuk saya di Mac, OS X, Mavericks berdasarkan tes yang dipublikasikan di arstechnica.com/security/2014/09/…

1
biarkan terbuka, "tertatih-tatih" akan cepat berubah. Sangat jelas, Anda menggunakan distro yang keluar lima tahun lalu . Dukungan berakhir pada Oktober 2010. Anda memiliki lebih banyak kerentanan untuk dikhawatirkan.
tedder42

Jawaban:


29

Mencuri ini dari AskUbuntu , dari seseorang yang mencurinya dari Hacker News. Bekerja pada dua server lama untuk saya

mkdir src
cd src
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 1 28); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz 
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 1 28);do patch -p0 < ../bash43-$i; done
#build and install
./configure --prefix=/ && make && make install
cd .. 
cd ..
rm -r src

Pembaruan: Saya baru memperhatikan bahwa jika Anda tidak menambahkan --prefix=/ ke perintah configure Anda akan berakhir dengan /usr/local/bin/bash itu terkini dan /bin/bash masih akan rentan.


Ada bug dalam skrip: urutan "0 25" seharusnya "1 26". Jika Anda membaca ini dan dapat mengedit jawabannya, harap perbarui. Terima kasih!
joelparkerhenderson

Sementara itu ./configure --prefix=/ && make berjalan dengan baik, itu make install tampaknya membutuhkan sudo
Stewart

Terima kasih telah meletakkan ini di luar sana - cara yang adil untuk menambal sesuatu saat bermigrasi. Beberapa orang memiliki banyak vms dan itu tidak realistis untuk membangun kembali masing-masing. Menggunakan ini sebagai perbaikan langsung sambil menyelesaikannya dalam jangka panjang dengan menginstalasi yang lebih baru adalah kuncinya.
Jas Panesar

@ rubo77 Sekarang perlu 1 27 (27 patch baru adalah yang paling penting)
joelparkerhenderson

1
Menambahkan tambalan 28. Ini tidak tampaknya memperbaiki kerentanan CVE-2014-7186 / 7187.
unkilbeeg

2

Ada juga solusi memperbarui sumber Anda. Daftar ke yang terbaru dan kemudian gunakan apt-get untuk meng-upgrade hanya bash. Ini sangat cepat dan Saya sudah menulis artikel tentang itu. Inilah yang pada dasarnya Anda lakukan:

Tingkatkan ke repositori apt-get 'terpercaya' Ubuntu terbaru (Anda mungkin juga harus mengubah URL old-repositori.ubuntu.com jika Anda menggunakannya, periksa artikel yang ditautkan):

sudo sed -i 's/YOUR_OS_CODENAME/trusty/g' /etc/apt/sources.list

Tingkatkan bash / terapkan perbaikan:

sudo apt-get update
sudo apt-get install --only-upgrade bash

Dan mungkin mengubah kembali repositori apt-get.


Bekerja dengan sempurna!
Peter Kruithof

-1

Perintahnya seharusnya

sudo apt-get update && sudo apt-get install --only-upgrade bash

2
Ini tidak akan membantu; seperti kata OP, itu tidak didukung lagi, jadi tidak akan ada peningkatan untuk bash.
Andrew Ferrier

-3

Salah satu opsi sederhana adalah tidak menggunakan bash. Yakinkan dash diinstal dan itu /bin/sh adalah symlink ke dashtidak bash. (Ini adalah default pada beberapa versi Debian, tapi saya tidak yakin tentang Ubuntu.) Jika Anda memiliki akun pengguna untuk akses ssh dengan perintah paksa, Anda juga perlu mengganti shell login mereka. Anda mungkin juga perlu memeriksa skrip apa pun secara eksplisit menggunakan bash; meraih untuk #!/bin/bash harus menemukannya.


5
Itu agak seperti mengatakan, "kami menemukan bahwa Anda dapat memiliki segfault di C ++, cukup gunakan Java"
DevSolar

3
Analogi yang lebih dekat akan memberi tahu seseorang yang mengalami bug di GCC untuk mencoba bunyi berdentang. Keduanya menerapkan bahasa yang sama (dengan set ekstensi tidak standar yang berbeda namun terkadang tumpang tindih) dan tidak mungkin bahwa kebutuhan sebenarnya adalah untuk "bash" melainkan untuk "shell interpreter".
R..

Seperti yang Anda katakan, ada skrip yang bisa menggunakan bash secara eksplisit. Bahkan jika Anda menerima file yang ada yang menggunakan bash, di masa mendatang seseorang dapat menambahkan skrip baru ke sistem yang menggunakan bash secara eksplisit. Hal yang sama berlaku untuk sistem embedded yang menggunakan busybox (/ bin / sh menunjuk ke busybox), tetapi juga telah menginstal bash. Yang terbaik adalah memperbarui bash di sistem yang rentan.
jcarballo

Mayoritas skrip Unix / Linux memerlukan bash atau shell modern lainnya seperti ksh atau zsh. Ini memiliki banyak sekali fungsi yang orang harapkan dalam bahasa apa pun tetapi tidak ada dalam cangkang "tulang kosong" seperti (BusyBox) ash / Dash / sh (asli). Kerang yang lebih sederhana ini hanya memiliki 20-30% fungsionalitas dari kerang yang lebih besar yang membuatnya lebih cepat. Namun, mereka membutuhkan penggunaan utilitas eksternal yang luas untuk banyak operasi umum seperti penanganan string tingkat lanjut dan pencocokan pola. Bash dan semacamnya bisa menjadi abu, et.al. skrip Tapi tidak sebaliknya.
DocSalvager
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.