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 bytecode sanal makinesi tarafından çalıştırılabilir talimat koduna dönüştüren bir bilgisayar programıdır.

Çoğu geliştirici ve güvenlik uzmanı genellikle program uygulama kodunun güvenliğine odaklanırken, derleyicinin kendisinin güvenliğini göz ardı edebilir. Aslında derleyici, bir bilgisayar programı olarak güvenlik açıklarına sahip olabilir ve derleyicinin oluşturduğu güvenlik açıkları bazı durumlarda ciddi güvenlik riskleri doğurabilir. Örneğin, bir tarayıcının Javascript ön uç kodunu derleyip yorumlayarak çalıştırma sürecinde, Javascript yorumlayıcı motorundaki bir açık nedeniyle kullanıcı kötü niyetli bir web sayfasına girdiğinde, saldırgan bu açığı kullanarak uzaktan kod çalıştırma gerçekleştirebilir ve nihayetinde kurbanın tarayıcısını hatta işletim sistemini kontrol altına alabilir. Araştırmalar, Clang C++ derleyicisindeki hataların da uzaktan kod çalıştırma gibi ciddi sonuçlara yol açabileceğini göstermektedir.

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

Solidity derleyici açıkları

Solidity derleyicisinin görevi, 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 kendisindeki açıklarla ayırt etmek gerekir. EVM'nin açıkları, sanal makinenin talimatları yürütürken ortaya çıkan güvenlik açıklarını ifade eder. Saldırganlar Ethereum'a rastgele kod yükleyebildiği için, bu kodlar nihayetinde her Ethereum P2P istemci programında çalışacaktır. Eğer EVM'de bir güvenlik açığı varsa, bu tüm Ethereum ağını etkileyebilir ve ağın tamamen hizmet reddine (DoS) uğramasına neden olabilir, hatta tüm zincirin saldırganlar tarafından tamamen kontrol edilmesine yol açabilir. Ancak EVM'nin kendisi nispeten basit bir tasarıma sahip olduğundan ve ana kodu sık sık güncellenmediğinden, yukarıda belirtilen sorunların ortaya çıkma olasılığı görece düşüktür.

Solidity derleyici hatası, derleyicinin Solidity'yi EVM koduna dönüştürürken var olan bir hatadır. Kullanıcı istemci bilgisayarında Javascript'i derleyip çalıştıran tarayıcılar gibi bir senaryodan farklı olarak, Solidity derleme süreci yalnızca akıllı sözleşme geliştiricisinin bilgisayarında gerçekleşir ve Ethereum üzerinde çalışmaz. Bu nedenle, Solidity derleyici hataları Ethereum ağını doğrudan etkilemez.

Solidity derleyici açıklarının bir ana tehlikesi, üretilen EVM kodunun akıllı sözleşme geliştiricilerinin beklediği şekilde olmamasıdır. Ethereum üzerindeki akıllı sözleşmeler genellikle kullanıcıların kripto para varlıklarını içerdiğinden, derleyicinin akıllı sözleşmelerde yarattığı herhangi bir hata kullanıcı varlıklarının kaybına neden olabilir ve ciddi sonuçlar doğurabilir.

Geliştiriciler ve sözleşme denetleyicileri, sözleşme kodu mantığının uygulanmasıyla ilgili sorunlara, ayrıca yeniden giriş, tam sayı taşması gibi Solidity düzeyindeki güvenlik sorunlarına odaklanabilir. Ancak, Solidity derleyici açıklarını yalnızca sözleşme kaynak kodu mantığının denetimiyle tespit etmek zordur. Akıllı sözleşmenin derleyici açıklarından etkilenip etkilenmediğini belirlemek için belirli derleyici sürümü ve belirli kod modellerinin birlikte analiz edilmesi gerekir.

Solidity derleyici açık örneği

Aşağıda birkaç gerçek Solidity derleyici açığı örneği ile, Solidity derleyici açıklarının spesifik biçimleri, nedenleri ve tehlikeleri sergilenmektedir.

( SOL-2016-9 YüksekDüzenBaytTemizlemeDepolama

Bu güvenlik açığı daha erken 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 = 0x12345678; uint16 b = 0x1234;

function f() public { a = a + 1; }

function run() public view returns (uint16) { return b; } }

Bu nedenle storage değişkeni b herhangi bir değişiklik olmadan, run() fonksiyonu varsayılan değer olan 0'ı döndürmelidir. Ancak, hatalı bir derleyici sürümünden üretilen kodda, run() 1 döndürecektir.

Bu derleyici açığını anlamadan, sıradan geliştiricilerin basit bir kod incelemesi ile yukarıdaki kodda bulunan hatayı tespit etmesi zordur. Yukarıdaki kod sadece basit bir örnektir, bu nedenle özellikle ciddi bir tehlike oluşturmaz. Ancak 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 sonuçlara yol açabilir.

Yukarıda belirtilen anormalliklerin nedeni, EVM'nin yığın tabanlı sanal makine 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 slot için de 32 bayt boyutundadır. Ancak Solidity dilinde uint32 gibi 32 bayttan daha küçük veri türleri desteklenmektedir; derleyici bu tür değişkenleri işlerken, yüksek bitlerini uygun şekilde temizleme işlemi yapmalıdır (clean up), verilerin doğruluğunu sağlamak için. Yukarıdaki durumda toplama işlemi sırasında tam sayı taşması gerçekleştiğinde, derleyici sonucu yüksek bitlerinin temizlenmesini doğru bir şekilde gerçekleştiremediği için, taşma sonrası yüksek bitteki 1 bit storage'a yazılmış, bu da a değişkeninin arkasındaki b değişkeninin üzerine yazarak b değişkeninin değerinin 1 olarak değiştirilmesine neden olmuştur.

( SOL-2022-4 InlineAssemblyMemorySideEffects

Bu güvenlik açığı >=0.8.13 <0.8.15 versiyonlarındaki derleyicide mevcuttur. Solidity derleyicisi, Solidity dilini EVM koduna dönüştürürken sadece basit bir çeviri yapmakla kalmaz. Aynı zamanda derin kontrol akışı ve veri analizleri yaparak, üretilen kodun boyutunu azaltmak ve yürütme sürecindeki gaz tüketimini optimize etmek için çeşitli derleme optimizasyon süreçlerini gerçekleştirir. Bu tür optimizasyon işlemleri, çeşitli yüksek seviyeli 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şması da kolaydır.

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

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

Yukarıdaki kodun açığı, derleme optimizasyon işlemlerinden kaynaklanmaktadır. Bazı durumlarda, eğer bir fonksiyonda bellek 0 offsetindeki veriyi değiştiren kod varsa, ancak sonrasında bu verinin kullanıldığı hiçbir yer yoksa, o zaman 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 stratejisinin kendisinde bir sorun yok, ancak belirli Solidity derleyici kodu uygulamasında, bu tür optimizasyon yalnızca tek bir assembly bloğu içinde uygulanmaktadır. Yukarıdaki örnek kodda, hafıza 0'a yazma ve erişim iki farklı assembly bloğunda bulunmaktadır, ancak derleyici yalnızca ayrı assembly bloğunu analiz optimizasyonuna tabi tutmuştur. İ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; bu da bir hataya yol açar. Açık olan sürümde, f( fonksiyonu 0 değerini döndürecektir, halbuki 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ümündeki derleyicileri etkilemektedir. Aşağıdaki kodu dikkate alın:

katılık contract C { function f(bytes calldata data) external pure returns ###bytes memory( { bytes4) bellek a = [bytes4(data)]; return abi.encode[1]a(; } }

Normal şartlar altında, yukarıdaki kod a değişkeninin "aaaa" olması gerektiğini döndürür. Ancak, bir güvenlik açığı bulunan versiyonda boş bir dize "" dönecektir.

Bu açığın nedeni, Solidity'nin calldata türündeki dizilere abi.encode işlemi uygularken, bazı verileri yanlışlıkla temizlemesi ve bu durumun yanındaki diğer verileri değiştirmesi, bu nedenle kodlama ve kod çözme sonrası verilerin tutarsız hale gelmesidir.

Dikkate değer bir nokta, Solidity'nin external call ve emit event işlemleri sırasında parametreleri gizlice abi.encode etmesidir, bu nedenle yukarıda belirtilen açık kodunun ortaya çıkma olasılığı, sezgisel olarak düşündüğümüzden daha yüksektir.

Bu açık, gerçek geliştirme senaryolarında derleyici açıklarının akıllı sözleşmeler üzerindeki etkisini gösteren 0ctf 2022'nin tanınmış bir güvenlik yarışması blockchain sorusuna dönüştürüldü.

![Solidity derleyici açığı analizi ve önleme yöntemleri])https://img-cdn.gateio.im/webp-social/moments-c97428f89ed62d5ad8551cdb2ba30867.webp(

Güvenlik Önerileri

Solidity derleyici açıklarına yönelik tehditler ve bunlarla başa çıkma konusunda aşağıdaki öneriler verilebilir:

Geliştiricilere:

• 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üzeyindeki hata, kodun çalıştırma sonucunun beklentilerle uyumsuz olmasına neden olur. Bu tür sorunlar, kod incelemesi sırasında tespit edilmesi zor olsa da, test aşamasında kolayca ortaya çıkabilir. Bu nedenle, kod kapsamını artırmak bu tür sorunları en aza indirmek için en iyi yoldur.

• Inline assembly kullanmaktan, çok boyutlu diziler ve karmaşık yapıların abi kod çözümü gibi karmaşık işlemlerden mümkün olduğunca kaçınılmalıdır, net bir ihtiyaç yoksa dilin yeni özelliklerini ve deneysel işlevlerini körü körüne kullanmaktan kaçınılmalıdır. Çoğu güvenlik açığı, inline assembly, abi kodlayıcı gibi işlemlerle ilgilidir. Derleyici karmaşık dil özelliklerini işlerken daha fazla hata yapma olasılığı taşır. Öte yandan, geliştiricilerin yeni özellikleri kullanırken yanlış yönlendirilmesi güvenlik sorunlarına yol açabilir.

Güvenlik personeline:

• Solidity kodunu güvenlik denetiminden geçirirken, 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'dur.

• İç güvenlik geliştirme süreçlerinde, geliştirme ekibini Solidity derleyici sürümünü güncellemeye teşvik edin ve CI/CD süreçlerine derleyici sürümü için otomatik kontroller eklemeyi düşünün.

• Ancak derleyici açıkları hakkında aşırı endişelenmeye gerek yoktur, çoğu derleyici açığı yalnızca belirli kod dizilimlerinde tetiklenir. Açık içeren bir derleyici versiyonu ile derlenmiş olan sözleşmelerin mutlaka güvenlik riski taşıdığı söylenemez, gerçek güvenlik etkilerini değerlendirmek için spesifik proje durumuna göre analiz yapılması gerekmektedir.

Bazı pratik kaynaklar:

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

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

• Her versiyon için derleyici hata listesi:

Kod sayfasının sağ üst köşesindeki üçgen ünlem simgesi, mevcut sürüm derleyicisinde var olan güvenlik açıklarını gösterebilir.

Özet

Bu makale, Solidity derleyici açıklarının kavramını tanıtmakta, bunların Ethereum geliştirme ortamında neden olabileceği güvenlik risklerini analiz etmekte ve geliştiricilere ve güvenlik uzmanlarına pratik güvenlik önerileri sunmaktadır. Derleyici açıkları yaygın olmasa da, etkileri çok ciddi olabilir ve bu nedenle geliştiricilerin ve güvenlik uzmanlarının dikkatini çekmektedir.

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