Apakah Mac rentan terhadap bug Bash shellshock?


58

Red Hat baru-baru ini mengumumkan bug besar terkait keamanan di Bash shell. Beberapa menyebutnya bug "shellshock". Karena OS X dibangun dari Unix, apakah ia rentan terhadap serangan yang mengeksploitasi bug ini?

Sebagai pengguna akhir, apakah saya perlu khawatir tentang perbaikan segera? Atau lebih baik saya menunggu pembaruan perangkat lunak resmi dari Apple?



Untuk melihat tindakan apa yang memengaruhi OSX, lihat security.stackexchange.com/questions/68123/…
user151019

Memperbarui pertanyaan sehingga kurang dari penipuan dan lebih dari permintaan saran untuk orang awam.
hairboat

1
Apple telah merilis perbaikan sekarang: support.apple.com/kb/DL1769
AT

Jawaban:


46

Ya, Anda secara teknis rentan. Jadi, jika Anda merasa panik atau menagih klien yang panik selama beberapa jam kerja panik, lakukan saja!

Tetapi kenyataannya adalah kecuali Anda mengizinkan akses SSH dari koneksi jarak jauh atau server web yang menjalankan skrip sisi server, Anda tidak berisiko. Anda hanya benar-benar rentan jika seseorang yang tidak Anda kenal dapat mengakses mesin Anda dari jarak jauh & melakukannya dengan cara di mana perintah Bash dapat dieksekusi.

Berarti Mac desktop Anda — yang benar-benar tidak menjalankan aplikasi server apa pun — tidak berisiko besar. Saya mau makan beberapa "pai sederhana" di sini, tapi saya tidak berpikir mayoritas pengguna Mac di luar sana akan beresiko pada akhir hari.

Jadi masalah ini terutama menjadi perhatian administrator sistem pada server Mac OS X & Unix / Linux yang terpapar dunia, bukan pengguna desktop yang tidak mengaktifkan berbagi SSH.

Mungkin ada risiko tepi malware Mac atau virus diciptakan untuk mengeksploitasi risiko ini, tapi saya ragu.

EDIT: Dan hanya untuk menguraikan bagaimana masalah ini — menurut pendapat saya yang sederhana — tidak benar-benar masalah bagi sebagian besar pengguna rata-rata, ya saya dapat menjalankan perintah berikut dari bashpada Mac OS X 10.9.5:

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

Dan saya melihat ini:

vulnerable
hello

Tebak apa? Itu hanya menakutkan jika Anda tidak memikirkannya secara rasional. Saya harus sudah masuk ke Mac saya untuk membuka Terminal. Dan untuk meniadakan apa yang saya katakan tentang SSH di atas, untuk sampai ke titik saya dapat menjalankan tes ini bahkan jika SSH diaktifkan, saya masih harus login terlebih dahulu. Dan kemudian — katakanlah saya mendapatkan akses melalui SSH — perintah tidak memungkinkan saya untuk melakukan APA SAJA melewati hak pengguna normal saya seperti ini:

env x='() { :;}; echo vulnerable' bash -c 'cat /etc/ssh_host_rsa_key'

Berarti jika Anda benar-benar rentan untuk dieksploitasi oleh peretasan ini, keamanan inti Anda pada sistem harus sangat dikompromikan sehingga fakta yang bashmemiliki kekurangan sebenarnya adalah masalah Anda.

Ini merupakan masalah dari masalah kontrol & hak secara keseluruhan karena hal tersebut berpotensi untuk memungkinkan akses yang tidak diinginkan karena perilaku tersebut meluas di luar norma yang diharapkan. Tetapi menurut pendapat saya yang sederhana, ini bukan risiko setara dengan OpenSSL atau variasi taman “biarkan saya meninggalkan kata sandi saya pada catatan yang direkam di layar saya” berisiko.

Pada akhirnya saya masih menambal semua server Linux / Unix yang saya jalankan sebagai prosedur standar. Dan dengan senang hati akan menambal Mac yang saya kelola setelah perbaikan selesai. Tetapi untuk penggunaan sehari-hari yang praktis saya merasa baik-baik saja tidak mengkhawatirkan hal ini karena saya tidak mengerti bagaimana cacat yang tidak memungkinkan untuk hak pengguna yang tinggi menambah apa pun.

UPDATE: Kata resmi dari Apple diposting di sini ; penekanan milikku:

“Sebagian besar pengguna OS X tidak berisiko terhadap kerentanan bash yang baru-baru ini dilaporkan,” kata juru bicara Apple kepada iMore. “Bash, shell perintah UNIX dan bahasa yang termasuk dalam OS X, memiliki kelemahan yang dapat memungkinkan pengguna yang tidak sah mendapatkan keuntungan dari jarak jauh. kontrol sistem yang rentan. Dengan OS X, sistem aman secara default dan tidak terkena eksploitasi bash jarak jauh kecuali pengguna mengkonfigurasi layanan UNIX canggih. Kami sedang berupaya menyediakan pembaruan perangkat lunak dengan cepat untuk pengguna UNIX tingkat lanjut kami. "

Terjemahan: Apa yang saya katakan di atas tentang ini menjadi masalah server & bukan masalah klien? Persis.

FINAL UDPATE: Bagi siapa pun yang berjuang dengan kompilasi dari sumber, pada tanggal 29 September, Apple telah secara resmi merilis patch untuk Mac OS X 10.9.5, 10.8.5 serta 10.7.5:

BELUM UPDATE FINAL LAINNYA: Dan sekarang, Apple baru saja merilis pembaruan keamanan kombinasi hari ini yang mencakup bashpembaruan juga !

Catatan: Pembaruan Keamanan 2014-005 mencakup konten keamanan Pembaruan OS X bash 1.0


7
"atau server web yang menjalankan skrip sisi server" - atau menjalankan aplikasi, mendengarkan pada port terbuka yang memungkinkan panggilan RPC dibuat yang akhirnya menjalankan perintah shell. Ini dapat berupa sejumlah hal karena ada banyak aplikasi standar yang melakukan RPC mereka. Saya pikir jawaban ini sangat naif. Sangat mudah untuk "menjalankan server web" secara tidak sengaja dalam menjalankan aplikasi yang melakukan beberapa jenis klien-server.
Ian C.

3
@IanC. Bisakah Anda memberikan contoh di mana di luar kotak OS X akan benar-benar rentan? Misalnya apakah sesuatu seperti WebEx atau GotoMeeting bahkan mendekati kemampuan Bash? Intinya adalah bahwa saya tidak dapat memikirkan skenario instal OS X sederhana yang akan benar-benar mengekspos sesuatu. Bisakah kamu?
JakeGould

8
Akun tamu tidak tersedia untuk ssh. Bahkan, tidak mungkin membuatnya tersedia untuk ssh, IIRC. Faktanya adalah, untuk sebagian besar pengguna OS X, kerentanan bash bukanlah masalah sama sekali. Bagi kita yang mengalami masalah, kita perlu mengkompilasi ulang bash segera setelah perbaikan yang teruji tersedia, tetapi itu tidak sekarang.
lbutlr

3
@IanC. Oke, contoh yang adil. Tetapi Anda masih melewatkan intinya: Bagaimana seseorang dapat mengeksploitasi kerentanan seperti itu dalam setiap contoh yang Anda berikan? Dalam setiap kasus, pengguna perlu akses ke sistem untuk memulai & lalu apa? Saya tidak bersikap acuh tak acuh tentang hal ini, tetapi saya masih belum memahami apa risikonya sebenarnya? Seseorang - misalnya - harus mencari jalan melalui API Plex untuk kemudian melakukan apa yang sebenarnya dilakukan untuk melakukan sesuatu di luar hak pengguna normal & hak akses?
JakeGould

6
@danielAzuelos “Semua orang rentan selama akun tamu terbuka: [!” Akun tamu tidak ada hubungannya dengan bash. Jadi ketakutan itu didasarkan pada apa sebenarnya? Juga, bahkan jika akun tamu terbuka & entah bagaimana bashdapat digunakan, lalu apa? Dari apa yang saya lihat dugaan menggunakan exploit ini tidak akan meningkatkan hak istimewa atau apa pun yang dekat dengan itu. Serius, saya bersedia untuk mundur dari sikap saya, tetapi ini sepertinya lebih karena kepanikan yang tidak banyak sedangkan OpenSSL adalah masalah nyata.
JakeGould

37

Iya!

Ketikkan ini di shell Anda

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

Jika dikatakan vulnerablemaka Anda rentan.

Jika dikatakan

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello

maka kamu baik-baik saja.

Edit: tautan ke perbaikan


4
Terima kasih. Saya memperbarui pertanyaan - jika kami menemukan kami rentan, bagaimana cara pengguna Mac memperbaikinya?
hairboat

3
@abbyhairboat Diposting jawaban saya. Kecuali Anda menjalankan server yang terekspos ke dunia luar, tidak ada risiko praktis. Administrator server adalah orang yang perlu khawatir tentang ini.
JakeGould

1
→ abby: silakan lihat jawaban terkait ini: apple.stackexchange.com/a/146851/22003 .
dan

2
Coba ini env X="() { :;} ; echo busted" /bin/sh -c "echo completed"- Bahkan setelah menambal sistem saya, yang satu ini batuk 'rusak' di baris perintah. Bah
Trane Francks

1
@Mark nggak, zsh aman. Anda perlu mengganti "bash -c" dengan "zsh -c" untuk mengujinya.
ismail

3

Sebagai pengguna akhir , periksa bahwa:

  • akun tamu Anda tidak aktif:

    Preferensi Sistem> Pengguna & Grup> Pengguna Tamu
    
  • sshakses Anda tidak aktif:

    System Preferences> Sharing> Remote Login
    

Secara default keduanya dimatikan pada Mavericks.

Sebagai pengguna akhir , lebih aman menunggu pembaruan keamanan resmi Apple yang memperbaiki bashkerentanan ini .


1
Ini tidak relevan. Salah satu dari ini, sesuai sifatnya, memberikan pengguna akses untuk menjalankan perintah pada sistem, jadi jika Anda mengaktifkannya, itu adalah niat Anda untuk memungkinkan pengguna menjalankan perintah. Bug Shellshock adalah sarana bagi pengguna yang Anda tidak bermaksud dapat menjalankan perintah untuk dapat melakukannya, misalnya pengguna server web yang Anda jalankan. Jadi, jawaban Anda harus mengatakan "Nonaktifkan Berbagi Web" (tapi itu hanya satu hal yang perlu diperiksa)
Josh

Saya kesal Apple tidak menyarankan untuk mematikan pengaturan itu. Siapa yang akan memungkinkan mereka? Saya akan. Saya adalah pengguna Mac sejak 1986, pengembang aplikasi web penuh waktu (jadi ssh adalah hidup saya), dan seorang ayah (jadi akun Tamu untuk anak-anak bukanlah ide yang buruk). Saya kenal banyak orang yang seperti saya dalam hal ini yang menggunakan laptop Apple. Ingin kehilangan kita? Membiarkan celah ini terbuka adalah cara yang baik.
minopret

2

Semua mesin Mac OS X secara teknis rentan terhadap "Shellshock," sampai Apple mengeluarkan pembaruan keamanan yang menambal bash, tapi ..

Pertanyaan Anda seharusnya: Dapatkah saya diretas dari jarak jauh?

Ada begitu banyak perangkat lunak yang menggunakan bashtanpa sadar sehingga menjawab pertanyaan itu sangat sulit. Jika Anda khawatir maka saya akan menyarankan beberapa perubahan System Preferencesuntuk mencegah eksploitasi jarak jauh:

  • Nonaktifkan SEMUA layanan berbagi di bawah Berbagi Preferensi.
  • Aktifkan Firewall di bawah Keamanan dan Privasi.

Jika Anda sangat khawatir maka tekan Firewalltombol opsi untuk:

  • Hapus centang Automatically allow signed software to receive incoming connections.
  • Periksa Block all incoming connections.

Masih ada kesempatan terhormat bahwa Anda rentan terhadap serangan level menggunakan DHCP, Bonjour, dll., Tapi hei jika Anda membutuhkan layanan lain maka jelas Anda bisa membiarkannya berjalan sementara Anda berharap itu tidak bisa dieksploitasi. Dan Anda harus membiarkan firewall lebih terbuka juga. Ini mungkin akan baik-baik saja jika mesin Anda hidup di balik firewall lain.

Juga, adakah serangan eskalasi hak istimewa lokal diaktifkan oleh "Shellshock?" Ya, hampir pasti. Saya tidak akan khawatir karena Mac OS X memiliki cukup banyak serangan serupa. Apple tidak menambal bug eskalasi hak istimewa lokal dengan cepat. Dan Apple sering menciptakannya dengan layanan yang mendukung Apple Script. Anggap saja semua mesin Mac OS X selalu rentan terhadap serangan lokal. Jika Anda perlu menghadiri konferensi peretas seperti DEFCON maka belilah sendiri kotak Linux untuk tujuan itu.

Pembaruan: Ada instruksi untuk mengkompilasi ulang bash tetap Anda dan pertanyaan lain yang dibahas juga. Saya akan melakukan ini sendiri, tetapi IMHO itu berlebihan jika Anda tidak menjalankan server dan menjaga firewall Apple tetap menyala.

Update: Jika Anda merasa nyaman dengan penggunaan terminal, ada sebuah program yang disebut execsnoopdisebutkan di sini yang akan membiarkan Anda menguji apakah pesta biasanya disebut dengan proses server Anda. Bukan peluru ajaib karena proses server mungkin memanggil bash hanya dalam situasi yang tidak biasa, tetapi itu akan memberi Anda ide yang baik.

Akhirnya, Apple tidak pandai memperbaiki kerentanan keamanan, tetapi mereka bagus dalam hal PR, jadi ini akan diperbaiki dengan relatif cepat. Oleh karena itu masuk akal untuk berpikir "Saya tidak perlu berlari lebih cepat daripada beruang, saya hanya perlu berlari lebih cepat daripada sejumlah besar server yang mudah dieksploitasi di internet". :)


2
Tidak ada kemungkinan Mac rentan terhadap serangan menggunakan DHCP, karena tidak menggunakan Bash.

1
Bagaimana Anda tahu bahwa? Penasihat awal adalah klien DHCP yang rentan. Dan banyak artikel berspekulasi bahwa klien Mac OS X dan / atau iOS DHCP mungkin rentan. Semua server harus dianggap rentan kecuali terbukti sebaliknya.
Jeff Burdges

1
Tidak, seharusnya tidak; itu mutlak FUD. Anda dapat memeriksa kode sumber terbuka untuk implementasi dhcp OS X dan mengukur sistem panggilan sendiri untuk memverifikasi.

3
@JeffBurdges, OS X belum menggunakan shell exec dengan DHCP sejak 10.3, dan sebelum itu bash tidak diinstal pada sistem. DHCP pada OS X tidak hanya masalah dengan Shellshock. (Satu hal lagi yang perlu dikhawatirkan.))
Trane Francks

1
→ Jeff: tolong pertimbangkan: strings /usr/libexec/bootpd | egrep '/bin|bash'dan nm -a /usr/libexec/bootpd | egrep 'fork|exec'. Dengan membaca perintah-perintah ini keluaran pada berbagai versi MacOS X, Anda mungkin mempertimbangkan kembali analisis risiko Anda karena dhcpdpada MacOS X ... tetapi yang ini saja :(.
dan

2

Saya membuat alat ini segera setelah saya mendengar tentang kerentanan ini. Ini akan memberi Anda tautan ke artikel untuk menambal shell Anda jika alat menentukan Anda rentan.

Membutuhkan Mac OS X 10.6 dan lebih tinggi.


3
Mungkin itu hanya saya ... tetapi gagasan menjalankan beberapa kode orang secara acak untuk menguji eksploit sepertinya adalah ide yang sangat buruk ketika Anda dapat dengan mudah menempelkan string (yang jelas hanya menjalankan tes & tidak lebih) ke dalam jendela terminal.
Joe

Saya setuju, itu sebabnya sumbernya ada di code.google.com/p/shellshock-check
Thomas Jones

Namun terkadang, itu dapat menawarkan kemudahan penggunaan untuk menguji beberapa sistem.
Thomas Jones

Saya tidak melihat manfaat dari hal ini. Memeriksa kerentanan jauh lebih mudah dilakukan dengan menempelkan baris perintah sederhana di jendela terminal.
Albert Godfrind

Ketika menguji beberapa mesin, terutama dalam kasus saya, karena itulah yang saya lakukan, memasukkan flash drive dan membuka Shellshock Check.app jauh lebih mudah daripada membuka Safari, mencari perintah bash untuk memeriksa, lalu membuka Terminal, menempelkan itu perintah dan kemudian tekan Enter. Jauh lebih cepat untuk memasang flash drive, dan membuka satu aplikasi.
Thomas Jones
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.