Solidity Derleyici Açıkları Analizi ve Müdahale Stratejileri

Derleyici, modern bilgisayar sistemlerinin temel bileşenlerinden biridir. İnsanların anlaması ve yazması kolay yüksek seviyeli programlama dili kaynak kodunu, bilgisayarın alt seviye CPU'su veya bayt kodu sanal makinesi tarafından yürütülebilen talimat kodlarına dönüştüren bir bilgisayar programıdır.

Çoğu geliştirici ve güvenlik uzmanı genellikle uygulama kodunun güvenliğine odaklanırken, derleyicinin kendisinin güvenlik sorunlarını göz ardı edebilir. Aslında, bir bilgisayar programı olarak derleyicinin de güvenlik açıkları vardır ve bu açıklar belirli durumlarda ciddi güvenlik riskleri oluşturabilir. Örneğin, bir tarayıcı JavaScript ön uç kodunu derleyip ayrıştırarak yürütme sürecinde, JavaScript ayrıştırma motorundaki bir güvenlik açığı nedeniyle, kullanıcı kötü niyetli bir web sitesini ziyaret ettiğinde saldırganlar tarafından uzaktan kod yürütülmesi için istismar edilebilir ve bu da mağdurun tarayıcısını hatta işletim sistemini kontrol altına alınmasına yol açabilir.

Solidity derleyicileri de bir istisna değildir, Solidity geliştirme ekibinin güvenlik uyarılarına göre, farklı sürümlerdeki Solidity derleyicilerinde güvenlik açıkları bulunmaktadır.

Solidity derleyici açığı

Solidity derleyicisinin işlevi, geliştiricilerin yazdığı akıllı sözleşme kodunu Ethereum Sanal Makinesi (EVM) talimat koduna dönüştürmektir. Bu EVM talimat kodları, işlemler aracılığıyla paketlenip Ethereum'a yüklenir ve nihayetinde EVM tarafından çözülüp yürütülür.

Solidity derleyici açıklarını EVM'nin kendi açıklarından ayırmak önemlidir. EVM açıkları, sanal makinenin talimatları yürütmesi sırasında ortaya çıkan güvenlik sorunlarını ifade eder. Saldırganlar, Ethereum'a herhangi bir kod yükleyebildikleri için, bu kodlar nihayetinde her Ethereum P2P istemci programında çalışacaktır; eğer EVM'de güvenlik açıkları varsa, bu durum tüm Ethereum ağını etkileyecek ve tüm ağın hizmet reddi (DoS) veya saldırganlar tarafından tamamen kontrol edilmesi gibi sorunlar yaratabilecektir. Ancak, EVM'nin tasarımı görece basit olduğundan ve çekirdek kod sıklıkla güncellenmediğinden, yukarıda belirtilen sorunların ortaya çıkma olasılığı düşüktür.

Solidity derleyici açıkları, derleyicinin Solidity'yi EVM koduna dönüştürmesi sırasında ortaya çıkan sorunlardır. Kullanıcı istemci bilgisayarında JavaScript'i derleyip çalıştıran tarayıcılar gibi senaryoların aksine, Solidity derleme süreci yalnızca akıllı sözleşme geliştiricisinin bilgisayarında gerçekleştirilir ve Ethereum üzerinde çalıştırılmaz. Bu nedenle, Solidity derleyici açıkları Ethereum ağını etkilemez.

Solidity derleyici güvenliğindeki ana tehlikelerden biri, üretilen EVM kodunun akıllı sözleşme geliştiricisinin beklentileriyle uyumsuz olabilmesidir. Ethereum üzerindeki akıllı sözleşmeler genellikle kullanıcıların kripto para varlıklarını içerdiğinden, derleyicinin neden olduğu herhangi bir akıllı sözleşme hatası, kullanıcı varlıklarının kaybına yol açabilir ve ciddi sonuçlar doğurabilir.

Geliştiriciler ve sözleşme denetleyicileri, sözleşme kodu mantığının uygulanmasına, ayrıca yeniden giriş, tam sayı taşması gibi Solidity düzeyindeki güvenlik sorunlarına odaklanabilirler. Ancak Solidity derleyici açıkları için, sözleşme kaynak kodunun mantığını denetlemekle bu açıkları tespit etmek oldukça zordur. Belirli bir derleyici sürümü ve belirli kod kalıpları ile birlikte analiz yapmak, akıllı sözleşmenin derleyici açıklarından etkilenip etkilenmediğini belirlemek için gereklidir.

Solidity Derleyici Açığı Örneği

Aşağıda birkaç gerçek Solidity derleyici açık örneği ile bunların belirli biçimleri, nedenleri ve zararları gösterilmektedir.

SOL-2016-9 YüksekDüzenBaytTemizlemeDepolama

Bu açık, erken dönem Solidity derleyici sürümlerinde bulunmaktadır (>=0.1.6 <0.4.4).

Aşağıdaki kodu dikkate al:

katılık sözleşme C { uint32 a = 0x1234; uint32 b = 0; function f() public { a += 1; } function run() public view returns (uint32) { return b; } }

storage değişkeni b herhangi bir değişiklik geçirmediğinden, run() fonksiyonu varsayılan değer olan 0'ı döndürmelidir. Ancak, güvenlik açığı olan sürüm derleyicisinden üretilen kodda, run() 1 döndürecektir.

Eğer bu derleyici açığını anlamıyorsanız, sıradan geliştiricilerin yukarıdaki kodda bulunan hatayı basit bir kod incelemesiyle bulması oldukça zor olacaktır. Bu sadece basit bir örnektir ve özellikle ciddi sonuçlar doğurmayacaktır. Ancak eğer b değişkeni yetki doğrulama, varlık muhasebesi gibi amaçlar için kullanılıyorsa, bu beklenmeyen tutarsızlık çok ciddi sorunlara yol açabilir.

Bu garip fenomenin nedeni, EVM'nin yığın tabanlı sanal makineyi kullanmasıdır, yığındaki her bir eleman 32 bayt boyutundadır ( yani uint256 değişken boyutudur ). Öte yandan, alt düzey depolama alanı (storage) her bir yuvası da 32 bayt boyutundadır. Solidity dilinde uint32 gibi 32 bayttan küçük çeşitli veri türleri desteklenmektedir, derleyici bu tür değişkenleri işlerken, üst bitlerini uygun şekilde temizleme işlemi yapmalıdır (clean up) veri doğruluğunu sağlamak için. Yukarıda belirtilen durumda, toplama işlemi tam sayı taşması meydana geldiğinde, derleyici sonucu üst bitlerini doğru şekilde temizleyememiştir, bu da taşma sonrası üst bitin storage'a yazılmasına neden olmuş ve nihayetinde a değişkeninin arkasındaki b değişkenini geçersiz kılmış, b değişkeninin değeri 1 olarak değiştirilmiştir.

SOL-2022-4 InlineAssemblyMemorySideEffects

Aşağıdaki kodu düşünün:

katılık sözleşme C { function f() public pure returns (uint) { derleme { mstore(0, 0x42) } uint x; assembly { x := mload(0) } return x; } }

Bu açık, >=0.8.13 <0.8.15 sürümlerindeki derleyicide bulunmaktadır. Solidity derleyicisi, Solidity dilini EVM koduna dönüştürürken yalnızca basit bir çeviri yapmaz. Ayrıca, çeşitli derleme optimizasyon süreçlerini gerçekleştirmek için derin kontrol akışı ve veri analizi yapar, üretilen kodun boyutunu küçültür ve yürütme sürecindeki gaz tüketimini optimize eder. Bu tür optimizasyon işlemleri, çeşitli yüksek düzey dillerin derleyicilerinde oldukça yaygındır, ancak dikkate alınması gereken durumlar çok karmaşık olduğu için hata veya güvenlik açığı oluşturması da oldukça kolaydır.

Yukarıdaki kodun açığı, bu tür optimizasyon işlemlerinden kaynaklanmaktadır. Diyelim ki bir fonksiyonda bellek 0 ofsetindeki verileri değiştiren bir kod vardır, ancak sonrasında bu verileri kullanan hiçbir yer yoksa, o zaman aslında bellek 0'ı değiştiren kod doğrudan kaldırılabilir, böylece gaz tasarrufu sağlanır ve sonrasındaki program mantığını etkilemez.

Bu optimizasyon stratejisi kendisiyle ilgili bir sorun yoktur, ancak spesifik Solidity derleyici kodu uygulamasında, bu tür optimizasyonlar yalnızca tek bir assembly bloğuna uygulanmaktadır. Yukarıdaki PoC koduna göre, bellek 0'ın yazılması ve erişimi iki farklı assembly bloğunda yer almakta, ancak derleyici yalnızca ayrı assembly bloğunu analiz ve optimize etmiştir. İlk assembly bloğunda bellek 0'a yazıldıktan sonra herhangi bir okuma işlemi olmadığı için, bu yazım komutunun gereksiz olduğu belirlenir ve kaldırılır, bu da bir hata oluşturur. Hata versiyonunda f() fonksiyonu 0 döndürecektir, oysa yukarıdaki kodun döndürmesi gereken doğru değer 0x42'dir.

SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Aşağıdaki kodu dikkate alınız:

katılık sözleşme C { function f(string[1] calldata a) external returns (string memory) { return abi.decode(abi.encode(a), (string)); } }

Bu güvenlik açığı >= 0.5.8 < 0.8.16 sürümlerindeki derleyicileri etkilemektedir. Normalde, yukarıdaki koddan dönen a değişkeni "aaaa" olmalıdır. Ancak güvenlik açığı olan sürümde boş bir dize "" dönecektir.

Bu açığın nedeni, Solidity'nin calldata türündeki diziler üzerinde abi.encode işlemi yaparken bazı verileri yanlışlıkla temizlemesi ve bu durumun komşu diğer verileri etkilemesi, bu da kodlama ve çözme sonrası verilerin tutarsız olmasına neden olmasıdır.

Dikkate değer olan, Solidity'nin external call ve emit event gerçekleştirdiğinde, parametreleri otomatik olarak abi.encode etmesidir, bu nedenle yukarıda bahsedilen güvenlik açığının ortaya çıkma olasılığı, sezgisel olarak düşündüğümüzden daha yüksektir.

Güvenlik Tavsiyeleri

Cobo blockchain güvenlik ekibi, Solidity derleyici güvenlik açığı tehdit modelinin analizi ve tarihsel güvenlik açıklarının derlenmesinin ardından, geliştiriciler ve güvenlik personeli için aşağıdaki önerileri sunmaktadır.

Geliştiriciler için:

• Daha yeni bir Solidity derleyici sürümü kullanın. Yeni sürümler yeni güvenlik sorunları getirebilir, ancak bilinen güvenlik sorunları genellikle eski sürümlere göre daha azdır.

• Birim test vakalarını geliştirin. Çoğu derleyici düzeyinde hata, kodun yürütme sonuçlarının beklentilerle tutarsız olmasına neden olur. Bu tür sorunlar, kod incelemesi yoluyla tespit edilmesi zor olup, test aşamasında kolayca ortaya çıkabilir. Bu nedenle, kod kapsama oranını artırarak bu tür sorunların en üst düzeyde önlenmesi sağlanabilir.

• Inline assembly, complex operations such as abi encoding and decoding for multidimensional arrays and complex structures should be avoided as much as possible. Avoid blindly using new language features and experimental functionalities for the sake of show-off when there is no clear requirement. According to Cobo security team's analysis of historical vulnerabilities in Solidity, most vulnerabilities are related to inline assembly, abi encoders, and similar operations. Compilers are indeed more prone to bugs when dealing with complex language features. On the other hand, developers can easily make mistakes when using new features, leading to security issues.

güvenlik personeline:

• Solidity kodunun güvenlik denetimi yapılırken, Solidity derleyicisinin getirebileceği güvenlik risklerini göz ardı etmeyin. Smart Contract Weakness Classification(SWC)'da karşılık gelen kontrol maddesi SWC-102: Eski Derleyici Versiyonu.

• İç SDL geliştirme sürecinde, geliştirme ekibini Solidity derleyici sürümünü yükseltmeye teşvik edin ve CI/CD sürecine derleyici sürümü için otomatik kontrol eklemeyi düşünebilirsiniz.

• Ancak derleyici açıkları konusunda aşırı panik yapmaya gerek yoktur, çoğu derleyici açığı yalnızca belirli kod kalıpları altında tetiklenir ve açık bir sürüm derleyici ile derlenen bir sözleşmenin mutlaka güvenlik riski taşıyacağı anlamına gelmez; gerçek güvenlik etkisi proje durumuna göre özel olarak değerlendirilmelidir.

Pratik Kaynaklar:

• Solidity Ekibi tarafından düzenli olarak yayınlanan Güvenlik Uyarıları gönderileri:

• Solidity resmi repo'sunun düzenli olarak güncellenen hata listesi:

• Tüm sürüm derleyici hata listesi:

Kod sayfasının sağ üst köşesindeki üçgen ünlem işareti, mevcut sürüm derleyicisinde bulunan güvenlik açıklarını gösterir.

Özet

Bu makale, derleyicinin temel kavramlarından yola çıkarak Solidity derleyici açıklarını tanıtmaktadır ve bunların gerçek Ethereum geliştirme ortamında yol açabileceği güvenlik risklerini analiz etmektedir. Son olarak, geliştiriciler ve güvenlik uzmanları için birkaç pratik güvenlik önerisi sunmaktadır.