CVE-2023-34450
Açıklama
CometBFT, bir durum geçiş makinesini alan ve bunu birçok makineye kopyalayan bir Bizans Hata Toleranslı (BFT) ara katman yazılımıdır. Versiyonlar 0.34.28 ve 0.37.1'de `PeerState` struct yapısının JSON'a serileştirilme yönteminde yapılan dahili bir değişiklik, yeni MarshallJSON fonksiyonu çağrıldığında bir deadlock oluşmasına neden olmuştur. Bu fonksiyon iki yerden çağrılabilir. Birincisi, `consensus` günlükleme modülü "debug" seviyesine ayarlanarak (üretim ortamında gerçekleşmemelidir) ve günlük çıktı formatı JSON olarak belirlenerek günlükler aracılığıyla yapılır. İkincisi ise `dump_consensus_state` RPC'si aracılığıyladır. Üretim ortamında karşılanmaması gereken Durum 1, zamanla çoğu goroutine'de deadlock'a yol açacak ve düğümü etkili bir şekilde durduracaktır. Durum 2'de, yalnızca ilk eşle ilgili veri yapıları ve RPC isteklerini işleyen iş parçacığı(ları) deadlock durumuna düşecektir. Bu, düğümün eşlerine olan iletişim kanallarından yalnızca birinin engelleneceği anlamına gelir. Sonunda eş zaman aşımına uğrayacak ve listeden çıkarılacaktır (genellikle 2 dakika sonra). Deadlock'a karışan goroutine'ler çöp toplayıcı (garbage collector) tarafından temizlenmeyecek ancak eş dışlandıktan sonra sistemle etkileşime girmeyecektir. Durum 2 için teorik en kötü senaryo, yalnızca iki doğrulayıcı düğümün bulunduğu bir ağdır. Bu durumda, her düğüm sadece bir `PeerState` struct yapısına sahiptir. Herhangi bir düğümde (veya her ikisinde) `dump_consensus_state` çağrılırsa, eş bağlantıları zaman aşımına uğrayana kadar zincir durur; ardından düğümler (farklı `PeerState` struct yapılarıyla) yeniden bağlanır ve zincir tekrar ilerler. Daha sonra aynı işlem tekrarlanabilir. Bir ağdaki düğüm sayısı ve dolayısıyla her düğümün tuttuğu eş struct sayısı arttıkça, iki düğümle görülen bu aksaklığın yeniden üretilme olasılığı azalır. Diğerleri değil, yalnızca ilk `PeerState` struct yapısı deadlock durumuna düşecektir (`dump_consensus_state` RPC'si bunlara bir for döngüsü içinde eriştiğinden, ilk yinelemedeki deadlock, söz konusu "for" döngüsünün geri kalan yinelemelerine asla ulaşılamamasına neden olur). Bu regresyon versiyonlar 0.34.29 ve 0.37.2'de düzeltilmiştir. Bazı geçici çözümler mevcuttur. Durum 1 için (günlükler üzerinden deadlock oluşması), ya günlük çıktısını "json" olarak ayarlamayın ve "plain" olarak bırakın ya da consensus günlükleme modülünü "debug" olarak ayarlamayın ve "info" veya daha yüksek bir seviyede bırakın. Durum 2 için (`dump_consensus_state` RPC'si üzerinden deadlock oluşması), `dump_consensus_state` RPC uç noktasını genel internete açmayın (örneğin, nginx kurulumundaki kurallar aracılığıyla).
Nasıl düzeltilir
- cometbft cometbft0.34.29, 0.37.2 ya da sonraki bir sürüm
- github.com/cometbft/cometbft0.34.29, 0.37.2 ya da sonraki bir sürüm
Etkilenen ürünler
| Ürün | Etkilenen sürümler | Düzeltildiği sürüm |
|---|---|---|
| cometbft cometbft | 0.34.28 ≤ v < 0.34.29, 0.37.1 ≤ v < 0.37.2 | 0.34.29, 0.37.2 |
| github.com/cometbft/cometbftGo | 0.34.28 ≤ v < 0.34.29, 0.37.1 ≤ v < 0.37.2 | 0.34.29, 0.37.2 |
Sürümünüzü kontrol edin
Ürünü seçin ve kullandığınız sürümü yazın; sürümün etkilenen aralıkta olup olmadığını görün.
Attack Surface Management
Alan adlarınıza bağlı varlıkları, bu varlıklarda çalışan teknolojileri ve bilinen zafiyetleri tek listede görün.