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

Derleyici, modern bilgisayar sistemlerinin temel bileşenlerinden biridir. İnsanların anlaması ve yazması kolay olan yüksek seviyeli programlama dili kaynak kodunu, bilgisayarın alt düzey CPU'su veya bayt kodu sanal makinesinin çalıştırılabilir 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üvenliğini göz ardı edebilir. Aslında, bir bilgisayar programı olarak derleyicilerin de güvenlik açıkları vardır ve bu açıklar bazı durumlarda ciddi güvenlik riskleri doğurabilir. Örneğin, bir tarayıcının Javascript ön uç kodunu derleyip analiz ederek çalıştırması sürecinde, Javascript analiz motorundaki bir açığın varlığı, kullanıcıların kötü niyetli web sitelerine erişmesi durumunda saldırganların açıkları kullanarak uzaktan kod çalıştırmasına neden olabilir ve bu da mağdurun tarayıcısının hatta işletim sisteminin kontrolünü ele geçirmesine yol açabilir.

Solidity derleyicisi de istisna değildir, farklı sürümlerde 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 ayrıştırılıp yürütülür.

Solidity derleyici açıklarını EVM'nin kendi açıklarından ayırmak gerekmektedir. EVM açıkları, sanal makinenin komutları yürütürken ortaya çıkan güvenlik sorunlarını ifade eder. Saldırganların Ethereum'a istedikleri kodu yükleyebilmeleri nedeniyle, bu kodlar nihayetinde her Ethereum P2P istemci programında çalışacaktır; eğer EVM'de güvenlik açığı varsa, bu durum tüm Ethereum ağını etkileyebilir ve ağın tamamen hizmet dışı kalmasına neden olabilir (DoS) hatta tüm zincirin saldırganlar tarafından ele geçirilmesine yol açabilir. Ancak, EVM'nin tasarımı nispeten basit olduğu ve çekirdek kodu sık sık güncellenmediği için, yukarıda belirtilen sorunların ortaya çıkma olasılığı görece daha 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ı senaryosunun aksine, Solidity derleme süreci yalnızca akıllı sözleşme geliştiricisinin bilgisayarında gerçekleşir ve Ethereum'da çalışmaz. Bu nedenle, Solidity derleyici açıkları doğrudan Ethereum ağını etkilemez.

Solidity derleyici açıklarının en büyük tehlikelerinden biri, üretilen EVM kodunun akıllı sözleşme geliştiricilerinin beklentileriyle tutarsız 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ık kaybına yol açabilir ve ciddi sonuçlar doğurabilir.

Geliştiriciler ve sözleşme denetçileri, sözleşme kodu mantık uygulama sorunlarına ve reentrancy, tam sayı taşması gibi Solidity düzeyindeki güvenlik sorunlarına odaklanabilirler. Ancak, Solidity derleyicisi ile ilgili açıklar yalnızca sözleşme kaynak kodu mantığının denetimi ile tespit edilmesi zor olan durumlardır. Akıllı sözleşmenin derleyici açıklarından etkilenip etkilenmediğini belirlemek için belirli derleyici sürümü ile belirli kod kalıplarının birlikte analiz edilmesi gerekir.

Solidity Derleyici Açığı Örneği

Aşağıda birkaç gerçek Solidity derleyici açığını örnek olarak göstererek, bunların belirli şekilleri, nedenleri ve zararları sergilenecektir.

SOL-2016-9 YüksekSıraBaytTemizlemeDepolama

Bu güvenlik açığı daha eski Solidity derleyici sürümlerinde bulunmaktadır (>=0.1.6 <0.4.4).

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

katılık contract C { uint32 a = 0x1234; uint32 b = 0; function f() public { a += 1; } function run() public view returns (uint) { return b; } }

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

Bu derleyici açığının ne olduğunu anlamadan, sıradan geliştiricilerin yukarıdaki kodda bulunan hatayı basit bir kod incelemesiyle tespit etmesi zor olacaktır. Bu örnek kod oldukça basit, dolayısıyla özellikle ciddi bir zarara yol açmayabilir. Ancak eğer b değişkeni yetki doğrulama, varlık muhasebesi gibi amaçlar için kullanılıyorsa, beklenmeyen bu tutarsızlık son derece ciddi sonuçlara yol açabilir.

Bu tür bir anomaliyi üreten neden, EVM'nin yığın tabanlı sanal makine kullanmasıdır; yığındaki her bir eleman 32 byte boyutundadır ( yani uint256 değişken boyutudur ). Öte yandan, alt düzey depolama storage'ın her bir slotu da 32 byte boyutundadır. Solidity dilinde uint32 gibi 32 byte'tan küçük çeşitli veri türleri desteklenmektedir; derleyici bu tür değişkenleri işlerken, yüksek bitlerini uygun şekilde temizleme işlemi yapması gerekmektedir (clean up) verinin doğruluğunu sağlamak için. Yukarıdaki durumda, toplama işlemi sırasında tam sayı taşması meydana geldiğinde, derleyici sonucu yüksek bitlerini düzgün bir şekilde temizlememiştir; bu, taşma sonrası yüksek 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

Bu güvenlik açığı >=0.8.13 <0.8.15 sürümündeki derleyicide bulunmaktadır. Aşağıdaki kodu düşünün:

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

Solidity derleyicisi, Solidity dilini EVM koduna dönüştürme sürecinde sadece basit bir çeviri yapmakla kalmaz. Ayrıca, derin kontrol akışı ve veri analizi gerçekleştirir, üretilen kodun boyutunu azaltmak ve yürütme sürecindeki gaz tüketimini optimize etmek için çeşitli derleme optimizasyon süreçlerini uygular. Bu tür optimizasyon işlemleri, çeşitli yüksek seviyeli dillerin derleyicilerinde oldukça yaygındır, ancak dikkate alınması gereken durumların oldukça karmaşık olması nedeniyle hata veya güvenlik açığı oluşması da oldukça kolaydır.

Yukarıdaki kodun açığı, bu tür optimizasyon işlemlerinden kaynaklanmaktadır. Şöyle bir durumu düşünün: Eğer bir fonksiyonda bellek 0 ofsetindeki veriyi değiştiren bir kod varsa, ancak sonrasında bu veriyi 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ğlanmış olur ve sonrasındaki program mantığını etkilemez.

Bu optimizasyon stratejisinin kendisinde bir sorun yok, ancak belirli Solidity derleyici kodu uygulamasında, bu tür optimizasyonlar yalnızca tek bir assembly bloğuna uygulanmaktadır. Yukarıdaki örnek kodda, hafıza 0'a yazma ve erişim iki farklı assembly bloğunda bulunmaktadır ve derleyici yalnızca ayrı assembly bloğuna analiz optimizasyonu uygulamıştır. İlk assembly bloğunda hafıza 0'a yazdıktan sonra herhangi bir okuma işlemi olmadığı için, bu yazma komutunun gereksiz olduğu tespit edilmekte ve bu komut kaldırılmaktadır, bu da bir hataya yol açmaktadır. Açık bulunan sürümde, f( fonksiyonu 0 değeri döndürecek, oysaki yukarıdaki kodun doğru bir şekilde 0x42 değerini döndürmesi gerekir.

) SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Bu güvenlik açığı >= 0.5.8 < 0.8.16 sürümlerindeki derleyicileri etkilemektedir. Aşağıdaki kodu göz önünde bulundurun:

katılık contract C { function f###uint8( calldata a[4] public pure returns )string memory( { return string)abi.encode(a(); } }

Normal şartlar altında, yukarıdaki kodun döndürdüğü a değişkeni "aaaa" olmalıdır. Ancak, açık içeren sürümde boş bir dize "" döndürecektir.

Bu açığın nedeni, Solidity'nin calldata türündeki dizilere abi.encode işlemi yaparken, bazı verileri hatalı bir şekilde temizlemesidir. Bu durum, komşu diğer verilerin değiştirilmesine yol açarak, kodlama ve kod çözme sonrası veriler arasında tutarsızlığa neden olmuştur.

Dikkate değer bir nokta, Solidity'nin external call ve emit event işlemleri sırasında parametreleri abi.encode ile örtük olarak kodlamasıdır; bu nedenle, yukarıda belirtilen güvenlik açığının ortaya çıkma olasılığı, sezgisel olarak düşündüğünüzden daha yüksektir.

![Solidity Derleyici Açığı Analizi ve Önlemleri])https://img-cdn.gateio.im/webp-social/moments-c97428f89ed62d5ad8551cdb2ba30867.webp(

Güvenlik Önerileri

Solidity derleyici açıkları tehdit modeli analizi ve tarihsel açıkların incelenmesine dayanarak, geliştiriciler ve güvenlik personeline aşağıdaki önerilerde bulunulmuştur.

Geliştiricilere:

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

• Birim test durumlarını geliştirin. Çoğu derleyici düzeyindeki hata, kodun çalışma sonuçlarının beklenenle uyuşmamasına neden olur. Bu tür sorunlar kod incelemesi ile tespit edilmesi zor ancak test aşamasında kolayca ortaya çıkabilir. Bu nedenle, kod kapsamını artırarak bu tür sorunların en aza indirilmesi 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 pursuing language new features and experimental functions without clear requirements. According to the analysis of historical vulnerabilities, most vulnerabilities are related to inline assembly and ABI encoder operations. Compilers indeed tend to have more bugs when dealing with complex language features. On the other hand, developers are also prone to misuse when using new features, leading to security issues.

Güvenlik personeline:

• Solidity kodunun güvenlik denetimi yapılırken, Solidity derleyicisinin potansiyel güvenlik risklerini göz ardı etmeyin. Smart Contract Weakness Classification)SWC('da ilgili kontrol maddesi SWC-102: Eski Derleyici Versiyonu'dur.

• İç SDL geliştirme sürecinde, geliştirme ekibini Solidity derleyici sürümünü güncellemeye teşvik edin ve CI/CD sürecine derleyici sürümüne yönelik otomatik kontroller eklemeyi düşünebilirsiniz.

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

Bazı kullanışlı kaynaklar:

• Solidity ekibi tarafından düzenli olarak yayınlanan güvenlik uyarıları:

• Solidity resmi deposunda düzenli olarak güncellenen hata listesi:

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

Code 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 başlayarak, Solidity derleyici açıklarını tanıtmaktadır ve bunların gerçek Ethereum geliştirme ortamında neden olabileceği güvenlik risklerini analiz etmektedir. Son olarak, geliştiriciler ve güvenlik uzmanları için birkaç pratik güvenlik önerisi sunulmaktadır.

![Solidity derleyici açığı analizi ve önlemleri])https://img-cdn.gateio.im/webp-social/moments-84f5083d8748f2aab71fd92671d999a7.webp(