Bagaimana cara menambal bug Heartbleed (CVE-2014-0160) di OpenSSL?

152

Sampai hari ini, bug di OpenSSL telah ditemukan mempengaruhi versi 1.0.1melalui 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 terpengaruh dapat menerapkan pembaruan ini sekarang ?

security openssl Lucio
sumber
Apakah Anda memiliki versi openssl yang terpengaruh?
Braiam
Saya sudah mendapatkan versi patch 1.0.1-4ubuntu5.12 dan saya telah me-restart layanan apache tetapi filippo.io/Heartbleed pengujian di situs saya masih mengatakan saya rentan tahu apa sebabnya?
1
@Mat Saya tidak tahu apa yang diuji situs itu, tetapi mungkin mendeteksi bahwa Anda menggunakan kunci lama. Karena kunci mungkin bocor, Anda harus membuatnya kembali.
Gilles
1
Anda benar-benar tidak ingin memperbarui OpenSSL ke versi baru grosir, itu adalah rasa sakit yang luar biasa. Jauh lebih mudah adalah dengan hanya menginstal paket yang diperbarui yang memperbaiki masalah ini: ubuntu.com/usn/usn-2165-1
sarnold
sudahkah Anda me-restart layanan Anda setelah peningkatan?
Axel

Jawaban:

141

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 me - restart layanan (HTTP, SMTP, dll.) Yang menggunakan versi OpenSSL yang terpengaruh, jika tidak Anda masih rentan. Lihat juga Heartbleed: Apa itu dan apa saja pilihan untuk menguranginya? di Serverfault.com.

Perintah berikut menunjukkan (setelah upgrade) 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, Anda perlu membuat ulang semua kunci server SSL , kemudian mengevaluasi apakah kunci Anda mungkin bocor, dalam hal ini penyerang mungkin telah mengambil informasi rahasia dari server Anda.

Florian Diesch
sumber
23
Tidak yakin ini berfungsi di Ubuntu 12.04.4 LTS. Setelah pembaruan penuh, openssl versionberikan OpenSSL 1.0.1 14 Mar 2012. Itu bukan versi yang ditambal, kan? Atau saya salah baca?
Paul Cantrell
7
Apa yang harus dilakukan dengan Ubuntu 13.04? Tidak ada openssl yang ditingkatkan yang tersedia :-(
Frodik
20
Di Ubuntu 12.04 bahkan OpenSSL tetap menampilkan versi 1.0.1 14 Mar 2012. Baca jawaban crimi untuk mengetahui apakah instalasi Anda termasuk perbaikan.
dan
7
Terima kasih, @dan! Resummarizing @ crimi jawaban di sini: jika Anda menjalankan dpkg -l | grep ' openssl 'dan Anda dapatkan 1.0.1-4ubuntu5.12maka Anda baik untuk pergi.
Paul Cantrell
20
Menambal dan memulai kembali tidak cukup. Anda perlu membuat ulang kunci dan menilai apakah kunci Anda telah bocor serta materi rahasia lainnya. Lihat misalnya Apakah Heartbleed berarti sertifikat baru untuk setiap server SSL?
Gilles
71

Bug ini dikenal sebagai Heartbleed .

Apakah saya rentan?

Secara umum, Anda terpengaruh jika Anda menjalankan beberapa server yang Anda buat kunci SSL untuk beberapa titik. 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 segala jenis server yang menggunakan versi OpenSSL 1.0-1.0.1f (kecuali tentu saja versi yang ditambal sejak bug ditemukan). Versi Ubuntu yang terpengaruh adalah 11.10 oneiric hingga 14.04 pra-rilis tepercaya. Ini adalah bug implementasi, bukan cacat dalam protokol, jadi hanya program yang menggunakan pustaka OpenSSL yang terpengaruh. Jika Anda memiliki program yang ditautkan dengan OpenSSL versi 0.9.x yang lama, itu tidak terpengaruh. Hanya program yang menggunakan pustaka OpenSSL untuk mengimplementasikan protokol SSL yang terpengaruh; program yang menggunakan OpenSSL untuk hal-hal lain tidak terpengaruh.

Jika Anda menjalankan server rentan yang terpapar ke Internet, anggap itu dikompromikan kecuali log Anda tidak menunjukkan koneksi sejak pengumuman pada 2014-04-07. (Ini mengasumsikan bahwa kerentanan tidak dieksploitasi sebelum diumumkan.) Jika server Anda hanya diekspos secara internal, apakah Anda perlu mengubah kunci akan tergantung pada apa langkah-langkah keamanan lain yang ada.

Apa dampaknya?

Bug ini 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 SSL server. Dengan data ini, penyerang dapat menyamar sebagai server Anda.

Bagaimana cara memulihkan di server?

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

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

  3. Buat kunci baru . Ini diperlukan karena bug tersebut memungkinkan penyerang memperoleh kunci privat yang lama. Ikuti prosedur yang sama yang Anda gunakan pada awalnya.

    • Jika Anda menggunakan sertifikat yang ditandatangani oleh otoritas sertifikasi, kirimkan kunci publik baru Anda ke CA. Ketika Anda mendapatkan sertifikat baru, instal di server Anda.
    • Jika Anda menggunakan sertifikat yang ditandatangani sendiri, pasang di server Anda.
    • Bagaimanapun, pindahkan kunci dan sertifikat lama dari jalan (tapi jangan menghapusnya, hanya memastikan mereka tidak digunakan lagi).

  4. Sekarang Anda memiliki kunci baru tanpa kompromi, Anda dapat membawa server Anda kembali online .

  5. Cabut sertifikat lama.

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

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

Bagaimana cara memulihkan klien?

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

  • Program klien menggunakan versi kereta pustaka 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 kerentanan, jadi mungkin setelah 2014-04-07.
  • Proses klien memiliki data rahasia dalam memori yang tidak dibagikan dengan server. (Jadi jika Anda hanya berlari wgetuntuk mengunduh file, tidak ada data yang bocor.)

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

Referensi

Gilles
sumber
4
Saya tidak percaya "Hanya sisi server dari koneksi SSL / TLS yang terpengaruh" benar. openssl.org/news/secadv_20140407.txt mengatakan dapat mengungkapkan rahasia dari klien atau server. ubuntu.com/usn/usn-2165-1 setuju. Kemungkinan Anda menggunakan sertifikat klien saat menyambung ke server jahat kecil, tetapi kemungkinan ada.
armb
@armb Anda membuat poin yang bagus. Bahkan tidak masalah apakah sertifikat klien digunakan, kebocoran data tidak terkait dengan penggunaan sertifikat. Saya telah meminta bantuan para profesional .
Gilles
Sertifikat klien adalah kasus di mana Anda akan membocorkan kunci privat, tetapi ya, kata sandi, cookie otorisasi dll. Tetap dapat bocor. Namun, dengan klien berbasis OpenSSL seperti curl atau wget dalam penggunaan umum, Anda tidak akan memiliki rahasia untuk situs lain dalam memori saat terhubung ke server jahat, jadi dalam hal ini saya pikir satu-satunya kebocoran akan terjadi jika Anda memberikan rahasia klien mengantisipasi pemberian mereka ke situs yang sah, dan Heartbleed membocorkannya saat jabat tangan sebelum verifikasi sertifikat menunjukkan Anda tidak terhubung ke situs yang benar.
armb
1
@Gilles Anda mungkin tertarik dengan jawaban atas Apa yang klien terbukti rentan terhadap Heartbleed? . Saya berhasil mendapatkan memori "menarik" di nginx (mode proxy), wget, tautan, dan lainnya.
Lekensteyn
1
@ MuhamedHuseinbašić Paket ini opensslberisi alat-alat baris perintah. Itu tidak digunakan oleh aplikasi yang menggunakan pustaka OpenSSL untuk mengimplementasikan protokol SSL (seperti Apache). Tetapi Anda harus menerapkan pembaruan keamanan distribusi.
Gilles
40

Untuk melihat versi OpenSSL yang diinstal pada Ubuntu run:

dpkg -l | grep openssl

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

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

Melihat https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12 , ini menunjukkan jenis bug 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
...
halangan
sumber
2
Saya telah memutakhirkan dan mendapatkan versi 5.12 tetapi alat ini masih memberi tahu saya bahwa saya rentan filippo.io/Heartbleed Thoughts?
toxaq
3
Saya telah menguji server kami yang diperbarui dari sisi ini dan memberi tahu saya bahwa saya tidak terpengaruh. Apakah Anda me-reboot sistem Anda, atau setidaknya Anda yakin semua proses yang diperlukan telah dimulai kembali?
crimi
3
Setelah memperbarui OPENSSL, yang harus saya lakukan adalah memulai kembali layanan apache, tetapi anggun tidak membantu . Saya harus pergi dan memulai kembali dengan menggunakansudo service apache2 restart
Tom Hert
1
Saya baru saja menemukan penyebab kerentanan saya: saya telah menginstal mod-spdy-beta. Setelah menghapus dan memulai kembali apache, semua tes berwarna hijau sekarang.
Andreas Roth
3
Pembaruan openssltidak memperbaiki aplikasi seperti Apache, Nginx atau postfix. Anda harus memperbarui libssl1.0.0dan me-restart seperti yang dijelaskan dalam posting lain.
tnj
17

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

Di bawah baris perintah tunggal untuk mengkompilasi dan menginstal versi openssl 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 openssl lama dengan yang baru melalui symlink.

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

Anda semua baik-baik saja!

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

Cf posting blog ini .

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

Quentin Rousseau
sumber
2
Seperti biasanya Ubuntu tidak menyediakan versi hulu baru tetapi menambal versi untuk semua rilis yang didukung untuk menjaga perubahan seminimal mungkin.
Florian Diesch
1
Catatan: Pastikan Anda me-restart server Anda setelah memperbarui OpenSSL. Apache dan Nginx mengambil lib baru dan kerentanan ditutup.
dAngelov
6
Heh, sekarang setelah saya meluangkan waktu untuk membaca rincian postingan ini, saya bahkan lebih terkejut - mengunduh tarball dari suatu tempat acak dari Internet, membongkar, dan menjalankan bagian-bagiannya sebagai root adalah perilaku sembrono. Akan sedikit lebih baik jika tanda tangan tarball diunduh dan diperiksa, tetapi pastikan Anda memvalidasi tanda tangan yang ditandatangani oleh tombol kanan itu sendiri adalah pertanyaan yang sulit. Distribusi telah dilakukan untuk memastikan asal-usul tarball dan patch yang aman. Terima kasih.
sarnold
2
itu mungkin ide yang baik untuk dikompilasi dari sumber SEKARANG, dan instal yang lebih baru nanti dari apt, dengan cara itu Anda lebih aman daripada tanpa diharapkan pada versi-versi ubuntu yang lebih lama, bagaimanapun, hanya dua sen saya
nwgat
2
@sarnold openssl.org sepertinya bukan tempat acak untuk mengunduh sumber untuk openssl. Canonical seharusnya membuat ini tidak perlu, tetapi openssl.org harus menjadi hulu yang resmi untuk bekerja.
Rustavore
12

Bagi mereka yang tidak ingin melakukan upgrade paket seluruh server. Saya membaca banyak panduan ini hari ini dan apt-get upgrade openssl=== apt-get upgradeini akan menerapkan semua perbaikan keamanan yang diperlukan oleh mesin Anda. Hebat, kecuali jika 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 bahwa Anda memiliki kerentanan. Anda harus menggunakan ALAMAT EKSTERNAL LANGSUNG DARI SERVER WEB ANDA. Jika Anda menggunakan loadbalancer (misalnya ELB), Anda mungkin tidak menghubungi server web Anda secara langsung.

  • Jalankan 1 liner berikut untuk memutakhirkan paket dan mulai ulang. Ya saya melihat semua panduan mengatakan bahwa Anda harus memiliki stempel waktu selambat-lambatnya 4 April 2014, ini tampaknya tidak menjadi masalah bagi saya.

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

  • Pastikan Anda telah menginstal versi paket yang sesuai dan periksa kerentanan server Anda sekali lagi.

Paket-paket kuncinya adalah sebagai berikut, saya menentukan informasi ini menggunakan perintah di bawah ini lalu menyunting cruft (Anda tidak perlu tahu banyak tentang kondisi 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.12seharusnya TIDAK mengandung kerentanan. Pastikan hal ini terjadi dengan kembali mengunjungi situs web di bawah ini, dan menguji server web Anda.

http://filippo.io/Heartbleed/

Adrian
sumber
2
Menggunakan situs eksternal untuk membuktikan kerentanan di server tampaknya merupakan pendekatan yang salah bagi saya.
Rinzwind
Skrip pengujian kerentanan eksternal menjadi semakin umum dewasa ini. Itu tidak persis apa yang dilakukan skrip internal, koneksi baru saja dimulai dari server web eksternal. Anda dapat melihat situs-situs seperti WhiteHatSecurity.com untuk contoh program yang menginisiasi 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 secara umum akan menjadi server SSL) ini hampir ideal.
Adrian
Mengapa menginstal paket jika sedang ditingkatkan?
Braiam
1
apt-get install openssl libssl1.0.0melakukannya untukku. Berjalan openssl version -asekarang menunjukkan:built on: Mon Apr 7 20:33:29 UTC 2014
top
"Skrip pengujian kerentanan eksternal menjadi semakin umum hari ini." Yang membuka kemungkinan situs eksternal itu menyalahgunakan sistem saya: semua yang mereka perlu tahu itu gagal dan meretas sistem saya sebelum saya menambalnya. Tidak, ini bukan cara yang benar. (dan ya saya meng-host situs saya sendiri dengan apache dan openssl).
Rinzwind
11

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 pengujian.

Anda harus memeriksa untuk memastikan Anda tidak memiliki paket yang ditunda 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 memutakhirkannya apt-mark unhold libssl1.0.0(misalnya). Kemudian upgrade: apt-get upgrade -V. Kemudian, restart layanan yang terpengaruh.

Kartu domino
sumber