Yıldırım Böceğinden Yararlanmak Etik Seçimdi

Bu, Bitcoin alanında kendi kendini yetiştirmiş bir eğitimci ve teknoloji odaklı Bitcoin podcast sunucusu olan Shinobi'nin bir fikir editörüdür.

Yaklaşık bir ay içinde ikinci kez btcd/LND, Bitcoin Core'dan fikir birliğine varmalarına neden olan bir hatadan yararlandı. Bir kez daha Burak, bu güvenlik açığını tetikleyen geliştiriciydi - bu kez açıkça kasıtlıydı - ve bir kez daha, Bitcoin işlemlerini fikir birliği katmanının üzerinde ayrıştırmaya yönelik kodla ilgili bir sorun vardı. Konuşmamda tartıştığım gibi önceki hatayla ilgili parça Burak'ın tetiklediği gibi, Taproot'tan önce bir işlemdeki komut dosyası ve tanık verilerinin ne kadar büyük olabileceği konusunda sınırlamalar vardı. Taproot'un etkinleştirilmesiyle bu sınırlar kaldırıldı ve bireysel işlemlerin bu kısımlarını sınırlamak için yalnızca blok boyutu sınırındaki sınırlamalar kaldı. Son hatadaki sorun, btcd'deki konsensüs kodunun bu değişikliği yansıtacak şekilde düzgün bir şekilde yükseltilmesine rağmen, eşler arası aktarımı (göndermeden önce veya alırken verileri ayrıştırma dahil) işleyen kodun düzgün şekilde yükseltilmemesiydi. Dolayısıyla, kod işleme blokları ve işlemleri, fikir birliği için doğrulanmak üzere gerçekten aktarılmadan önce verilerde başarısız oldu, onu hiçbir zaman fikir birliği doğrulama mantığına aktarmadı ve söz konusu blok hiçbir zaman doğrulanamadı.

Bu sefer de çok benzer bir olay yaşandı. Kod tabanının eşler arası bölümündeki bir diğer sınırlama, tanık verileri üzerinde yanlış bir kısıtlama uygulamak ve bunu tam blok boyutunun aksine blok boyutunun maksimum 1/8'i ile sınırlamaktı. Burak hazırladı işlem tanık verileriyle katı sınırın yalnızca tek bir ağırlık birimi üzerinde olması ve btcd ve LND düğümlerinin bir kez daha bu blok yüksekliğinde durmasına neden oldu. Bu işlem standart olmayan bir işlemdi; bu, fikir birliği kurallarına göre tamamen geçerli olmasına rağmen, varsayılan bellek havuzu politikasına göre geçerli olmadığı ve bu nedenle düğümlerin bunu ağ üzerinden aktarmayacağı anlamına gelir. Bunu bir bloğa çıkarmak tamamen mümkün, ancak bunu yapmanın tek yolu onu doğrudan bir madenciye sağlamaktır ki Burak da F2Pool'un yardımıyla bunu yaptı.

Bu, amacı Bitcoin verilerini ayrıştırmak ve doğrulamak olan herhangi bir kod parçasının, Bitcoin Core'un yapacağı şeyle uyumlu olduğundan emin olmak için yoğun bir şekilde denetlenmesi gerektiği noktasını ortaya koyuyor. Bu kodun bir düğüm uygulaması için fikir birliği motoru mu yoksa yalnızca bir Lightning düğümü için işlemleri aktaran bir kod parçası mı olduğu önemli değil. Bu ikinci hata şuydu: Kelimenin tam anlamıyla geçen aykinin hemen üstünde kod tabanında. Lightning Laboratuvarlarındaki hiç kimse tarafından bile keşfedilmedi. AJ Towns bunu 11 Ekim'de, orijinal hatanın Burak'ın 998/999 çoklu imza işlemi tarafından tetiklenmesinden iki gün sonra bildirdi. Silinmeden önce 10 saat boyunca Github'da herkese açık olarak yayınlandı. Daha sonra LND'nin bir sonraki sürümünde sorunu sessizce düzeltme niyetiyle bir düzeltme yapıldı, ancak yayınlanmadı.

Bu, ciddi bir güvenlik açığı için oldukça standart bir prosedürdür, özellikle de böyle bir güvenlik açığının temel katman ağında/protokolünde ciddi hasara neden olabileceği Bitcoin Core gibi bir projede. Ancak bu spesifik durumda, LND kullanıcılarının fonları için ciddi bir risk teşkil ediyordu ve kelimenin tam anlamıyla aynı riskleri taşıyan önceki hatanın hemen yanında olduğu gerçeği göz önüne alındığında, bulunma ve istismar edilme şansı çok yüksekti. Burak'ın gösterdiği gibi. Bu, kullanıcıları fon hırsızlığına açık bırakabilecek bu gibi güvenlik açıkları söz konusu olduğunda sessiz yama yaklaşımının gidilecek yol olup olmadığı sorusunu akla getiriyor (çünkü düğümleri eski kanal durumlarını tespit edemiyor ve onları uygun şekilde cezalandıramıyor).

Son hatayla ilgili yazımda değindiğim gibi, kötü niyetli bir aktör, hataları iyi niyetli bir geliştiriciden önce bulsaydı, taktiksel olarak savunmasız düğümlere yeni kanallar açabilir, bu kanalların tüm içeriğini tekrar kendisine yönlendirebilir ve sonra hatayı istismar etti. Oradan, bu fonları kontrolleri altına alacaklar ve aynı zamanda kanalı başlangıç ​​​​durumuyla kapatabilecekler, kelimenin tam anlamıyla paralarını ikiye katlayabileceklerdi. Burak'ın ironik bir şekilde bu konuyu aktif olarak istismar ederek yaptığı şey aslında LND kullanıcılarını böyle bir saldırıdan korudu.

Kullanıcılar, bir kez istismar edildiğinde, zaten açık kanallara sahip oldukları önceden var olan eşlerden gelen bu tür saldırılara açıktı, ancak artık yeni kanallarla özel olarak hedef alınamıyorlardı. Düğümleri durmuştu ve düğümlerini durduran bloktan sonra birisinin açmaya çalıştığı kanallar aracılığıyla yapılan ödemeleri asla tanıyamayacak veya işleme koyamayacaktı. Dolayısıyla, kullanıcıların istismar edilmesi riskini tamamen ortadan kaldırmasa da, bu riski halihazırda kanal sahibi oldukları kişilerle sınırladı. Burak'ın hareketi bunu hafifletti. Şahsen ben, hataya yanıt olarak bu tür eylemlerin anlamlı olduğunu düşünüyorum; hasarı sınırladı, kullanıcıları risk konusunda bilinçlendirdi ve hızlı bir şekilde yama yapılmasını sağladı.

Etkilenen tek şey LND de değildi. Sıvı sabitleme süreci de bozuldufederasyonun görevlilerinin bunu düzeltmesi için güncellemeler yapılması gerekiyor. Rust Bitcoin'in eski sürümleri duraklamanın bazı blok araştırmacılarını ve elektr örneklerini (Electrum Wallet için arka uç sunucusunun bir uygulaması) etkilemesine neden oldu. Şimdi, Liquid'in sabitlemesinin, zaman aşımının sona ermesinden sonra Blockstream tarafından tutulan acil durum kurtarma anahtarlarına fonları ifşa etmesi dışında - ve gerçekçi bir şekilde, Blockstream'in bu fonları çaldığı soygun tarzı film senaryosunda, herkes tam olarak kimin peşinden gideceğini biliyor - bu diğer sorunlar hiçbir zaman kimsenin parasını riske atmaz. Ayrıca Rust Bitcoin, bu özel hatayı daha yeni sürümlerde yamamıştı; bu da görünüşe göre diğer kod tabanlarının sağlayıcılarıyla bu tür sorunların potansiyelini vurgulamak için herhangi bir iletişime yol açmadı. Sorunun birden fazla kod tabanında mevcut olduğunu geniş ölçüde ortaya çıkaran şey, yalnızca ağdaki canlı olarak hatanın aktif olarak kullanılmasıydı.

Bu, Bitcoin'deki Katman 2 yazılımındaki buna benzer güvenlik açıkları söz konusu olduğunda bazı büyük sorunları gündeme getiriyor. İlk olarak, bu kod tabanlarının güvenlik hataları açısından denetlenme ciddiyeti ve yeni özelliklerin entegrasyonuna göre buna nasıl öncelik verildiği. Bu ikinci hatanın, kelimenin tam anlamıyla geçen ay keşfedilen ilk hatanın hemen yanında olmasına rağmen, mevcut olduğu kod tabanının bakımcıları tarafından bile bulunamadığı göz önüne alındığında, güvenliğe her zaman öncelik verilmediğinin çok açıklayıcı olduğunu düşünüyorum. Kullanıcıların fonlarını riske atan büyük bir hatanın ardından, bu kod tabanının iç denetimi yapılmadı mı? Bunu keşfetmek için projenin dışından biri mi gerekti? Bu, daha fazla kullanıcı çekmek için yeni özellikler geliştirmek yerine kullanıcıların fonlarını korumaya öncelik verildiğini göstermez. İkincisi, bu sorunun Rust Bitcoin'de zaten yamalanmış olması, farklı kod tabanlarının bakımcıları arasında bunun gibi hatalar konusunda iletişim eksikliği olduğunu gösteriyor. Bu oldukça anlaşılır bir durum çünkü kod tabanlarının tamamen farklı olması, birinde hata bulan birinin hemen şunu düşünmesine neden olmuyor: "Böyle bir hata potansiyeli konusunda onları uyarmak için tamamen farklı programlama dillerinde benzer yazılımlar yazan diğer ekiplerle iletişime geçmeliyim." Windows'ta bir hata bulamazsınız ve hemen hatayı Linux çekirdek bakımcılarına bildirmeyi düşünürsünüz. Bununla birlikte, küresel bir ağ üzerinde dağıtılmış mutabakat protokolü olarak Bitcoin çok farklı bir canavardır; belki de Bitcoin geliştiricileri, konu Bitcoin yazılımındaki güvenlik açıkları olduğunda bu doğrultuda düşünmeye başlamalı. Özellikle konsensusla ilgili verilerin ayrıştırılması ve yorumlanması söz konusu olduğunda.

Son olarak, güvenliği sürdürmek amacıyla eski kanal durumlarına tepki verebilmek için blok zincirinin her zaman gözlemlenmesine dayanan Lightning gibi protokoller söz konusu olduğunda, verilerin bağımsız ayrıştırılması ve doğrulanması mutlak minimumda tutulmalıdır. tamamen kaldırılmaz ve Bitcoin Core'a veya doğrudan ondan türetilen verilere devredilmez. Core Lightning, Bitcoin Core'un bir örneğine bağlanarak ve blokların ve işlemlerin doğrulanması için tamamen buna bağlı olarak bu şekilde tasarlanmıştır. LND aynı şekilde çalışsaydı, btcd'deki bu hataların hiçbiri LND kullanıcılarını fonlarını riske atacak şekilde etkilemezdi.

İşler hangi şekilde ele alınırsa alınsın (doğrulamanın tamamen dış kaynaklardan sağlanması veya basitçe dahili doğrulamanın en aza indirilmesi ve ona çok daha dikkatli yaklaşmak) bu olay, Katman 2 yazılımının fikir birliğiyle ilgili verilerle etkileşimi nasıl ele aldığı konusuna yaklaşırken bir şeylerin değişmesi gerektiğini gösteriyor. Bir kez daha, bu durumun kötü niyetli bir aktör tarafından değil, bir noktayı kanıtlayan bir geliştirici tarafından istismar edildiği için herkes çok şanslı. Bununla birlikte, Bitcoin şanslı olmaya veya kötü niyetli aktörlerin bulunmadığını ummaya güvenemez.

Geliştiriciler ve kullanıcılar, bu gibi olayların tekrar yaşanmasını önlemek için süreçleri iyileştirmeye odaklanmalı ve suçu patates gibi etrafa savurma oyunu oynamamalıdır.

Bu Shinobi'nin konuk yazısıdır. İfade edilen görüşler tamamen kendilerine aittir ve BTC Inc veya Bitcoin Magazine'in görüşlerini yansıtmayabilir.