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

Derleyici, modern bilgisayar sistemlerinin temel bileşenlerinden biridir. İnsanlar tarafından anlaşılabilir yüksek seviyeli programlama dillerini, bilgisayarın çalıştırabileceği düşük seviyeli talimatlara dönüştürür. Geliştiriciler ve güvenlik uzmanları genellikle uygulama kodunun güvenliğine odaklansa da, derleyicinin kendisinin güvenlik sorunları da göz ardı edilmemelidir. Derleyici açıkları bazı durumlarda ciddi güvenlik risklerine yol açabilir.

Örneğin bir tarayıcıda, JavaScript kodunu işlerken JavaScript motorundaki bir güvenlik açığı, kullanıcıların kötü niyetli web sitelerine erişmesi durumunda uzaktan kod yürütme saldırılarına maruz kalmasına neden olabilir ve bu durum, saldırganın kurbanın tarayıcısını hatta işletim sistemini kontrol etmesine yol açabilir. Ayrıca, C++ derleyicisindeki bir hata da uzaktan kod yürütme gibi ciddi sonuçlara yol açabilir.

Solidity derleyicisi de bir istisna değildir, birden fazla sürümde güvenlik açıkları bulunmaktadır. Solidity derleyicisinin işlevi, akıllı sözleşme kodunu Ethereum sanal makinesi (EVM) talimat koduna dönüştürmektir, bu talimatlar nihayetinde EVM'de 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ütmesi sırasında ortaya çıkan güvenlik sorunlarını ifade eder ve bu, tüm Ethereum ağı üzerinde etkili olabilir. Solidity derleyici açıkları ise, Solidity'nin EVM koduna dönüştürülmesi sırasında meydana gelen sorunlardır.

Solidity derleyici hatalarının bir tehlikesi, üretilen EVM kodunun geliştiricilerin beklentileriyle uyuşmamasıdır. Akıllı sözleşmeler genellikle kullanıcıların kripto para varlıklarını içerdiğinden, derleyiciden kaynaklanan herhangi bir hata kullanıcı varlık kaybına yol açabilir ve sonuçları oldukça ciddi olabilir. Geliştiriciler ve denetçiler genellikle sözleşme mantığının uygulanmasına ve yaygın hatalara odaklanırken, derleyici hatalarının belirli sürüm ve kod kalıplarıyla birlikte analiz edilmesi gerekmektedir.

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

SOL-2016-9 YüksekDüzenByteTemizlemeDepolama

Bu açık, daha eski versiyonlardaki Solidity derleyicisinde 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; uint32 b = 0; function f() public { a = a + 1; } function run() public view returns (uint32) { return b; } }

Değişken b değiştirilmeden, run() fonksiyonu varsayılan değer 0'ı döndürmelidir. Ancak, hata içeren sürüm derleyici tarafından üretilen kodda, run() 1 döndürecektir.

Bu tutarsızlık, basit bir kod incelemesi ile tespit edilmesi zor. Örnek kodun etkisi sınırlı olsa da, eğer b değişkeni yetkilendirme veya varlık muhasebesi için kullanılıyorsa, sonuçlar son derece ciddi olacaktır.

Bu sorunun nedeni, EVM'nin 32 bayt boyutunda yığın öğeleri kullanması ve alt düzey depolamanın her bir slotunun da 32 bayt olmasıdır. Solidity, uint32 gibi 32 bayttan daha küçük veri türlerini destekler, derleyici bu türleri işlerken yüksek bitleri temizlemek için (clean up) veri doğruluğunu sağlamak amacıyla gereklidir. Bu durumda, toplama taşması sonrası derleyici sonucu yüksek bitleri doğru bir şekilde temizlemedi, bu da taşan 1 bitin depolamaya yazılmasına ve b değişkenini üzerine yazmasına neden oldu.

SOL-2022-4 InlineAssemblyMemoryYanEtkileri

Bu güvenlik açığı 0.8.13 ile 0.8.15 versiyonları arasındaki derleyicide bulunmaktadır. Aşağıdaki kodu dikkate alınız:

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; } }

Solidity derleyicisi, oluşturulan kodun boyutunu azaltmak ve gaz tüketimini optimize etmek için derin kontrol akışı ve veri analizi yapar. Bu tür bir optimizasyon yaygın olmasına rağmen, durumun karmaşık olması nedeniyle hata veya güvenlik açığı ortaya çıkabilir.

Yukarıdaki kodun sorunu, bu tür optimizasyondan kaynaklanmaktadır. Derleyici, eğer bir fonksiyon bellek 0 ofsetindeki verileri değiştiriyorsa, ancak sonrasında bu veriler kullanılmıyorsa, gaz tasarrufu sağlamak için değişiklik talimatlarını kaldırabileceğini düşünmektedir. Ancak bu optimizasyon yalnızca tek bir assembly bloğu içinde uygulanır.

Bu örnekte, bellek 0'ın yazımı ve erişimi iki farklı assembly bloğunda yer almaktadır. Derleyici yalnızca ayrı assembly bloklarını analiz etti ve ilk bloktaki yazımın gereksiz olduğuna karar vererek bunu kaldırdı, bu da bir hata ortaya çıkardı. Hatalı sürümde f() fonksiyonu 0 dönecek, oysa doğru dönen değer 0x42 olmalıdır.

SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Bu güvenlik açığı 0.5.8 ile 0.8.16 sürümleri arasındaki derleyicileri etkilemektedir. Aşağıdaki kodu dikkate alın:

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

Normal şartlarda, bu kod a değişkeninin değerini "aaaa" olarak döndürmelidir. Ancak, açık olan versiyonda boş bir dize "" döndürülecektir.

Sorun, Solidity'nin calldata türündeki diziler üzerinde abi.encode işlemi yaparken bazı verileri yanlışlıkla temizlemesi ve bu durumun komşu verileri değiştirmesi, sonuç olarak kodlama ve kod çözme sonrası verilerin tutarsız olmasına neden olmasıdır.

Dikkat edilmesi gereken bir nokta, Solidity'nin external call ve emit event işlemleri sırasında parametreleri otomatik olarak abi.encode etmesidir. Bu nedenle, bu açığın etkisi beklenenden daha büyük olabilir.

Güvenlik Önerileri

Solidity derleyici açıklarının analizi temelinde, geliştiricilere ve güvenlik uzmanlarına aşağıdaki önerilerde bulunulmaktadır:

Geliştiriciler için:

• Daha yeni bir Solidity derleyici sürümü kullanın. Yeni sürümler yeni sorunlar getirebilir, ancak bilinen güvenlik sorunları genellikle daha azdır.
• Birim testlerini geliştirin. Çoğu derleyici seviyesindeki hata, yürütme sonuçlarının beklentilerle uyuşmamasına neden olur, bu sorunlar kod incelemesi ile tespit edilmesi zor, ancak testlerde kolayca ortaya çıkabilir. Kod kapsamını artırmak, bu tür sorunları en üst düzeyde önlemeye yardımcı olabilir.
• Inline assembly, karma ABI kodlama ve çözme gibi karmaşık işlemlerden kaçının, yeni özellikleri ve deneysel fonksiyonları körü körüne kullanmayın. Çoğu tarihsel açık bu karmaşık işlemlerle ilgilidir.

Güvenlik personeline:

• Denetim sırasında derleyicinin 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 ekibinin derleyici sürümünü güncellemesini sağlamak ve CI/CD'de derleyici sürümünün otomatik kontrolünü sağlamayı düşünmek.
• Derleyici açıkları konusunda aşırı endişelenmeye gerek yok. Çoğu açık yalnızca belirli kod kalıpları altında tetiklenir, açık bir sürümle derlenmiş sözleşmelerin mutlaka risk taşıdığı söylenemez, duruma göre değerlendirilmelidir.

Bazı pratik kaynaklar:

• Solidity ekibi tarafından düzenli olarak yayınlanan güvenlik uyarıları
• Solidity resmi deposunda düzenli olarak güncellenen hata listesi
• Farklı sürüm derleyici hata listesi, CI/CD içinde otomatik kontrol için kullanılabilir.
• Etherscan sözleşme kodu sayfasının sağ üst köşesindeki uyarı simgesi, mevcut sürüm derleyicisindeki güvenlik açıklarını gösterebilir.

Özet

Bu makalede Solidity derleyici açıklarının kavramı tanıtılmakta, bunların Ethereum geliştirmedeki potansiyel güvenlik riskleri analiz edilmekte ve geliştiricilere ile güvenlik uzmanlarına pratik güvenlik önerileri sunulmaktadır. Derleyici açıkları nadir olsa da, derin etkilere sahiptir ve geliştirme ile güvenlik ekiplerinin dikkatini çekmeye değerdir.