Heartbleed: Nedir ve hafifletme seçenekleri nelerdir?


204

Bu, Heartbleed güvenlik konusunu anlama ve iyileştirme konusunda Kanonik bir Soru .

Tam olarak ne CVE-2014-0160 AKA "Heartbleed" nedir? Sebep nedir, OpenSSL’nin işletim sistemleri ve sürümleri savunmasızdır, belirtileri nelerdir, başarılı bir istismarın tespit edilmesinde herhangi bir yöntem var mı?

Sistemimin etkilenip etkilenmediğini nasıl kontrol edebilirim? Bu güvenlik açığı nasıl hafifletilebilir? Anahtarlarımın veya diğer özel verilerimin tehlikeye girdiğinden endişelenmeli miyim? Başka hangi yan etkiler hakkında endişelenmeliyim?



Seni duyuyorum ama AÇAA'nın bunu kapsamlı bir şekilde ele aldığını düşünüyorum.
MadHatter

Katılıyorum: Bu harika bir cevap, ancak heartbleed.com şifre değişikliklerini zorlamak ve oturum geçersiz kılmak gibi sadece yeni anahtar çiftlerinin ötesinde bazı hususların olduğunu belirtmek için büyük çaba harcıyor.
scuzzy-delta

1
@ scuzzy-delta - iyi nokta. Şimdi cevabımı CW yaptım, bu bilgiyi düzenlemek / geliştirmek için çekinmeyin.
AÇAA

3
Bunun ne olduğuna dair en iyi örnek - (şaşırtıcı olmayan şekilde) XKCD: xkcd.com/1354
Wayne Werner

Yanıtlar:


118

İlk önce, çıldırmadan önce, bu güvenlik açığının sizin için gerçekten geçerli olup olmadığını anladığınızdan emin olun. Eğer bir sunucunuz varsa, ancak TLS'yi kullanan hiçbir uygulamanız olmadıysa, düzeltmeniz sizin için öncelikli bir şey değildir. Öte yandan, eğer hiç oldu TLS etkin uygulamalar, iyi o zaman bir tedavi için konum. Okumaya devam etmek:

Tam olarak ne CVE-2014-0160 aka "Heartbleed" nedir?

Bu büyük bir ürkütücü karmaşa, işte bu. Kısacası, bir saldırganın sistem belleğinin belirli bölümlerini okuyabildiği OpenSSL sürüm 1.0.1 ile 1.0.1f arasında uzaktan yararlanılabilir bir güvenlik açığı keşfedildi. Özel anahtarlar, önceden paylaşılmış anahtarlar, şifreler ve diğer şeyler arasında yüksek değerli kurumsal veriler gibi hassas verileri tutan kısımlar.

Hata, Google Güvenlik'ten Neel Mehta (21 Mart 2014) ve Fin BT güvenlik testi şirketi Codenomicon (2 Nisan 2014) tarafından bağımsız bir şekilde keşfedildi.

Sebep nedir?

OpenSSL’de hatalı kod var. İşte açığını tanıtıldı olduğunu taahhüt ve burada açığını sabit olduğunu taahhüt olduğunu. Böcek 2011'in Aralık ayında ortaya çıktı ve 7 Nisan 2014'te bugün yamalandı.

Hata aynı zamanda daha büyük bir sorunun belirtisi olarak da görülebilir. İlgili iki sorun (1) hatalı kodun bir kod tabanına tanıtılmamasını sağlamak için hangi sürecin uygulandığı ve (2) protokoller ve uzantıların neden bu kadar karmaşık ve test edilmesi zor olduğu. Madde (1), OpenSSL ve diğer birçok projeyle birlikte bir yönetişim ve süreç konusudur. Pek çok geliştirici kod incelemesi, analiz ve tarama gibi uygulamalara karşı koyar. (2) maddesi IETF'in TLS WG'sinde tartışılmaktadır. Bkz Heartbleed / protokol karmaşıklığını .

Hatalı kod kötü amaçlı olarak mı girildi?

Bunun gerçekten bir hata mı yoksa kötü bir oyuncu adına girilen bir kod mu olduğunu tahmin etmeyeceğim. Ancak, OpenSSL kodunu geliştiren kişi, istemeden hata yaptığını belirtir. Bakın , ciddi 'Heartbleed' güvenlik açığı tanıtan Adam, kasıtlı olarak yerleştirdiğini inkar ediyor .

Hangi işletim sistemleri ve OpenSSL sürümleri savunmasız?

Yukarıda bahsedildiği gibi, OpenSSL 1.0.1 ile 1.0.1f arasında çalışan herhangi bir işletim sistemi veya uygulama.

Semptomlar nelerdir, başarılı bir istismarın tespitinde herhangi bir yöntem var mı?

Bu korkutucu kısım. Bildiğimiz kadarıyla, bu güvenlik açığından yararlanılıp yararlanılmadığını tespit etmenin bilinen bir yolu yoktur. Bu açıklamayı tespit edebilecek IDS imzalarının yakında yayınlanması teorik olarak mümkündür, ancak bu yazı itibariyle, mevcut değildir.

Heartbleed'in vahşi doğada Kasım 2013'ün başlarında aktif bir şekilde sömürüldüğüne dair kanıtlar var. Bkz. EFF'nin Kalbindeki Vahşi: Kasım 2013'te Heartbleed Kullanarak İstihbarat Ajansları mı? Bloomberg, NSA'nın bu güvenlik açığının ortaya çıkmasından kısa bir süre sonra sömürüyü silahladığını bildirdi. Bkz Yıl için İstihbarat Heartbleed Bug Exploit NSA Said'i . Ancak ABD İstihbarat Topluluğu, Bloomberg'in iddialarını reddetti. KAYIT İLE IC'ye bakınız .

Sistemimin etkilenip etkilenmediğini nasıl kontrol edebilirim?

Eğer o zaman sadece bir konu olabilir, sisteminizde OpenSSL'i muhafaza edilmektedir openssl version:

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

Eğer dağıtım OpenSSL'yi sürdürüldüğünü, o zaman muhtemelen kullanarak yama arkasına OpenSSL sürümünü belirleyemiyor opensslkomutu veya paket bilgilerini (örneğin, apt-get, dpkg, yumveya rpm). Çoğu (tümü?) Dağıtım tarafından kullanılan arka düzeltme işlemi yalnızca temel sürüm numarasını kullanır (örneğin, "1.0.1e"); ve yok değil bir içerme etkili güvenlik versiyonunu (örneğin, "1.0.1g").

Paketler geri eklendiğinde, OpenSSL ve diğer paketlerin etkin güvenlik sürümünü belirlemek için Süper Kullanıcı hakkında açık bir soru var. Ne yazık ki, yararlı cevaplar yok (dağıtım web sitesini kontrol etmekten başka). Backpatching ile karşılaştığınızda Etkin Güvenlik Sürümünü Belirleme bölümüne bakın .

Genel bir kural olarak: Etkilenen sürümlerden birini daha önce kurduysanız ve TLSS desteği için OpenSSL ile bağlantılı programları veya hizmetleri çalıştırdıysanız, savunmasız kalırsınız.

Güvenlik açığını test etmek için bir program nerede bulabilirim?

Heartbleed'in açıklanmasından birkaç saat sonra, internetteki birkaç kişi, bu güvenlik açığının varlığına karşı bir sunucuyu kontrol etmek için kullanılabilecek sözde kamuya açık web uygulamalarını duyurdu. Bu yazı itibariyle hiçbirini incelemediğim için başvurularını daha fazla duyurmayacağım. Tercih ettiğiniz arama motorunun yardımıyla nispeten kolayca bulunabilirler.

Bu güvenlik açığı nasıl azaltılır?

Güvenlik açığı bulunmayan bir sürüme yükseltin ve güvenlik açığı bulunan verileri sıfırlayın veya yeniden güvenli hale getirin. Heartbleed sitesinde belirtildiği gibi , uygun müdahale adımları genel olarak şöyledir:

  1. Yama savunmasız sistemleri.
  2. Yeni özel anahtarları yeniden oluşturun.
  3. CA'nıza yeni CSR gönderin.
  4. Yeni imzalı sertifika alın ve yükleyin.
  5. Oturum anahtarlarını ve çerezleri geçersiz kılar
  6. Şifreleri ve paylaşılan sırları sıfırla
  7. Eski sertifikaları iptal et.

Daha ayrıntılı bir analiz ve cevap için, bkz. Bir web sitesi operatörü, Heartbleed OpenSSL sömürüsüyle ilgili ne yapmalı? Güvenlik Yığın Değişimi.

Anahtarlarımın veya diğer özel verilerimin tehlikeye girdiğinden endişelenmeli miyim? Başka hangi yan etkiler hakkında endişelenmeliyim?

Kesinlikle. Sistem Yöneticilerinin , savunmasız OpenSSL sürümlerini kullanan sunucularının gerçekten tehlikeye girdiğini ve buna göre yanıt verdiğini varsaymaları gerekir .

Güvenlik açığı açıklandıktan kısa bir süre sonra Cloudfare, sunucunun özel anahtarının pratikte kurtarılıp kurtarılamayacağını görmek için bir zorluk teklif etti. Mücadeleyi bağımsız olarak Fedor Indutny ve Ilkka Mattila kazandı. Heartbleed Mücadelesi'ne bakınız .

Daha fazla bilgiyi nerede bulabilirim?

Daha fazla ayrıntı arayanlar için Link dökümü:


Açıklama olaylarının oldukça ayrıntılı bir zaman çizelgesi, Heartbleed açıklama zaman çizelgesinde bulunabilir: kim ne ve ne zaman olduğunu biliyordu .


Programcıysanız ve OpenSSL'nin msg_cbgeri çağrısı yoluyla Heartbleed saldırısı tespit etmek gibi çeşitli programlama püf noktaları ile ilgileniyorsanız , bkz. OpenSSL Güvenlik Danışma Belgesi 2014047 .


42
SHUT için +1 . AŞAĞI. SİZİN. SERVERS. * - SSL'nin gerçekten önemli olduğu yerlerde bir şey yaparsanız, sorunu çözene kadar kapatın. Ayrıca , sunucularınızı bağladıktan sonra ( yeni anahtarlarla birlikte ) yeni sertifikalar yüklemeyi unutmayın - eski anahtarlarınızı (tehlikeye girmiş olabilir) yeniden kullanmak, bu güvenlik açığını düzeltme amacını
yitirir

29
Ayrıca , OpenSSL kitaplıklarına bağlanan hizmetleri yeniden başlatın. OpenSL'yi, servis alanlarınızı yeniden başlatmadan yükseltmek, hiç yükseltme yapmamak kadar iyidir.
EEAA

14
Gerçekten - herhangi bir büyük yamadan sonra (OpenSSL gibi) hiçbir şeyi kaçırmadığınızdan emin olmak için makineyi yeniden başlatmanın iyi bir kural olduğunu düşünüyorum.
voretaq7


3
@EEAA, "sunucularınızı kapatma", gücü kesmeniz gerektiği anlamına gelmez. Aps (veya ssl / tls'yi devre dışı bırakmak için) apache veya servis ne yapıyorsa, kapatılması (veya yeniden yapılandırılması) anlamına gelir.
psusi


36

Ubuntu 12.04, 12.10 ve 13.10

Ubuntu, güncellenmiş paketlerin artık arşivlerde bulunduğunu belirten USN-2165-1'i yayınladı . Düzeltmeyi kapmak için aşağıdaki iki komutu çalıştırın.

sudo apt-get update
sudo apt-get upgrade

Ubuntu 14.04

Bu amaçla kurduğum bir PPA'ya yeni sürümü (1.0.1g) içeren bir Debian paketi yükledim. Bu üç komut PPA'mı sisteminize ekleyecek, kullanılabilir paketlerin listesini güncelleyecek ve her şeyi yükseltecektir:

sudo add-apt-repository ppa:george-edison55/openssl-heartbleed-fix
sudo apt-get update
sudo apt-get upgrade

Not: PPA ayrıca sadece arşivlerdeki yamalı sürümleri kullanmak yerine yeni sürümü (1.0.1g) çalıştırmayı tercih etmeniz durumunda Ubuntu 12.04 ve 13.10 paketleri de sunar.

Ubuntu 10,04

Bu bir LTS Sürümü, sunucu sürümü hala destekleniyor ve güvenlik güncellemelerini alıyor. Ancak yürürlükteki güvenlik açığı, sürüm 1.0.1'in altında olduğundan ubuntu 10.04'ün standart kurulumunun openssl paketini etkilememiştir.

Masaüstü sürümü kullanım ömrü sona erdi ve yenilenmesi / yeniden kurulması gerekiyor.

Ubuntu 13.04 ve diğer güncel sürümler

Ubuntu 13.04, beklemeyebileceğiniz çok kısa bir destek süresine sahipti. Zaten ömrünün sonuna ulaştı ve artık güvenlik güncellemeleri almıyor. Uzun zamandır yenilenmesi gerekiyordu. Eğer hala birileri kullanıyorsa, lütfen şimdi sıfırdan güncelleyin veya bu kolay prosedürü izleyerek tahribatsız olarak 13.10'a yükseltilebilir: http://www.tecmint.com/upgrade-ubuntu-13-04-raring-ringtail -to-ubuntu-13-10-saucy-salamander / Güncellemeden sonra sistem kalp atışı yamasını 13.10'dan alıyor.

Diğer tüm eski ubuntu sürümleri için, temel olarak yeni bir kurulum yapılması gerektiği anlamına gelir.

Düzeltme ekinin uygulandığını doğrulayın

Temel olarak, koşma openssl version -ave oluşturma tarihinin 7 Nisan 2014 veya sonraki bir tarih olduğundan emin olun, ancak daha fazlasını burada görün .

Yeniden Başlatma

OpenSSL'ye bağlı olarak tüm servislerin yeniden başlatıldığından emin olmanın en iyi yolu yeniden başlatmaktır .


Diğer sürümler için konuşamıyorum, ancak kesin olarak kullanılabilen bir düzeltme eki var gibi görünüyor (12.04). Bunun güvenlik açığını çözdüğünü kesin olarak söyleyemem ama en azından ilgili taahhütten sonra derlendi ( Mon Apr 7 20:31:55 UTC 2014).
Calrion

@Calrion: OpenSSL için bir yama mı yoksa OpenSSL için Debian paketi mi? OpenSSL zaten düzeltildi ve yeni bir sürüm yayınlandı.
Nathan Osman

openssl güncellenirken mevcut bağlantılara ne olacak? düşürülecekler mi?
pdeva

2
Bu, hangi web sunucusunu kullandığınıza ve nasıl güncelleyeceğinize bağlıdır. Olduğu söyleniyor, savunmasız sürümünü kullandıkları için mevcut bağlantıları bırakma konusunda endişelenmem.
Nathan Osman

3
14.04'ten beri bir yama aldı .
Seth,

14

RedHat 6.5 ve CentOS 6.5

Bunlar savunmasız. RedHat'ın erratumu RHSA-2014-0376 , mevcut yamalı kütüphanelerin bulunduğunu ve etkilenen herkesin ilk fırsatta yükseltme yapması gerektiğini söylüyor.

Yazma sırasında, CentOS henüz sabit bir versiyona sahip değildi, ancak Karanbir Singh'in CentOS-anons’a gönderdiği mesajda , açılabilir TLS’ye sahip güncellenmiş bir openssl sürümü ( openssl-1.0.1e-16.el6_5.4.0.1, önemli olan son dört basamağı not edin) ürettikleri yazıyor. komut devre dışı bırakıldı ve sonunda serbest bırakıldığında sabit bir sürüm tarafından üzerine yazılacağı için güvenle uygulanabilir.

Geçici olarak sabitlenmiş sürüm henüz tüm aynalara yansımış görünmüyor, ancak http://mirror.centos.org/centos/6/updates/x86_64/Packages/ adresindeki ana depoda (ve benzer şekilde i686).

Düzenleme : Iain'in dediği gibi, şimdi C6.5 için tamamen yamalı bir sürüm var gibi görünüyor ve aynaların etrafına aceleyle itilmiş gibi görünüyor. yum updateBenim sunucular için bir düz var; bu openssl-1.0.1e-16.el6_5.7.

6.5 öncesi RH6 ve C6 sürümleri

Bunlar savunmasız değil. Red Hat'in tavsiyesine göre ,

Bu sorun, Red Hat Enterprise Linux 5 ve Red Hat Enterprise Linux 6.4 ve daha önceki sürümlerde sunulan openssl sürümlerini etkilememiştir.

Karanbir Singh'in CentOS-announc'a gönderdiği gönderi, versiyonlama konusunda eşit derecede açıktır:

Günün erken saatlerinde, CentOS-6.5’te gönderildiği gibi openssl’deki ciddi bir sorundan haberdar olduk.



13

Debian Wheezy

Debian, DSA-2896-1'i yayınladı ve burada yamalı kütüphaneler mevcut . Burada bir kabuk betiği mevcuttur .

1. Yama

Apt-get deposu güncellendi, böylece artık yamalı kütüphaneler apt-get update && apt-get upgrade

apt-get upgrade libssl1.0.0 openssl

Alternatif olarak (önerilmez) paketler manuel olarak yükseltilebilir:

wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_amd64.deb

dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u5_amd64.deb

2. Sunucuyu / hizmetleri yeniden başlatın

En iyi koruma için sunucunun tamamını yeniden başlatın veya sunucu çevrimdışı olamazsa, gerekli hizmetleri yeniden başlatın.

3. OpenSSL Sürümünü Kontrol Edin

love@server:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
love@server:~$ dpkg -l libssl1.0.0
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-====================================================
ii  libssl1.0.0                 1.0.1e-2+deb7u6  amd64            SSL shared libraries

1
Eğer güncellemeler alıyorsanız wheezy/securityo zaman iyi olacaksınız apt-get update && apt-get upgrade. Ya da, sadece paketleri güncellemek için etkileşimli bir paket yöneticisini kullanarak openssl, libssl1.0.0, libssl1.0.0-dbgve libssl-dev(Sisteminizde yüklü gibi).
CVn

apt-get kullanmak benim için sorunu çözmedi - hala OpenSSL 1.0.1e gösteriliyor 11 Şub 2013
user568829

Thanks @ michael-kjorling, bunu yaptığımda mevcut değildi, ama en güvenli ve doğru yükseltme yoluydu.
jacksoncage

2
@ user568829 yamasını uyguladıktan sonra openssl sürümü hala OpenSSL 1.0.1e 11 Feb 2013yama 1.0.1e-2 olarak adlandırıldığını gösterecek. dpkg -l openssl1.0.1e-2+deb7u6
İle

2
OpenSSL'yi güncelledikten sonra ana bilgisayarı yeniden başlatmanızı öneririm, kesinlikle gerekli olduğu için değil, en azından OpenSSL kitaplıklarını dinamik olarak yükleyen her şeyin yeni sürümü kullandığını unutmayın. (Statik olarak bağlantılı bir başka meseledir.) Bununla birlikte, bir servisin yeniden başlatılmasının kabul edilebilir olabileceği her durumda bazı sunucuların kolayca yeniden başlatılamayacağını biliyorum.
Bir CVn

9

Özel anahtarların tehlikeye atılması gereken tek varlıklar olmadığını belirtmek isterim. Hata, OpenSSL ile aynı adres alanında (yani aynı işlem) çalışan herhangi bir hafızayı sızdırma potansiyeline sahip . Bu nedenle, açık bir OpenSSL sürümünün statik veya dinamik olarak bağlantılı olduğu bir sunucu işlemi çalıştırıyorsanız , şifreler, kredi kartı numaraları ve diğer kişisel veriler de dahil olmak üzere, bu işlemin gerçekleştirdiği herhangi bir bilgi parçası potansiyel olarak tehlikeye girmiş sayılmalıdır.


9

FreeBSD 10.0 veya portlardan openssl

FreeBSD güvenlik ekibi : CVE-2014-0160 (aka "Heartbleed") ve ilgili bir duyurusu yayınladı FreeBSD-SA-14: 06.openssl

  1. FreeBSD Güncelleniyor

    • FreeBSD'yi ikili yama ile güncelleme

      İBS6 veya amd64 platformlarında RELEASE bir FreeBSD sürümü çalıştıran sistemler freebsd-update (8) yardımcı programı aracılığıyla güncellenebilir:

      # freebsd-update fetch
      # freebsd-update install
      
    • FreeBSD'yi kaynaklardan güncelleme

      1. İlgili yamayı aşağıdaki konumdan indirin ve PGP yardımcı programını kullanarak ayrılmış PGP imzasını doğrulayın.

        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch
        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc
        # gpg --verify openssl-10.patch.asc
        
      2. Aşağıdaki komutları root olarak çalıştırın:

        # cd /usr/src
        # patch < /path/to/patch
        
      3. İşletim sistemini yeniden derleyin

        kullanılarak buildworld ve installworld tarif edildiği gibi FreeBSD el kitabında .

  2. Güncelleme openssl asgari sürümü ile port 1.0.1_10

  3. Kütüphaneyi kullanarak tüm cep telefonlarını yeniden başlatın veya sistemi yeniden başlatın

  4. Sisteminiz tehlikeye girmiş gibi davranın , tüm ssl anahtarlarınızı ve / veya sertifikalarınızı ve sızdıran bilgileri yeniden yayınlayın (bkz. EEAA daha genel bir cevap).

FreeBSD 9.x ve FreeBSD 8.x

Bunlar sistemidir savunmasız değil için Heartbleed eski 0.9.x versiyonunda güvenerek olarak, varsayılan olarak konuyla openssl , kütüphane sürece yüklü openssl limanlardan (yukarı bakınız).

Bu sistemler Heartbleed sorununa açık değilse , başka bir yerel güvenlik açığı nedeniyle sisteminizi çok daha erken bir zamanda yükseltmeniz akıllıca olabilir (yukarıdaki FreeBSD-SA-14: 06.openssl ve "FreeBSD 10.0" bölümüne bakın):

Yerel bir saldırgan bir imzalama işlemini izleyebilir ve imzalama anahtarını ondan kurtarabilir. [CVE-2014-0076]

Not :

Orijinal Heartbleed tavsiyesi FreeBSD 8.4 ve 9.1'i potansiyel olarak savunmasız olarak listeler. Bu, Heartbeat Extension'un olmaması nedeniyle doğru değildir (varsayılan FreeBSD openssl kütüphanesi sürüm 0.9.x'tir).


3

Çalıştığım cihazların birçoğunda kullanılan SSL sürümlerini belirlemeyi imkansız buldum. Her ne kadar teknik olarak hafifletici olmamasına rağmen şu anda savunmasız ana bilgisayarların kimliğini tespit etmek listemin başındaydı.

FiloSottile test modülünü kullanarak rastgele ana bilgisayarlara ve bağlantı noktalarına karşı kontroller yapacak küçük bir VM'yi bir araya getirdim . Ön bakışta kod sağlam görünüyor.

Tamamlanan VM'nin sürümü burada . VMX formatında.

Uyarı Sözleri

Bu komut dosyası ve VM yalnızca sistemlerinizin geçerli durumunu gösterir. Geçmişte bir noktada sistemlerinizin savunmasız bir durumda olması ve kötüye kullanılması olabilir.

Burada bir şey görünmüyor kesinlikle düzeltmek için büyük bir önceliktir ama yok değil güncelleştirmeleri uygulayarak ve tüm anahtarlarını değiştirmek için kurtulmuş olsun.


Daha yeni Snapt'tan bir e-posta aldım. BOLO (Uyanık olun) !
Jacob,

2

Amazon Linux (Amazon EC2'de kullanılan Linux dağıtımı)

https://aws.amazon.com/amazon-linux-ami/security-bulletins/ALAS-2014-320/

Yayına Genel Bakış: OpenSSL'nin TLS kalp atışı genişletme paketlerini işleme biçiminde eksik bir sınır kontrolü bulundu. Bu kusur, bağlı bir istemciden veya sunucudan 64k'a kadar belleği ortaya çıkarmak için kullanılabilir.

Etkilenen Sürümler: Açık 1.0.0.1 yüklü olan herhangi bir Amazon Linux AMI, herhangi bir Amazon Linux AMI 2013.03 veya üstü olan ve 2013.03 veya sonraki sürümlerine yükselen Amazon Linux AMI. OpenSSL, varsayılan olarak Amazon Linux AMI'ye yüklenir.

Etkilenen Paketler: openssl

Sorun Düzeltme: Sisteminizi güncellemek için yum update openssl komutunu çalıştırın. Yeni paket yüklendikten sonra, openssl kullanan tüm hizmetleri manuel olarak yeniden başlatmanız veya örneğinizi yeniden başlatmanız gerekir. Yeni paket hala openssl-1.0.1e olarak adlandırılmış olmasına rağmen, CVE-2014-0160 için düzeltme içeriyor.

Yeni Paketler: i686:

openssl-1.0.1e-37.66.amzn1.i686

openssl-static-1.0.1e-37.66.amzn1.i686

openssl-perl-1.0.1e-37.66.amzn1.i686

openssl-devel-1.0.1e-37.66.amzn1.i686

openssl-debuginfo-1.0.1e-37.66.amzn1.i686

x86_64:

openssl-devel-1.0.1e-37.66.amzn1.x86_64

openssl-1.0.1e-37.66.amzn1.x86_64

openssl-debuginfo-1.0.1e-37.66.amzn1.x86_64

openssl-perl-1.0.1e-37.66.amzn1.x86_64

openssl-static-1.0.1e-37.66.amzn1.x86_64
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.