Pertanyaan Bagaimana cara mem-patch bug Heartbleed (CVE-2014-0160) di OpenSSL?


Mulai hari ini, a bug di OpenSSL telah ditemukan mempengaruhi versi 1.0.1 melalui 1.0.1f (inklusif) dan 1.0.2-beta.

Sejak Ubuntu 12.04, kita semua rentan terhadap bug ini. Untuk menambal kerentanan ini, pengguna yang terpengaruh harus memperbarui ke OpenSSL 1.0.1g.

Bagaimana setiap pengguna yang terkena dampak dapat menerapkan pembaruan ini sekarang?


152
2018-04-07 22:17


asal


Apakah Anda memiliki versi opensl yang terpengaruh? - Braiam
Saya punya versi patch 1.0.1-4ubuntu5.12 dan saya telah memulai kembali layanan apache tetapi filippo.io/Heartbleed pengujian di situs saya masih mengatakan saya rentan Ada gagasan mengapa?
@Mat Saya tidak tahu apa yang diuji oleh situs itu, tetapi mungkin mendeteksi bahwa Anda menggunakan kunci lama. Karena kuncinya mungkin bocor, Anda perlu memperbaikinya. - Gilles
Anda benar-benar tidak ingin memperbarui OpenSSL ke versi baru yang lebih besar, itu adalah rasa sakit yang luar biasa. Jauh lebih mudah adalah dengan hanya menginstal paket pembaruan yang menambal masalah: ubuntu.com/usn/usn-2165-1 - sarnold
sudahkah Anda memulai kembali layanan setelah peningkatan versi? - Axel


Jawaban:


Pembaruan keamanan tersedia untuk 12.04, 12.10, 13.10 dan 14.04 Lihat Pemberitahuan Keamanan Ubuntu USN-2165-1.

Jadi, pertama-tama Anda perlu menerapkan pembaruan keamanan yang tersedia, misalnya dengan menjalankan

sudo apt-get update
sudo apt-get upgrade

dari baris perintah.

Jangan lupa untuk mengulang kembali layanan (HTTP, SMTP, dll.) yang menggunakan versi OpenSSL yang terpengaruh, jika tidak Anda masih rentan. Lihat juga Heartbleed: Apa itu dan apa pilihan untuk meredakannya? di Serverfault.com.

Perintah berikut menunjukkan (setelah peningkatan) semua layanan yang perlu direstart:

sudo find /proc -maxdepth 2 -name maps -exec grep -HE '/libssl\.so.* \(deleted\)' {} \; | cut -d/ -f3 | sort -u | xargs --no-run-if-empty ps uwwp

Setelah itu, kamu butuh buat ulang semua kunci server SSL, kemudian evaluasi apakah kunci Anda mungkin telah bocor, dalam hal ini penyerang mungkin telah mengambil informasi rahasia dari server Anda.


141
2018-04-07 22:46



Tidak yakin ini berfungsi pada Ubuntu 12.04.4 LTS. Setelah pembaruan lengkap, openssl version memberi OpenSSL 1.0.1 14 Mar 2012. Itu bukan versi yang ditambal, bukan? Atau saya salah membaca itu? - Paul Cantrell
Apa yang harus dilakukan dengan Ubuntu 13.04? Tidak ada pembaruan yang terbuka :-( - Frodik
Pada Ubuntu 12.04 bahkan OpenSSL tetap menampilkan versi 1.0.1 14 Mar 2012. Baca baca jawaban crimi untuk mengetahui apakah instalasi Anda termasuk perbaikan. - dan
Terima kasih, @dan! Resummariskan jawaban @ crimi di sini: jika Anda berlari dpkg -l | grep ' openssl ' dan kamu dapatkan 1.0.1-4ubuntu5.12 maka Anda siap untuk pergi. - Paul Cantrell
Menambal dan memulai ulang tidak cukup. Anda perlu meregenerasi kunci dan menilai apakah kunci Anda telah bocor serta materi rahasia lainnya. Lihat mis. Apakah Heartbleed berarti sertifikat baru untuk setiap server SSL? - Gilles


Bug ini dikenal sebagai Heartbleed.

Apakah saya rentan?

Umumnya, Anda terpengaruh jika Anda menjalankan beberapa server yang Anda buat kunci SSL untuk suatu saat. Sebagian besar pengguna akhir tidak (langsung) terpengaruh; setidaknya Firefox dan Chrome tidak menggunakan OpenSSL. SSH tidak terpengaruh. Distribusi paket Ubuntu tidak terpengaruh (bergantung pada tanda tangan GPG).

Anda rentan jika Anda menjalankan server apa pun yang menggunakan OpenSSL versi 1.0-1.0.1f (kecuali tentu saja versi yang ditambal sejak bug ditemukan). Versi Ubuntu yang terkena dampak adalah 11.10 satuiric melalui 14.04 pra-rilis yang terpercaya. Ini adalah bug implementasi, bukan kesalahan dalam protokol, jadi hanya program yang menggunakan pustaka OpenSSL yang terpengaruh. Jika Anda memiliki program yang terkait dengan versi lama 0.9.x OpenSSL, itu tidak terpengaruh. Hanya program yang menggunakan pustaka OpenSSL untuk menerapkan protokol SSL yang terpengaruh; program yang menggunakan OpenSSL untuk hal-hal lain tidak terpengaruh.

Jika Anda menjalankan server rentan yang terpapar ke Internet, pertimbangkan untuk menyusup kecuali log Anda tidak menunjukkan koneksi sejak pengumuman pada 2014-04-07. (Ini mengasumsikan bahwa kerentanan tidak dieksploitasi sebelum pengumumannya.) Jika server Anda hanya terkena secara internal, apakah Anda perlu mengubah kunci akan tergantung pada apa tindakan keamanan lainnya yang ada.

Apa dampaknya?

Bug memungkinkan setiap klien yang dapat terhubung ke server SSL Anda untuk mengambil sekitar 64kB memori dari server. Klien tidak perlu diautentikasi dengan cara apa pun. Dengan mengulangi serangan, klien dapat membuang berbagai bagian memori dalam upaya berturut-turut.

Salah satu bagian penting dari data yang dapat diambil oleh penyerang adalah kunci privat server SSL. Dengan data ini, penyerang dapat meniru server Anda.

Bagaimana cara memulihkan di server?

  1. Ambil semua server yang terpengaruh secara offline. Selama mereka berjalan, mereka berpotensi membocorkan data penting.

  2. Tingkatkan libssl1.0.0 paket, dan pastikan bahwa semua server yang terpengaruh direstart.
    Anda dapat memeriksa apakah proses yang terkena masih berjalan dengan libssl `` grep '.(dihapus) '/ proc // maps`

  3. Hasilkan kunci baru. Ini diperlukan karena bug mungkin telah memungkinkan penyerang untuk mendapatkan kunci pribadi yang lama. Ikuti prosedur yang sama yang Anda gunakan awalnya.

    • Jika Anda menggunakan sertifikat yang ditandatangani oleh otoritas sertifikasi, kirim kunci publik baru Anda ke CA. Saat Anda mendapatkan sertifikat baru, pasang di server Anda.
    • Jika Anda menggunakan sertifikat yang ditandatangani sendiri, pasang di server Anda.
    • Either way, memindahkan kunci tua dan sertifikat keluar dari jalan (tapi jangan menghapusnya, hanya memastikan mereka tidak terbiasa lagi).
  4. Sekarang Anda memiliki kunci baru tanpa kompromi, Anda bisa bawa server Anda kembali online.

  5. Mencabut sertifikat lama.

  6. Penilaian kerusakan: data apa pun yang ada dalam memori proses yang melayani koneksi SSL berpotensi bocor. Ini dapat termasuk kata sandi pengguna dan data rahasia lainnya. Anda perlu mengevaluasi apa data ini mungkin.

    • Jika Anda menjalankan layanan yang memungkinkan autentikasi kata sandi, maka kata sandi pengguna yang terhubung sejak sedikit sebelum kerentanan diumumkan harus dianggap terganggu. (Sedikit sebelumnya, karena kata sandi mungkin tetap tidak digunakan dalam memori untuk sementara waktu.) Periksa log Anda dan ubah kata sandi pengguna yang terpengaruh.
    • Juga membatalkan semua cookie sesi, karena mungkin telah disusupi.
    • Sertifikat klien tidak dikompromikan.
    • Setiap data yang dipertukarkan sejak sedikit sebelum kerentanan mungkin tetap di memori server dan mungkin telah bocor ke penyerang.
    • Jika seseorang telah mencatat koneksi SSL lama dan mengambil kunci server Anda, mereka sekarang dapat mendekripsi transkrip mereka. (Kecuali kalau PFS dipastikan - jika Anda tidak tahu, itu tidak.)

Bagaimana cara saya memulihkan klien?

Hanya ada beberapa situasi di mana aplikasi klien terpengaruh. Masalahnya di sisi server adalah siapa pun dapat terhubung ke server dan mengeksploitasi bug. Untuk mengeksploitasi klien, tiga ketentuan harus dipenuhi:

  • Program klien menggunakan versi buggy perpustakaan OpenSSL untuk mengimplementasikan protokol SSL.
  • Klien terhubung ke server jahat. (Jadi misalnya, jika Anda terhubung ke penyedia email, ini bukan masalah.) Ini harus terjadi setelah pemilik server menyadari kerentanannya, jadi mungkin setelah 2014-04-07.
  • Proses klien memiliki data rahasia dalam memori yang tidak dibagikan dengan server. (Jadi, jika Anda hanya berlari wget untuk mengunduh file, tidak ada data yang bocor.)

Jika Anda melakukannya antara 2014-04-07 petang UTC dan memutakhirkan pustaka OpenSSL Anda, pertimbangkan data apa pun yang ada di dalam memori proses klien untuk dikompromikan.

Referensi


71
2018-04-08 10:02



Saya tidak percaya "Hanya sisi server koneksi SSL / TLS yang terpengaruh" adalah benar. openssl.org/news/secadv_20140407.txt mengatakan itu dapat mengungkapkan rahasia dari klien atau server. ubuntu.com/usn/usn-2165-1 setuju. Kemungkinan Anda menggunakan sertifikat klien saat menghubungkan ke server jahat adalah kecil, tetapi kemungkinan itu ada. - armb
@armb Anda membuat poin bagus. Bahkan tidak peduli apakah sertifikat klien digunakan, kebocoran data tidak terkait dengan penggunaan sertifikat. Saya sudah meminta bantuan para profesional. - Gilles
Sertifikat klien adalah kasus di mana Anda akan membocorkan kunci pribadi, tetapi ya, kata sandi, cookie otorisasi, dll. Bisa bocor. Namun, dengan klien berbasis OpenSSL seperti curl atau wget dalam penggunaan tipikal, Anda tidak akan memiliki rahasia untuk situs lain di memori saat terhubung ke server jahat, jadi dalam hal ini saya pikir satu-satunya kebocoran akan terjadi jika Anda memberikan rahasia kepada klien mengantisipasi memberi mereka ke situs yang sah, dan Heartbleed membocorkan mereka selama jabat tangan sebelum verifikasi sertifikat mengungkapkan Anda tidak terhubung ke situs yang tepat. - armb
@Gilles Anda mungkin tertarik dengan jawabannya Klien apa yang terbukti rentan terhadap Heartbleed?. Saya berhasil mendapatkan memori "menarik" pada nginx (mode proxy), wget, tautan dan lainnya. - Lekensteyn
@ MuhamedHuseinbašić Paket openssl berisi alat baris perintah. Ini tidak digunakan oleh aplikasi yang menggunakan pustaka OpenSSL untuk mengimplementasikan protokol SSL (seperti Apache). Tetapi Anda hanya perlu menerapkan pembaruan keamanan distribusi. - Gilles


Untuk melihat versi OpenSSL yang diinstal pada Ubuntu, jalankan:

dpkg -l | grep openssl

Jika Anda melihat keluaran versi berikut, patch untuk CVE-2014-0160 harus disertakan.

ii  openssl      1.0.1-4ubuntu5.12      Secure Socket Layer (SSL)...

Melihat ke https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12, ini menunjukkan bug jenis apa yang diperbaiki:

...
 SECURITY UPDATE: memory disclosure in TLS heartbeat extension
    - debian/patches/CVE-2014-0160.patch: use correct lengths in
      ssl/d1_both.c, ssl/t1_lib.c.
    - CVE-2014-0160
 -- Marc Deslauriers <email address hidden>   Mon, 07 Apr 2014 15:45:14 -0400
...

40
2018-04-08 06:40



Saya telah meningkatkan dan mendapatkan versi 5.12 tetapi alat ini masih memberi tahu saya bahwa saya rentan filippo.io/Heartbleed Pikiran? - toxaq
Saya telah menguji server kami yang diperbarui di sisi ini dan itu memberi tahu saya bahwa saya tidak terpengaruh. Apakah Anda me-reboot sistem Anda, atau setidaknya Anda yakin bahwa semua proses yang diperlukan telah dimulai kembali? - crimi
Setelah memperbarui OPENSSL, yang harus saya lakukan adalah me-restart layanan apache, tetapi anggun tidak membantu. Saya harus pergi dan restart dengan menggunakan sudo service apache2 restart - Tom Hert
Saya baru saja menemukan penyebab kerentanan saya: saya memasang mod-spdy-beta. Setelah menghapusnya dan memulai kembali apache, semua tes menjadi hijau sekarang. - Andreas Roth
Memperbarui openssl tidak memperbaiki aplikasi seperti Apache, Nginx atau postfix. Anda harus memperbarui libssl1.0.0 dan restart mereka seperti yang dijelaskan di posting lain. - tnj


Jika Anda repositori apt-get tidak berisi dikompilasi 1.0.1g OpenSSL versi, jadi cukup unduh sumber dari situs web resmi dan kompilasi.

Di bawah baris perintah tunggal untuk mengkompilasi dan menginstal versi opensl yang terakhir.

curl https://www.openssl.org/source/openssl-1.0.1g.tar.gz | tar xz && cd openssl-1.0.1g && sudo ./config && sudo make && sudo make install

Ganti file biner opensl lama dengan yang baru melalui symlink.

sudo ln -sf /usr/local/ssl/bin/openssl `which openssl`

Anda semua baik!

# openssl version should return
openssl version
OpenSSL 1.0.1g 7 Apr 2014

Cf ini posting blog.

NB: Sebagaimana dinyatakan dalam posting blog, solusi ini tidak akan memperbaiki "Nginx dan server Apache yang harus dikompilasi ulang dengan sumber openSSL 1.0.1g."


17
2018-04-08 02:18



Seperti biasanya Ubuntu tidak menyediakan versi upstream baru tetapi menambal versi untuk semua rilis yang didukung untuk menjaga perubahan seminimal mungkin. - Florian Diesch
Catatan: Pastikan Anda me-restart server Anda setelah memperbarui OpenSSL. Apache dan Nginx mengambil lib baru dan kerentanan ditutup. - dAngelov
Heh, sekarang aku meluangkan waktu untuk membaca rincian posting ini, saya bahkan lebih terkejut - mengunduh tarball dari beberapa tempat acak di Internet, membongkar, dan mengeksekusi bagian-bagiannya sebagai root adalah perilaku sembrono. Akan lebih baik jika tanda tangan tarball diunduh dan diperiksa, tetapi pastikan Anda memvalidasi tanda tangan yang ditandatangani oleh kunci yang tepat itu sendiri adalah pertanyaan yang sulit. Distribusi sudah dilakukan untuk memastikan ketersediaan tarbal dan tambalan yang aman. Terima kasih. - sarnold
mungkin ide yang baik untuk mengkompilasi dari sumber SEKARANG, dan menginstal yang lebih baru kemudian dari apt, dengan cara itu Anda lebih aman daripada tanpa berharap pada ubuntu versi yang lebih lama bagaimanapun hanya dua sen saya - nwgat
@sarnold openssl.org tidak tampak seperti tempat acak untuk mengunduh sumber untuk openssl. Canonical seharusnya membuat ini tidak perlu, tetapi openssl.org harus menjadi hulu otoritatif untuk bekerja dari. - Rustavore


Bagi mereka yang tidak ingin melakukan upgrade paket serverwide. Saya membaca banyak panduan ini hari ini dan apt-get upgrade openssl === apt-get upgrade ini akan menerapkan semua perbaikan keamanan yang diperlukan oleh mesin Anda. Hebat, kecuali Anda secara eksplisit bersandar pada versi paket lama di suatu tempat.

Ini adalah tindakan minimal yang diperlukan pada Ubuntu 12.04 LTS yang menjalankan Apache 2:

  • Pergi ke alamat ini dan buktikan Anda memiliki kerentanan. Anda harus menggunakan ALAMAT EKSTERNAL LANGSUNG DARI SERVER WEB ANDA. Jika Anda menggunakan loadbalancer (misalnya ELB) Anda mungkin tidak akan menghubungi server web Anda secara langsung.

  • Jalankan 1 liner berikut untuk meningkatkan paket dan mulai ulang. Ya saya melihat semua pemandu mengatakan bahwa Anda harus memiliki timestamp lebih lambat dari tanggal 4 April 2014, ini sepertinya tidak menjadi masalah bagi saya.

    apt-get update && apt-get install openssl libssl1.0.0 && /etc/init.d/apache2 restart

  • Pastikan Anda memiliki versi paket yang sesuai diinstal dan periksa webserver Anda untuk kerentanan sekali lagi.

Paket-paket kunci adalah sebagai berikut, saya menentukan informasi ini menggunakan perintah di bawah ini kemudian menyunting cruft (Anda tidak perlu tahu banyak tentang keadaan mesin saya).

$ dpkg -l | grep ssl

ii  libssl-dev                       1.0.1-4ubuntu5.12          SSL development libraries, header files and documentation
ii  libssl1.0.0                      1.0.1-4ubuntu5.12          SSL shared libraries
ii  openssl                          1.0.1-4ubuntu5.12          Secure Socket Layer (SSL)* binary and related cryptographic tools

1.0.1-4ubuntu5.12 TIDAK harus mengandung kerentanan. Pastikan ini terjadi dengan kembali ke situs web di bawah ini, dan menguji server web Anda.

http://filippo.io/Heartbleed/


12
2018-04-08 21:56



Menggunakan situs eksternal untuk membuktikan kerentanan di server tampaknya merupakan pendekatan yang salah bagi saya. - Rinzwind
Skrip pengujian kerentanan eksternal menjadi lebih dan lebih umum hari ini. Itu tidak persis apa yang dilakukan skrip internal, koneksi hanya dimulai dari server web eksternal. Anda dapat melihat situs seperti WhiteHatSecurity.com untuk contoh program yang memulai semua koneksi dari jarak jauh. Ada contoh di mana ini tidak akan terbang, misalnya pengujian kerentanan jaringan tetapi untuk menguji server web yang menghadap ke depan (yang pada umumnya server SSL akan) ini hampir ideal. - Adrian
Mengapa menginstal paket jika sedang ditingkatkan? - Braiam
apt-get install openssl libssl1.0.0 melakukannya untukku. Lari openssl version -a sekarang menunjukkan: built on: Mon Apr 7 20:33:29 UTC 2014 - topher
"Skrip pengujian kerentanan eksternal menjadi lebih dan lebih umum saat ini." Yang membuka kemungkinan situs eksternal menyalahgunakan sistem saya: semua yang mereka perlu tahu gagal dan meretas sistem saya sebelum saya menambalnya. Tidak, ini bukan cara yang benar. (dan ya saya host situs saya sendiri dengan apache dan openssl). - Rinzwind


Saya memperhatikan banyak komentator di sini yang membutuhkan bantuan segera. Mereka mengikuti instruksi, dan meningkatkan, dan me-reboot, dan masih rentan ketika menggunakan beberapa situs web tes.

Anda harus memeriksa untuk memastikan Anda tidak memiliki paket yang ditahan seperti libssl.

:~$ sudo apt-get upgrade -V
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
  libssl-dev (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  libssl1.0.0 (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  linux-image-virtual (3.2.0.31.34 => 3.2.0.60.71)
  linux-virtual (3.2.0.31.34 => 3.2.0.60.71)
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

Untuk meningkatkannya apt-mark unhold libssl1.0.0 (sebagai contoh). Lalu tingkatkan: apt-get upgrade -V. Kemudian, mulai ulang layanan yang terpengaruh.


11
2018-04-08 17:51