Solidity Derleyici Açıkları Analizi ve Baş Etme Stratejileri

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

Geliştiricilerin ve güvenlik uzmanlarının genellikle uygulama kodunun güvenliğine odaklansa da, derleyicinin kendisinin güvenliği de göz ardı edilemez. Bir bilgisayar programı olarak derleyicilerin de güvenlik açıkları olabilir ve bu açıklar bazı durumlarda ciddi güvenlik riskleri doğurabilir. Örneğin, tarayıcı, Javascript ön yüz kodunu derleyip çözümlerken, Javascript çözümleme motorundaki bir açık nedeniyle kullanıcılar kötü niyetli bir web sayfasını ziyaret ettiklerinde saldırganlar tarafından uzaktan kod çalıştırma yeteneği elde edilebilir ve bu da kurbanın tarayıcısının hatta tüm işletim sisteminin kontrolünü ele geçirmesine yol açabilir.

Solidity derleyicisi de bir istisna değil, farklı sürümlerinde güvenlik açıkları bulunmaktadır.

Solidity Derleyici Açığı

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

Dikkat edilmesi gereken nokta, Solidity derleyici açıklarının EVM'nin kendisindeki açıklarla farklı olduğudur. EVM açıkları, sanal makinenin talimatları yürütürken ortaya çıkan güvenlik sorunlarını ifade eder. Saldırganlar, Ethereum ağına herhangi bir kod yükleyebildiklerinden, 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, ağın hizmet reddi (DoS) yaşamasına veya tüm blok zincirinin saldırganlar tarafından kontrol altına alınmasına yol açabilir. Ancak, EVM'nin tasarımı nispeten basit olduğundan ve ana kodu sık sık güncellenmediğinden, bu tür sorunların ortaya çıkma olasılığı düşüktür.

Solidity derleyici hataları, derleyicinin Solidity kodunu EVM koduna dönüştürürken karşılaştığı sorunlardır. JavaScript'in kullanıcı istemci bilgisayarında derlenip çalıştırıldığı durumların aksine, Solidity'nin derleme süreci yalnızca akıllı sözleşme geliştiricisinin bilgisayarında gerçekleşir ve Ethereum ağı üzerinde yürütülmez. Bu nedenle, Solidity derleyici hataları doğrudan Ethereum ağını etkilemez.

Solidity derleyici hatalarının en büyük tehlikelerinden biri, üretilen EVM kodunun akıllı sözleşme geliştiricilerinin beklentileriyle uyuşmamasıdır. 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 neden olabilir ve bu da 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 odaklanabilir. Ancak, yalnızca sözleşme kaynak kodu mantığının denetimi ile Solidity derleyicisinin açıklarını tespit etmek zordur. Akıllı sözleşmenin derleyici açıklarından etkilenip etkilenmediğini belirlemek için belirli bir derleyici sürümü ile belirli kod kalıplarının birlikte analiz edilmesi gerekir.

Solidity Derleyici Açığı Örneği

Aşağıda, belirli biçimlerini, nedenlerini ve zararlarını gösteren birkaç gerçek Solidity derleyici açığı örneği bulunmaktadır.

SOL-2016-9 YüksekDüzenBaytTemizlemeDepolama

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

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

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

Buradaki storage değişkeni b herhangi bir değişiklik geçirmediği için run() fonksiyonu varsayılan değer 0'ı döndürmelidir. Ancak, açık sürüm derleyicisi tarafından üretilen kodda, run() gerçekte 1 döndürmektedir.

Sıradan geliştiricilerin yukarıda belirtilen koddaki sorunları basit bir kod incelemesi ile bulması zordur. Bu örnek nispeten basit olsa da, özellikle ciddi sonuçlara yol açmayabilir; ancak eğer b değişkeni yetkilendirme, varlık muhasebesi gibi kritik amaçlar için kullanılıyorsa, bu beklenmeyen durum ciddi güvenlik açıklarına yol açabilir.

Bu problemin kökeni EVM'nin yığın tabanlı sanal makine kullanmasındadır. Yığındaki her bir eleman 32 byte boyutundadır (yani uint256 değişken boyutu). Alt düzey depolama alanı (storage) her slot da 32 byte boyutundadır. Solidity dili, uint32 gibi 32 byte'tan daha küçük çeşitli veri türlerini desteklemektedir. Derleyici, bu tür değişkenleri işlerken, verilerin doğruluğunu sağlamak için yüksek bitlerini uygun şekilde temizleme (clean up) işlemi yapmak zorundadır. Yukarıdaki durumda, toplama işlemi sırasında tam sayı taşması meydana geldiğinde, derleyici sonucu yüksek bitlerini doğru bir şekilde temizleyemedi ve taşma sonrasında yüksek bitteki 1, depolama alanına yazıldı. Sonuç olarak, a değişkeninin arkasındaki b değişkeni üzerini kapladı ve b değişkeninin değeri 1 olarak değiştirildi.

SOL-2022-4 InlineAssemblyMemorySideEffects

Bu güvenlik açığı >=0.8.13 <0.8.15 versiyonlarındaki derleyicide bulunmaktadır. Aşağıdaki kodu dikkate alalım:

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

Solidity derleyicisi, Solidity dilini EVM koduna dönüştürme sürecinde, sadece basit bir çeviri yapmaz. Aynı zamanda derin kontrol akışı ve veri analizi gerçekleştirir, üretilen kodun boyutunu küçültmek ve yürütme sürecindeki gaz tüketimini optimize etmek için çeşitli derleme optimizasyon süreçleri uygular. 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 oldukça karmaşık olduğundan, hata veya güvenlik açığı oluşma olasılığı yüksektir.

Yukarıdaki kodun açığı bu tür optimizasyon işlemlerinden kaynaklanmaktadır. Derleyici, eğer bir fonksiyonda bellek 0 ofsetindeki verileri değiştiren bir kod varsa fakat sonrasında bu verilerin kullanıldığı hiçbir yer yoksa, o zaman bellek 0'ı değiştiren kodu doğrudan kaldırabileceğini düşünür. Böylece gas tasarrufu sağlanır ve sonrasındaki program mantığını etkilemez.

Bu optimizasyon stratejisinin kendisinde bir sorun yoktur, ancak belirli Solidity derleyici kodu uygulamasında, bu tür optimizasyon yalnızca tek bir assembly bloğuna uygulanmaktadır. Yukarıda belirtilen PoC kodunda, hafıza 0'a yazma ve erişme işlemleri iki farklı assembly bloğu içinde bulunmaktadır, ancak derleyici yalnızca ayrı bir assembly bloğunu analiz ve optimizasyon yapmıştır. İlk assembly bloğunda hafıza 0'a yazıldıktan sonra herhangi bir okuma işlemi olmadığı için, bu yazma komutunun gereksiz olduğu belirlenir ve bu komut kaldırılır, böylece bir hata oluşur. Açık olan versiyonda f() fonksiyonu 0 dönecek, oysa yukarıdaki kodun döndürmesi gereken doğru değer 0x42'dir.

SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Bu açık, >= 0.5.8 < 0.8.16 sürümündeki derleyicileri etkilemektedir. Aşağıdaki kodu dikkate alın:

katılık contract C { function f(string[1] calldata a) external pure returns (string memory) { return abi.decode(abi.encode(a), (string[1]))[0]; } }

Normal şartlarda, yukarıdaki kodun döndürdüğü a değişkeni "aaaa" olmalıdır. Ancak, açık bulunan sürümde boş bir dize "" döndürülecektir.

Bu açığın nedeni, Solidity'nin calldata türündeki dizilere abi.encode işlemi yaparken bazı verileri yanlışlıkla temizlemesidir. Bu durum, bitişik diğer verilerin değiştirilmesine yol açarak kodlama ve çözme sonrası verilerin tutarsız olmasına neden olmuştur.

Dikkat edilmesi gereken bir nokta, Solidity'nin external call ve emit event işlemlerinde parametreleri abi.encode ile örtük olarak işlediğidir. Bu nedenle, yukarıda belirtilen güvenlik açığının ortaya çıkma olasılığı, sezgisel olarak düşündüğümüzden daha yüksektir.

Güvenlik Önerileri

Solidity derleyicisi güvenlik açığı tehdit modelinin analizi ve geçmiş güvenlik açıklarının incelenmesi sonucunda, geliştiriciler ve güvenlik uzmanlarına aşağıdaki önerilerde bulunuyoruz.

Geliştiricilere:

1. Daha yeni bir Solidity derleyici sürümü kullanın. Yeni sürümler yeni güvenlik sorunları ortaya çıkarabilse de, bilinen güvenlik sorunları genellikle daha eski sürümlerde daha fazladır.

2. Birim test durumlarını iyileştirin. Çoğu derleyici düzeyindeki hata, kodun çalışma sonucunun beklenenden farklı olmasına neden olur. Bu tür sorunlar kod incelemesi ile tespit edilmesi zor olsa da, test aşamasında kolayca ortaya çıkabilir. Bu nedenle, kod kapsama oranını artırarak bu tür sorunları en aza indirmek mümkündür.

3. İnline assembly, çok boyutlu diziler ve karmaşık yapıların abi kodlama ve kod çözme gibi karmaşık işlemlerini kullanmaktan kaçınılmalıdır; açık bir ihtiyaç olmadıkça, dilin yeni özelliklerini ve deneysel işlevlerini körü körüne kullanarak gösteriş yapmaktan kaçının. Tarihsel güvenlik açıkları incelendiğinde, çoğu açık inline assembly, abi kodlayıcı gibi işlemlerle ilişkilidir. Derleyici, karmaşık dil özelliklerini işlerken daha fazla hata yapma eğilimindedir. Öte yandan, geliştiriciler yeni özellikleri kullanırken kullanım hataları yapma eğilimindedirler ve bu da güvenlik sorunlarına yol açabilir.

Güvenlik Personeline:

1. Solidity kodunu güvenlik denetiminden geçirirken, Solidity derleyicisinin getirebileceği güvenlik risklerini göz ardı etmeyin. Smart Contract Weakness Classification (SWC)'deki ilgili kontrol maddesi SWC-102: Eski Derleyici Sürümü.

2. İçerideki SDL geliştirme sürecinde, geliştirme ekibini Solidity derleyici sürümünü güncellemeye teşvik edin ve CI/CD sürecinde derleyici sürümü için otomatik kontrol eklemeyi düşünebilirsiniz.

3. Ancak derleyici açıkları konusunda aşırı panik yapmaya gerek yoktur, çünkü çoğu derleyici açığı sadece belirli kod desenlerinde tetiklenir ve açık bir derleyici sürümünü kullanarak derlenen bir sözleşmenin mutlaka güvenlik riski taşıdığı anlamına gelmez; gerçek güvenlik etkisi proje durumuna göre özel olarak değerlendirilmelidir.

Pratik Kaynaklar

• Solidity ekibi düzenli olarak güvenlik uyarı makaleleri yayımlamaktadır.
• Solidity resmi deposunun düzenli olarak güncellenen hata listesi
• Her sürüm derleyici hata listesi. Buna göre CI/CD sürecinde derleyici versiyonunu otomatik kontrol etmek için dahil edilebilir, mevcut sürümdeki güvenlik açıklarını bildirebilir. Code sayfasının sağ üst köşesindeki üçgen ünlem simgesi, 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ştiricilere ve güvenlik uzmanlarına birkaç pratik güvenlik önerisi sunmaktadır. Bu açıkları anlamak ve uygun önleyici önlemleri almak suretiyle, akıllı sözleşmelerin güvenliğini daha iyi koruyabilir ve potansiyel varlık kaybı riskini azaltabiliriz.