eMudhra olayından sonra Teku ve Besu, zayıf sertifika anahtarlarının dış hizmetlere bağlanan yazılımlara, bunların arasında bazı Ethereum doğrulayıcı dağıtımlarının da bulunduğu, risk oluşturması nedeniyle ilgili Docker görüntülerini güncelledi.
- Teku 26.10.3 ve Besu 26.10.2, eMudhra olayı nedeniyle Docker görüntülerinden etkilenen sertifika güvenliğini kaldırdı.
- Teku, varsayılan ana ağ düğümlerinin etkilenmediğini belirtiyor; gerçek maruziyet düzeyi, HTTPS bağlantısı ve işletmenin kullandığı Java çalışma zamanına bağlıdır.
- İçinde yer alan riskler, sahtecilik yapılan hizmetler ve doğrulayıcı operasyonlarını içerir; Teku'nun bildiriminde herhangi bir istismar rapor edilmemiştir.
Operatörler için şu anda en doğrudan soru, diğer hizmetlere bağlanırken yazılımlarının sahte sertifikaları kabul edip etmeyeceğidir. Cevap, kullanılan bağlantı ve Java kurulumuna bağlıdır; bu nedenle istemci güncellemesi, her doğrulayıcının aynı riskle karşı karşıya kaldığı anlamına gelmez.
Teku ve Besu Docker görüntülerini güncelliyor
Ethereum istemci ekibi, blok zinciri dışında başlayan bir sertifika sorununu düzeltmek için bir güncelleme yayınladı. İlgili değişiklikler, yazılımın uzak servislerin gerçek olup olmadığını nasıl belirlediğini içeriyor.
Teku 26.10.3 ve Besu 26.10.2, etkilenen sertifika köklerine olan güveni Docker görüntülerinden kaldırdı. Bu yayın, eMudhra adlı sertifika yetkilisiyle ilgili zayıf anahtarların keşfedilmesinden kaynaklandı.
Doğrulayıcı operatörleri için sorun, saldırganın yazılımın bağlandığı hizmeti taklit etmesidir. Hizmetin rolüne bağlı olarak, sahte yanıtlar sorumlulukları karıştırabilir veya bazı blok ücretlerinin ödenme yönünü etkileyebilir.
Ancak bu, her Ethereum doğrulayıcısının risk altında olduğu anlamına gelmez. Teku'nun güvenlik bildirimi, varsayılan ana ağ düğümlerinin etkilenmediğini ve şu ana kadar herhangi bir istismar rapor edilmediğini belirtmektedir.
Fark, kurulum yönteminde yatıyor. Dış HTTPS hizmetini kullanan operatörler, tamamen yerel bileşenlerde bulunmayan bağlantıları kontrol etmelidir.
Bu güncellemeler belirli bir kurulum ortamına uygulanır. Düzeltme sonrası Docker görüntüsü, kapsayıcı içinde paketlenmiş çalışma zamanı değişikliklerini içerirken, arşiv dosyasından kurulan yazılımlar, işletmenin ayrı olarak sağladığı Java versiyonunu kullanabilir.
Bu olay, doğrulayıcıların çevresindeki altyapıyı etkiledi, Ethereum'un uzlaşım kuralı değişmedi.
Sertifika sorunları neden güvenlik riskine dönüşür?
Sertifikalar, yazılımın beklenen hizmete bağlı olup olmadığını belirlemesine yardımcı olur. Güvenilen sertifika veren kurumlar, sunucu sertifikasına ait kimliği onaylar.
Bu mekanizma HTTPS sitelerinde yaygındır, ancak tarayıcı aracılığıyla iletişim kurmayan uygulamalarda da geçerlidir. Arka plan hizmetleri de bu kimlik doğrulamalara bağlı olabilir.
Sertifika yetkilisi, güvenilir kök sertifikalarının altında ara sertifikalar kullanabilir. Bu ara sertifikalarla ilişkili özel anahtarlar, daha fazla sertifika imzalamak için kullanılabilmesi nedeniyle güvenli tutulmalıdır.
Bu olayda sorun, yalnızca birinin sunucunun normal giriş bilgilerine erişmesiyle sınırlı değildi. Etkilenen ara anahtarlar, zaten açık olan bilgilerden geri kazanılabilirdi.
Go güvenlik ekibi, bu zafiyetin mikrosaniye düzeyinde özel anahtarların geri kazanılmasına izin verdiğini belirtti. Açıklamada, saldırganın ardından kontrol etmediği alan adları için sertifika oluşturabileceğine de dikkat çekildi.
Bir saldırganlığa karşı savunmasız uygulama, sertifikanın sonunda güventiği kuruma kadar izlenebilir olduğunu düşünerek bunu kabul edebilir. Bu durumda, sahte kimlikler, orijinal olarak sahtekarları reddetmek için tasarlanan kontrollerden geçebilir.
Ancak saldırganlar, kurbanların bağlantılarını engellemek veya yönlendirmek için hâlâ bir yöntem gerektirir. Zayıf anahtarlar, her kullanıcı ile her sunucu arasında otomatik olarak onları ortaya çıkarmaz.
Bu koşul, saldırıların nasıl gerçekleşeceğini daraltır ancak sertifika geçersiz kılınmasını zararsız hale getirmez. Yazılım, sahtekarı gerçek bir uç nokta olarak kabul ettiği sürece, ağ ara kesiti daha tehlikeli hale gelir.
Kudelski Security'in araştırması, etkilenen sertifika katmanlarını inceledi. Sorun, yazılımın, saldırganın yeniden oluşturabildiği anahtarlarla imzalanmış sertifikaları kabul etmesidir.
eMudhra, zayıf anahtarları işlem hatasına atfediyor
eMudhra'nın olay açıklamasına göre, bir araştırmacı 17 Ekim'de 8 zayıf ara anahtar bildirdi. Şirket, bir sonraki gün bu 8 anahtarı iptal etti.
Şirket, bu ara sertifikaların 30 Nisan 2025'te gerçekleştirilen bir anahtar töreni sırasında oluşturulduğunu belirtti. Şirkete göre, hatalı wrap ve unwrap adımları, orijinal güçlü anahtarın yanı sıra zayıf kopyalar da üretti.
Şirket, sertifikalı donanım güvenlik modüllerini kullandığını belirtti. Arızayı bu tür cihazların eksikliğinden ziyade çevresel süreçlerdeki bir adımdan kaynaklandığını açıkladı.
Şirket, bu 7 ara sertifikanın hiçbirisinin üretim ortamında kullanılmadığını ve kalan 1 sertifikanın da henüz sertifika verilmediğini belirtti. Şirket, olayın altyapının işgaline veya veri sızıntısına neden olmadığını ifade etti.
Bu ifadeler, eMudhra'nın dahili işlemlerine dair açıklamalarını açıklar. Ancak yazılım sağlayıcısı, başka tarafların kurtarılabilir anahtarları kullanabileceğini de göz önünde bulundurmalıdır.
Sertifika sistemi, orijinal operatörün hiçbir şey daha fazla imzalamayacağını taahhüdüne yalnızca dayanamaz. Bir başkası bir imza anahtarını tekrar oluşturabildiğinde, bu taahhüt, oluşturulabilecek tüm sertifikaları kontrol etmekten çıkar.
Bu nedenle, anahtar oluşturan şirketin ötesinde, tarayıcı üreticileri, işletim sistemi sağlayıcıları ve programlama dili takımları da kullanıcılarının yazılımlarının neyi kabul edeceğini göz önünde bulundurmalıdır.
Bu düzeltmeler, kullanıcılara farklı güncellemeler aracılığıyla aktarılacaktır. Tarayıcılar engel listesi alabilirken, başka bağımsız bir Java uygulaması hâlâ eski güvenilen sertifika kümesini kullanmaya devam edebilir.
Zayıf anahtar ve bu anahtarı kabul eden uygulamalar, aynı sorunun iki farklı parçasıdır. Sertifika iptali, kurumsal kayıtlar düzeyindeki sorunu çözerken, istemcilerin etkilenen güven yollarını reddetmeleri gereken güvenilir bir yöntem也需要.
Dış hizmetler, doğrulayıcılara farklı riskler getirir.
Ethereum düğümleri, farklı görevleri üstlenen yazılımlardan oluşur. Ethereum istemci belgeleri, yürütme istemcilerini ve konsensüs istemcilerini ayırt eder: ilki işlemler ve durumu işler, diğeri paylaşımlı kanıt konsensüsünü takip eder.
Doğrulayıcı yazılımı, blok önerme ve zincire kanıt sunma sorumluluklarını artırmıştır. Operatörler bu bileşenleri yerel olarak çalıştırabilir veya bunların bir kısmını dış hizmetler aracılığıyla bağlayabilir.
Teku, konsensüs istemcisidir; Besu, yürütme istemcisidir. İkisi de Java kullanır, bu da çalışma zamanı sertifika güveninin sürümlerine bağlı olduğunu açıklar.
Yerel makinenin dışındaki hizmetler, bu düzenlemeye bir kimlik doğrulama katmanı ekler. Yazılım, yanıt veren uç noktanın beklenen sağlayıcı olduğunu doğrulamalıdır.
Örneğin, operatörler imzalama işlemini aynı süreçte tutmak yerine uzaktan imzalama hizmetini kullanabilir. Başkaları ise veri veya blok oluşturma hizmetleri için dış uç noktalara güvenebilir.
Sahtecilerin ne kadar zarar verebileceği, hizmetin ne yapmaya izin verildiğine bağlıdır. Yalnızca izleme verilerini alan bir hizmet, imza kararlarına katılan bir bilgi sağlayıcı hizmetiyle aynı riski taşımaz.
Ağ yolu da aynı derecede önemlidir. Kamu altyapısı üzerinden geçen bağlantılar, aynı ana bilgisayarda veya sıkı kontrol altındaki özel ağlarda bulunan bileşenlerle karşılaştırıldığında farklı korsanlık fırsatları sunar.
Özel ağ, tüm arızaların olasılığını ortadan kaldıramaz, ancak saldırganların trafiği bozmak için gerekli konuma erişme şansını azaltır.
Bu nedenle, istemci adı yalnızca maruz kalıp kalmadığını belirlemek için yeterli değildir. Aynı yazılım, farklı uç noktalar, güvenirlik kütüphaneleri ve erişim kontrolleri kullanan ortamlarda dağıtılabilir.
Gerçekten cevaplanması gereken soru: Hangi bağlantı, etkilenen yoldan sertifikayı kabul etti? Bu sorunun netleşmesi, operatörün sahtecilik yapılan hizmetin doğrulayıcının işlemi içinde ne kadar yetkiye sahip olması gerektiğini değerlendirmesini sağlar.
Docker görüntüsü ve arşiv kurulumu neden farklı?
Docker görüntüsü, uygulamayı ve gerekli çalışma ortamını birlikte paketler; bu ortam, Java çalışma zamanını ve bu çalışma zamanının güvendiği sertifikaları içerebilir.
Ana makinedeki Java'yı güncellemek, mevcut görüntülerdeki Java'yı otomatik olarak değiştirmez. Konteynerler hâlâ kendi dahil ettikleri dosyaları kullanmaya devam edebilir.
Bu, istemci sürüm notlarının Docker değişikliklerine özellikle değinmesinin nedenidir. Teku'nun açıklamasına göre, Eclipse Temurin temel görüntüsü o dönemde ilgili kaldırılmaları içermemekteydi, bu nedenle istemci görüntüsü doğrudan değiştirildi.
Besu'nun sürüm notları, sertifika kaldırmanın Docker görüntülerine uygulandığını ve kurulumu elle yapan kullanıcıların kendi sağladıkları Java sürümlerini kontrol etmelerini açıkça talep ediyor.
Arşivleme kurulumu, bu sorumluluğu operatöre bırakır. Ethereum istemcisi zaten güncellenmiş olabilir, ancak ayrı çalışma zamanı hâlâ eski sertifika deposunu içerebilir.
Tersine, bakım sırasında benzer farklılıklar da ortaya çıkar. Bir ana bilgisayar çalışma zamanını değiştirmek, o çalışma zamanını kullanan işlemleri etkiler, ancak farklı bir Java yolu kullanan başka bir kurulumu etkilemez.
Oracle, etkinlik rehberiyle etkilenen çalışma zamanlarını güncellemeyi veya belgelerinde belirtilen alternatifleri uygulamayı önerir. Ayrıca, çalışan örnekleri yeniden başlatmayı ve her bağımsız kurulumu ayrı ayrı değerlendirmeyi talep eder.
Bu, indirilenlerden daha önemli olan çalışmakta olan süreçleri sağlar. Sunucuda düzeltilmiş dosyalar bulunabilir, ancak eski süreçler değiştirilene veya yeniden başlatılana kadar çalışmaya devam eder.
Özel sertifika deposuna başka bir değişiklik daha eklendi. Bir organizasyon, Java'nın varsayılan sertifika deposunun yanı sıra kendi hizmetleri için bakım yaptığı bir sertifika deposu kullanabilir.
Gerçek görev, istemcinin gerçekten ne kullandığını belirlemektir. Kurulum yöntemi, çalışma zamanı konumu ve güven yapılandırması, yayımlanan onarımın gerekli bağlantıya ulaşıp ulaşmadığını belirler.
Uygulamalar arasında iptal kontrolünün farklılıkları
Revokasyon, sertifikanın artık kabul edilmemesi gerektiği anlamına gelir. Ancak bu, her uygulamanın bağlantı kurmadan önce en son revokasyon bilgilerini kontrol ettiğini garanti etmez.
Bu bilgileri almak için farklı uygulamalar farklı yöntemler kullanır. Bazıları çevrimiçi hizmetleri sorgular, bazıları tedarikçiden sağlanan engelleme listelerini kullanır, bazıları ise yerel güven deposundaki sertifikalara büyük ölçüde dayanır.
Go ekibinin yanıtı, zaman uyumlu sağlayıcıların doğrudan müdahale etmesi gerekebileceğini açıklamaktadır. Ekibin 19 Ekim'de acil güvenlik sürümünü başlatması ve bildirim aldıktan yaklaşık 7,5 saat sonra düzeltme sürümünü sağlaması gerektiğini belirtmiştir.
Bu işlem, ilgili Go doğrulama davranışını kullanan uygulamaların etkilenen sertifika yollarını engelledi. Java kullanıcıları ise kendi çalışma zamanı ve güven ayarları aracılığıyla koruma sağlamalıdır.
Teku, Java'nın varsayılan olarak iptalleri kontrol etmediğini bildiriyor. Bu nedenle, eMudhra'nın bu ara sertifikaları iptal etmesine rağmen, yerel olarak güveni kaldırmak gerekli.
Kök sertifika kaldırma ve ara sertifika engelleme, farklı seviyelerde de etki edebilir. İlk durum, belirli bir zararlı yolu reddederken, ikincisi kaldırılan kök sertifikaya yönlendiren daha geniş sertifika zincirlerini engelleyebilir.
Doğru uygulama, sağlayıcı ve uygulamayı bakım altına alan organizasyona aittir. Kimlik doğrulamanın geçici olarak devre dışı bırakılması, güven sorununu çözmek yerine korumayı kaldırmaktır.
Yasal hizmetler de ayarlanabilir. Eğer sertifikaları, istemci tarafından artık reddedilen bir yola bağlıysa, hizmet sağlayıcılar kullanıcıların güvensiz güveni yeniden kurmasını beklemek yerine kabul edilebilir alternatifler sunmalıdır.
Bu, bir sertifika olayının neden birkaç gün sürebileceğini de açıklar. Keşif anında yapılabilir, ancak koruma, tarayıcılar, paketlenmiş uygulamalar ve özel altyapı arasındaki farklı yayın ve bakım süreçleriyle adım adım yerine getirilir.
Doğrulayıcı operatörleri için kritik sonuç, ilgili bağlantıların güvensiz kimlikleri reddetmiş olup olmadığıdır. Yazılım ekosisteminin diğer yerlerindeki iptal duyuruları, düğüm işleminin bu sonuca ulaştığını kanıtlamaz.
Ödüller ve doğrulayıcı stakingi aynı şekilde mi ortaya çıkar?
Doğrulayıcıların kilitlenmesi, imzalama sorumlulukları ve ücret ödemeleri birbirine bağlıdır, ancak bunlar farklı mekanizmalarla yönetilir. Bunlardan birini etkileyen bir sorun, bunların tümüne yönelik bir kontrol olarak otomatik olarak tanımlanmamalıdır.
Ethereum stake belgesi: Doğrulayıcılar, görevlerini yerine getirdikleri takdirde ödül alır ve çevrimdışı kalması veya kanıtlanabilir yanlış davranışlar nedeniyle cezalandırılır. İmza yetkisi ve çekim yetkisi sistemde farklı roller oynar.
Sertifika anahtarı, bağlantı için kullanılan kimlik sistemine aittir. Bu, doğrulayıcının gizli imza anahtarı değildir ve yatırılmış ETH çekimlerini yöneten kimlik bilgilerini doğrudan ortaya çıkarmaz.
Ancak, sahtecilik yapılan hizmetler hâlâ doğrulayıcıların davranışını etkileyebilir. Bu etki, hizmetin hangi istekleri veya yanıtları işlediğine ve hangi ek kontrollerin hâlâ tutulduğuna bağlıdır.
Blokların önerilmesi, ilgili ödemelerin ödeme alıcısını içerir. Bir yol, öneriyi veya yapılandırmayı değiştirebiliyorsa, tüm stake'ı kontrol etmeden sonuçlar ortaya çıkabilir.
İmza hizmeti, yetkilendirilmiş doğrulayıcı davranışlarına katılım nedeniyle başka bir dizi sorunu ortaya çıkarmaktadır. İsteklere yönelik sınırlamalar ve çakışan imzaları önleyen koruma önlemleri gibi kendi koruma önlemleri, saldırganın ne kadarını yapabileceğini etkilemektedir.
Hizmet kesintisi nedeniyle ortaya çıkan sorumluluk eksikliği de olası bir sonuçtur. Herhangi bir ödeme başarıyla aktarılmasa bile, saldırgan doğru yanıtın engellenmesiyle ödülleri azaltabilir.
Bu sonuçların mali etkileri farklıdır. Önerilen blok fırsatını kaçırmak, genel çevrimdışı cezalar ve kesme cezaları birbirine karıştırılmamalıdır.
İstemci duyurusu, etkilenen yapılandırmalar altında ortaya çıkabilecek sonuçları açıklar, ancak her bir operatörün bu sonuçları yaşadığını veya ilgili miktarda ETH'nin çalındığını kanıtlamaz.
Kira hizmet sağlayıcısı kullanan sahipler için gerçek olarak önemli olan, hizmet sağlayıcının gerçek dağıtımıdır. Kaç ETH yönetildiği, işletmenin hangi uzak hizmetleri veya sertifika kütüphanelerini kullandığını göstermez.
Doğrulayıcılar, Ethereum'un dışındaki yazılımlara da bağımlıdır.
Ethereum ağı kuralları, operatörlerin yalnızca bir kısmına dayanır. Donanım, çalışma zamanı, barındırma, yapılandırma ve dış hizmetler, doğrulayıcının görevlerini doğru şekilde yerine getirebilmesini etkiler.
Sertifika yetkilisi, Ethereum protokolünün dışında yer alır, ancak doğrulayıcı yazılımın hizmetleri tanımlamak için buna bağımlı olması durumunda arızası önem kazanır. Bu yalnızca, genel bir internet güvenliği sorununu stake altyapısına sokmak için yeterlidir.
İstemci çeşitliliği, farklı uygulamaların tek bir kod tabanına olan bağımlılığı azalttığı için hâlâ değerlidir. Ancak bu, her bağımlılığın bağımsız olduğu anlamına gelmez.
İki istemci, aynı programlama dili çalışma zamanını kullanabilir. Farklı operatörler aynı barındırma hizmet sağlayıcısını, imzalama hizmetini veya blok inşa altyapısını da kullanabilir.
Bu paylaşılan bileşenler, Ethereum yazılımının farklı versiyonlarında ortak bir saldırı yüzeyi oluşturur. Bu nedenle, dağıtım durumunu anlamak için yalnızca istemci marka sayısına bakmak yeterli değildir.
Yabancılaştırma da bir denge getirir. Özel imza hizmetleri, anahtar koruma yöntemini iyileştirebilir, ancak bu hizmetle olan kimlik doğrulama bağlantısının önemini de artırır.
Yerel olarak çalıştırmak da kendi bakım gereksinimlerine sahiptir. Bileşenleri aynı makineye yerleştirmek bazı ağ maruziyetlerini azaltabilir, ancak operatörler hala yazılım güncellemelerini ve o makineye erişimi yönetmek zorundadır.
Bu olay, tüm durumlarda en güvenli mimariyi otomatik olarak belirlemez. Her çevresel bağlantının sorumluluğunun anlaşılmasını ve korunmasını gerektirdiğini gösterir.
Bu fark, genel ETH kullanıcıları için de önemlidir. Düğüm altyapısındaki sertifika düzeltmesi, her cüzdanın fonlarını taşımak zorunda olduğunu veya Ethereum hesap bakiyelerinde değişiklik olduğunu anlamına gelmez.
İlgili eylemler etkilenen yazılım sağlayıcılarına aittir. Sadece onlar, ilgili çalışma zamanını, uç noktaları ve güven ayarlarını tanımlayabilir ve bu bağlantıları kurulan sistemlere tedarikçi yönergelerini uygulayabilir.
Yöneticilerin uygulama ve güncellemeleri kontrol etmesi gerekir.
Bu yayınlamalar, operatörlerin desteklenen Docker görüntülerinden etkilenen güvenirlik yollarını kaldırmasını sağlar. Arşivlenen kullanıcılar, kendi Java sağlayıcılarının yönergelerine göre ayrı ayrı çalışma zamanı işlemlerini gerçekleştirmelidir.
Düzeltilme kullanılabilirlik, sürecin yalnızca ilk adımıdır. Güncellenmiş ortam, beklenen yapılandırmayla birlikte çalıştırılmalı ve hizmetlerin düzgün çalışmasını sağlamalıdır.
Hizmet sağlayıcılar için, yeni reddedilen sertifikalar nedeniyle oluşan kesintiler, uç noktalarda sertifika değiştirme gerektirebilir. Hizmeti yeniden başlatırken kimlik doğrulamayı atlamak yerine korunmalıdır.
Sonraki açıklamalar, etkiyi daha da ayrıntılı şekilde belirleyebilir. Operatörler, etkilenen sertifika zincirini kabul eden bir yapılandırmayı tanımlayabilir veya belirli bir hizmetle ilgili olayları rapor edebilir.
Şu anda Teku bildirim raporları kullanılmamaktadır ve varsayılan ana ağ kullanımını etkilenen dış bağlantılarla ayırt etmektedir. Bu, mevcut Ethereum saldırı yüzeyini açıklayan en net kanıttır.
Etkilenen operatörlerin güncelleme nedenleri vardır. Herhangi bir finansal kayıp, saldırganın hangi hizmeti taklit ettiği, trafiğin engellenip engellenmediği ve doğrulayıcının bu hizmete ne izin verdiğiyle ilgilidir.
Ne dikkat edilmeli
- İstemci güncellemesi: Teku ve Besu'nun sürümünü takip edin ve düzeltilmiş sürümü çalıştırdığınızı doğrulayın.
- Java sertifikası: Her kurulumda kullanılan Java çalışma zamanı ve sertifika kütüphanesinin sağlayıcısının rehberini inceleyin.
- Harici bağlantılar: Uzak imzalama, veri ve blok oluşturma hizmetlerine yönlendiren HTTPS bağlantıları incelenmektedir.
- Güvenlik Bildirimi: Saldırıları veya ek açıklamaları onaylayan istemci ekibi ve Java tedarikçisinin duyurularına dikkat edin.
Sıkça Sorulan Sorular
eMudhra olayı nedir?
Bu olay, eMudhra adlı sertifika yetkilisiyle ilgili ara sertifikalarla ilişkili zayıf özel anahtarları içeriyor. Araştırmacılar, bu anahtarların açık bilgilerden geri kazanılabileceğini keşfetti, bu da başkalarının kontrolünde olmayan alan adları için sertifika oluşturmasını mümkün kılıyor. Etkilenen sertifika yolunu seven yazılımlar, bu sahte kimlikleri kabul edebilir. Saldırganlar, hedef hizmeti taklit etmek için hala bir bağlantıları engelleme veya yönlendirme yöntemi gerektirir.
Ethereum konsensüsü başarısız mı oldu?
Hayır. Raporunda bahsedilen sorun, Ethereum'un blok zinciri üzerindeki uzlaşım kuralları değil, yazılımın dış hizmetlerin kimliğini nasıl kontrol ettiğidir. İstemci güncellemesi, etkilenen yazılım ortamındaki sertifika güvenini değiştirir. Bazı doğrulayıcı dağıtımları, dış hizmetlerin sahteciliğine maruz kalırsa hâlâ operasyonel risklerle karşı karşıya kalabilir. Bu olasılık, bağlantı ve hizmet rolüne bağlıdır ve Ethereum'un uzlaşım kurallarının bozulduğu anlamına gelmez.
Hangi istemciler güncellendi?
Teku 26.10.3 ve Besu 26.10.2, etkilenen sertifika güvenliğini kaldırmak için Docker görüntülerini güncelledi. Teku, konsensüs istemcisi; Besu, yürütme istemcisi olup, ikisi de Java kullanır. Kurulum yöntemi önemlidir, çünkü bu değişiklik bu görüntülerde sağlanan ortamlara uygulanır. İstemci arşivlerini indirip Java çalışma zamanını kendi kendine sağlayan operatörler, bu çalışma zamanı için ayrı ayrı rehberlere bakmalıdır.
Tüm doğrulayıcılar etkilenecek mi?
Hayır. Teku'nun bildirimi, varsayılan ana ağ düğümlerinin etkilenmediğini belirtiyor. Risk, bir dağıtımın ilgili harici HTTPS bağlantılarını yapıp yapmadığına ve sertifika denetiminin etkilenen güven yolunu kabul edip etmediğine bağlıdır. Farklı operatörler, aynı istemciyi farklı hizmetlerde, Java sürümlerinde ve sertifika kütüphanelerinde çalıştırabilir. Bu nedenle, istemci adı veya stake edilen ETH miktarı, bir belirli doğrulayıcının maruz kalıp kalmadığını göstermez.
Docker güncellemesi tüm kurulum yöntemlerini geçersiz kılabilir mi?
Hayır. Düzeltme sonrası Docker görüntüsü, görüntü içinde paketlenmiş ortamı günceller, ancak arşiv kurulumu operatörün sağladığı başka bir Java kullanabilir. Diğer konteynerler veya hizmetlerin kendi çalışma zamanları da olabilir. Operatör, çalışan sürecin hangi kurulum yöntemini kullandığını belirlemeli ve tedarikçi talimatlarını takip etmelidir. Sunucudaki düzeltme dosyaları, hala eski ortamda çalışan süreçleri koruyamaz.
Kullanım mı doğrulandı?
Yazılan zaman noktasında, Teku'nun bildirimi bir istismarın gerçekleştiğini rapor etmemiştir. İlgili açıklamalar, bir zayıflık ve olası sonuçlarını tanımlamaktadır, ancak saldırganların bunu doğrulayıcılar için kullanmış olduğunu kanıtlamamaktadır. Kayıplar tartışılırken bu ayrım önemlidir. Bir hizmetin taklit edilebileceği bir yolun varlığı, imza sorumluluklarının manipüle edildiğini, ücret ödemelerinin yönlendirildiğini veya stake edilen ETH'nin çalındığını anlamına gelmez.
Doğrulayıcı yatırımları otomatik olarak ortaya çıkacak mı?
Hayır. Sertifika imzalama anahtarı, doğrulayıcı imzalama anahtarı ile veya çekimleri kontrol eden yetkilerle farklıdır. Etkilenen sertifika anahtarlarının kurtarılması, ETH质押 çekmek için gerekli olan anahtarların otomatik olarak açığa çıkmasına neden olmaz. Sahtecilik yapılan hizmet, dağıtım şekline bağlı olarak sorumlulukları karıştırabilir veya doğrulayıcının kullandığı bilgileri etkileyebilir. Bu hizmet, tüm yatırımlara otomatik erişim olarak değil, olası sonuçları değerlendirilmelidir.
Operatörler ne yapmalıdır?
Operatörler, ilgili Teku veya Besu sürüm notlarını ve Java sürümüne ait yönergeleri takip etmelidir. Her etkilenen işlem tarafından kullanılan çalışma zamanını ve sertifika kütüphanesini, dahil edilen konteynerler dahil olmak üzere belirlemek gerekir. Önerilen güncellemeler uygulandıktan sonra, güncellenmiş hizmetlerin çalıştığı ve gerekli bağlantıların düzgün şekilde işlediği doğrulanmalıdır. Başarısız bağlantıları geri yüklemek için sertifika denetimlerini devre dışı bırakmak, bu denetimlerin sağladığı korumayı kaldırır.