Ethereum parite istemcisinin tam sürümünde uzak DoS güvenlik açıklarının analizi
Önsöz: Bu makale Parite ile ilgili giriş, UTF-8 kodlama nedir, Rust tehlikeli dizi dilimleme, güvenlik açığı analizi, onarım planı ve özet olmak üzere beş bölümden oluşmaktadır. Bugün okuyuculara Ethereum'un parite istemcisinin tam sürümünde uzak DoS güvenlik açıklarının analizini göstereceğiz.
1. Parite ile ilgili giriş
Ethereum Parity istemcisi, Rust dilini kullanan Geth'in yanı sıra en çok kullanılan Ethereum istemcisidir.
Ethernodlardan alınan en son verilere göre, Ethereum parite müşterisi tüm Ethereum ağının% 30'unu, Geth müşterisi ise% 40'ını oluşturuyor.
Bu yıl 3 Şubat'ta, bu istemci ciddi bir uzaktan hizmet reddi güvenlik açığını düzelttiğini belirten bir duyuru yayınladı. Bu güvenlik açığı 2.2.9'dan önceki sürümleri ve 2.3.2-beta'dan önceki sürümleri, 2.2.9 ve 2.3.2-beta zaten en son sürüm. Resmi duyurudan yola çıkarak şu şekilde anlaşılabilir: Bu güvenlik açığının güvenlik açığı düzeltilmeden önceki tüm sürümleri.
Güvenlik açığı birçok sürümü etkilese de kapsamı sınırlıdır. Bunun nedeni, güvenlik açığının saldırganın hedef Parity istemcisinin JSONRPC'sine erişebilmesini gerektirmesi ve Parity'nin varsayılan olarak JSONRPC bağlantı noktasını herkese açmamasıdır.
Güvenlik açığının belirli kapsamı FOFA aracılığıyla hesaplanabilir:
Yukarıdaki şekilden, şu anda genel ağdaki 1195 eşlik düğümünün JSONRPC bağlantı noktasını açtığını görebiliriz, bu nedenle güvenlik açığı birçok sürümü etkiler, ancak etki kapsamı sınırlıdır.
2. UTF-8 kodlaması nedir?
Güvenlik açığı araştırmalarına daha iyi hazırlanmamıza yardımcı olmak için bu güvenlik açığını incelemeden önce UTF-8 kodlamasını anlamamız gerekir.
Unicode, şu anda bilgisayar endüstrisinde daha yaygın bir kodlama olan bir karakter kodlamasıdır. Unicode tüm dilleri bir kodlama kümesinde birleştirdiği için, sektördeki dil tutarsızlıklarının neden olduğu bozuk kodlar sorununu çözer.
Ve UTF-8 (8-bit Unicode Transformation Format), evrensel kod olarak da bilinen Unicode için değişken uzunlukta bir karakter kodlamasıdır.
Bu güvenlik açığı analizinde, yalnızca aşağıdaki bilgi noktalarını bilmeniz gerekir:
UTF-8 kodlamasında, bir İngilizce karakter bir bayt, bir Çince (geleneksel dahil) üç baytı kaplar.
Üç, Pas tehlikeli dize dilimi
UTF-8 kodlamasının önceki bölümde tanıtılmasının nedeni, Rust'un kullanılan UTF-8 kodlaması olması ve Ethereum Parity istemcisi tarafından kullanılan programlama dilinin Rust olmasıdır.
Dize dilimlemenin anlaşılması kolaydır, yani dizedeki belirli bir dizgiyi kesmek kolaydır, ancak Rust'un dize dilimlemesinde bir sorun vardır:
Baytları keser, karakterleri değil
Aşağıda gösterildiği gibi kısaca test edeyim:
Görüntü içeriğinin gösterilmesinden, str1 dizesinin 0-3 öğelerini dilimlerken, "DVP" nin 3 karakterinin kesildiğini, ancak 3-6 öğeleri dilimlerken, karakter olarak kesilmesi gerektiğini görebiliriz. Bunu "en iyisi" olarak kesin ama öyle olmadı.
Bu neden oluyor?
Nedeni, Rust'un baytlara göre dilimlemesidir. Makalenin bu bölümünde daha önce bahsedildiği gibi: UTF-8'de İngilizce 1 bayt, Çince 3 bayt yer kaplar, bu nedenle 3-6 keserek "Evet" kelimesini keseriz.
Tam olarak 3 baytlık dilimlerin tam bir Çince karaktere kesildiği durum budur. Şunu hayal edin: Ya dilim 2 bayt keserse?
- Çince'nin yarısı sergilenecek mi?
- Cevap: Elbette hayır.
Dilim tam bir karakter olmadığında, Rust sizin için herhangi bir karakteri kesmeyecek, ancak bir hata bildirecektir.
Basit test
Resimden, programın 3-5 dilimleme sırasında bir hata bildirdi, çünkü kesim tam bir Çince karakter değil.
Ethereum Parity istemcisi bu hatayı yaptı ve bugün bu makaledeki güvenlik açığı analizimizin anahtarı budur.
Dört, güvenlik açığı analizi
DVP güvenlik ekibi bu makaleyi yazdığında, resmi web sitesi güvenlik açığıyla ilgili herhangi bir ayrıntı açıklamadı.Bunun nedeni, güvenlik açığını gidermek için bazı düğümlerin yeni sürüme güncellenmemiş olması olabilir.Arama yaptıktan sonra, ağda kimsenin bu güvenlik açığını tartışmadığı bulundu. Kaydetme kaydını kontrol etmek için Parity'nin github'ına gidebilir, bu güvenlik açığı için bir düzeltme bulmaya çalışabilir, güvenlik açığını yama aracılığıyla analiz edebilir ve sonunda şu işlemi görebilirim:
https://github.com/paritytech/parity-ethereum/commit/3b23c2e86d09a8a8b8cd99dfa02390177498e6b7
Muhtemelen bir göz attım ve temelde bunun onarım yaması olduğunu doğrulayabilirim.Yamada, dize dilimleri begin_with işlevi ile değiştirilir:
Yukarıdaki şekilden, önceki yazıda, dizginin 0 ila 2 elemanlarının kesildiğini ve uzunluk 2'den küçükse ve ilk iki elemanın dizisi değilse "0x" ile başlayıp başlamadığına karar verildiğini görebilirsiniz. "0x" bir hata döndürecektir. Bu yazıda Rust dilimlerinin tehlikeli olduğunu öğrendik.Dilimlenmiş dizge kontrol edilebilir ise programın hata bildirmesine neden olacaktır.
Peki, dizi dilimleri kullanan bu yerler uzaktan kullanılabilir mi?
Şekle yakından bakarsanız, şekildeki iki değiştirilmiş dosyanın rpc dizininin türler dizininde olduğunu görebilirsiniz.JSONRPC arayüzünden geçen veriler için tanımlanmış bazı türler olması gerektiğini tahmin ediyoruz.Şekilde hash ve uint var.
Ardından aşağıdaki resmi RPC belgelerini kontrol edin:
Orijinal resmi belgeler, json'da yalnızca iki tür dize ve değer olduğundan, tamsayılar, baytlar, karmalar gibi veri türlerinin hepsinin kodlandığını ve 0x ön ekli bir dize biçiminde iletildiğini belirtti.
Resmi belgenin açıklamasına göre zafiyeti test etmemiz bizim için çok uygundur. Belgede verilen istek örneğinde, işlev çağrı zincirine bakarken zaman kazandıran 0x ön ekli herhangi bir parametre bulun.
İşte daha yaygın bir eth_getTransactionByHash arayüzü, istek yöntemi aşağıdaki gibidir:
curl --data '{"method": "eth_getTransactionByHash", "params":, "id": 1, "jsonrpc": "2.0"}' -H "İçerik Türü: uygulama / json" -X POST localhost: 8545'in kullanımı da çok basittir, "işlem karma değerini" Çince bir dizeyle değiştirin, örneğin:
curl --data '{"method": "eth_getTransactionByHash", "params":, "id": 1, "jsonrpc": "2.0"}' -H "İçerik Türü: uygulama / json" -X POST localhost: 8545 aslında şunu gösteriyor:
Düğümün bir istisna yaptığı ve arabirimi talep ettikten sonra çöktüğü görülebilir.
5. Onarım planı ve özeti
Daha önce bahsedilen resmi onarım planı, dizelerin tüm dilimlerini değiştirmektir.
Bununla birlikte, bu yalnızca geçici bir çözümdür.Bu tür güvenlik açıklarını uzun süre önlemek istiyorsanız, halka açık zincir geliştiricilerin dilin özelliklerini geleneksel yazılım geliştiricilerden daha iyi anlamaları gerektiğine inanıyoruz, çünkü birçok kod sorunu görmek için geleneksel programlama düşüncesini kullanıyor, ancak Dilin kendisi, geliştiricilerin anlamadığı bazı özelliklere sahip olabilir. Bu özelliklerin yardımıyla, güvenlik açıkları oluştu. Önceden, genel zincirler go dilini make işlevini ve uygunsuz parametre denetimini kötüye kullanmak için kullanıyordu ve ardından OOM'un neden olduğu bir hizmet reddi güvenlik açığı.
Bu nedenle, DVP güvenlik ekibi bu güvenlik açığı analizini, blok zinciri ekolojisini daha istikrarlı ve güvenli hale getirmek için blok zinciri geliştiricilerinin dilin özelliklerini gelecekteki gelişim yolunda daha fazla anlamaları gerektiği konusunda uyarmak için kullanmayı umuyor.
Referans bağlantısı
https://www.parity.io/security-alert-parity-ethereum-03-02/
https://blog.csdn.net/wowotuo/article/details/75579103
https://baike.baidu.com/item/UTF-8/481798?fr=aladdin
https://wiki.parity.io/JSONRPC
