Solidity Derleyici Açıkları Detaylı İnceleme ve Yanıt Stratejileri
Derleyici, modern bilgisayar sistemlerinin temel bileşenlerinden biridir. Bu, bilgisayar programıdır ve ana işlevi, yüksek seviyeli programlama dilinin kaynak kodunu bilgisayarın alt düzey CPU'su veya sanal makinesi tarafından çalıştırılabilir talimat koduna dönüştürmektir.
Çoğu geliştirici ve güvenlik uzmanı genellikle uygulama kodunun güvenliğine odaklansa da, derleyicinin güvenliği de aynı derecede önemlidir. Bir bilgisayar programı olarak, derleyicinin de güvenlik açıkları olabilir ve bazı durumlarda ciddi güvenlik riskleri oluşturabilir. Örneğin, bir tarayıcı JavaScript ön uç kodunu derleyip çözümlemeden önce, JavaScript çözümleme motorundaki bir güvenlik açığı nedeniyle kullanıcılar kötü niyetli bir web sayfasını ziyaret ettiklerinde saldırganlar tarafından hedef alınabilir ve sonunda kurbanın tarayıcısına hatta işletim sistemine kontrol sağlanabilir.
Solidity derleyicisinde de güvenlik açıkları bulunmaktadır. Solidity geliştirme ekibinin güvenlik uyarısına göre, farklı sürümlerdeki Solidity derleyicilerinde güvenlik sorunları tespit edilmiştir.
Solidity derleyici açığı
Solidity derleyicisinin ana işlevi, 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 Ethereum'a paketlenip yüklenir ve nihayetinde EVM tarafından çözülüp yürütülür.
Dikkat edilmesi gereken husus, Solidity derleyici açıklarının EVM'nin kendi açıklarından farklı olduğudur. EVM açıkları, sanal makinenin talimatları yürütmesi sırasında ortaya çıkan güvenlik sorunlarını ifade eder. Saldırganların Ethereum'a istedikleri kodu yükleyebilmesi nedeniyle, EVM'de bir güvenlik açığı varsa, bu durum tüm Ethereum ağını etkileyebilir, hizmet reddi (DoS) ve hatta tüm blok zincirinin saldırganlar tarafından ele geçirilmesine yol açabilir. Ancak, EVM tasarımı nispeten basittir, temel kod güncellemeleri sık sık yapılmaz, bu nedenle bu tür sorunların ortaya çıkma olasılığı düşüktür.
Solidity derleyici açığı, derleyicinin Solidity kodunu EVM koduna dönüştürürken karşılaştığı sorunları ifade eder. Kullanıcı istemcisinde JavaScript'in derlenip çalıştırılması durumunun aksine, Solidity'nin derleme süreci yalnızca akıllı sözleşme geliştiricisinin bilgisayarında gerçekleşir ve Ethereum üzerinde çalıştırılmaz. Bu nedenle, Solidity derleyici açıkları doğrudan Ethereum ağını etkilemez.
Solidity derleyici hatalarının başlıca tehlikelerinden biri, üretilen EVM kodunun geliştiricinin beklediğiyle tutarsız olabilmesidir. Ethereum üzerindeki akıllı sözleşmeler genellikle kullanıcıların kripto para varlıklarını içerdiğinden, derleyici kaynaklı herhangi bir 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 denetleyicileri, genellikle sözleşme kodunun mantıksal uygulanmasıyla ilgili sorunlara ve reentrancy, tam sayı taşması gibi Solidity düzeyindeki güvenlik sorunlarına odaklanabilirler. Ancak, derleyici açıkları genellikle yalnızca sözleşme kaynak kodunu denetleyerek tespit edilmesi zor olan sorunlardır. Akıllı sözleşmenin derleyici açıklarından etkilenip etkilenmediğini belirlemek için belirli bir derleyici sürümü ve belirli kod kalıplarıyla birlikte analiz yapılması gerekmektedir.
Solidity derleyici güvenlik 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 açık, erken dönem Solidity derleyici sürümlerinde bulunmaktadır (>=0.1.6 <0.4.4).
Aşağıdaki kodu göz önünde bulundurun:
katılık
sözleşme C {
uint32 a = 0x12345678;
uint32 b = 0;
function f() public {
a = 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 0'ı döndürmelidir. Ancak, açık sürüm derleyicisi tarafından üretilen kodda, run() 1 döndürecektir.
Bu derleyici açığını anlamadan, sıradan geliştiricilerin basit bir kod incelemesi ile bu hatayı bulmaları zor. Bu örnek nispeten basit olsa da, özellikle ciddi sonuçlar doğurmaz; ancak, e değişkeni yetki doğrulama, varlık muhasebesi gibi amaçlar için kullanılıyorsa, beklenmeyen bu tutarsızlık çok ciddi sonuçlara yol açabilir.
Bu fenomenin nedeni, 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 seviye depolama alanındaki her slot da 32 byte boyutundadır. Solidity dili uint32 gibi 32 byte'tan daha küçük veri türlerini destekler. Derleyici bu türleri işlerken, yüksek bitlerini uygun şekilde temizleme işlemi yapması gerekmektedir (clean up) veri doğruluğunu sağlamak için. Yukarıda belirtilen durumda, toplama işlemi sonucunda tam sayı taşması gerçekleştiğinde, derleyici sonucu yüksek bitini doğru bir şekilde temizleyemediği için, taşma sonrası yüksek bitin 1'i storage'a yazıldı ve bu da a değişkeninin arkasındaki b değişkenini geçersiz kıldı, 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 sürümündeki derleyicilerde 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 yalnızca basit bir çeviri yapmakla kalmaz, aynı zamanda derin kontrol akışı ve veri analizi gerçekleştirerek, üretilen kodun boyutunu azaltmak ve yürütme sürecindeki gaz tüketimini optimize etmek için çeşitli derleme optimizasyonları uygular. Bu tür optimizasyonlar, çeşitli yüksek seviyeli dillerin derleyicilerinde oldukça yaygındır, ancak dikkate alınması gereken durumların karmaşık olması nedeniyle hata veya güvenlik açığı oluşma olasılığı yüksektir.
Yukarıdaki kodun açığı, bu tür optimizasyon işlemlerinden kaynaklanmaktadır. Eğer bir fonksiyonda bellek 0 offsetindeki verileri değiştiren bir kod varsa, ancak daha sonra bu veriler kullanılmıyorsa, o zaman bellek 0'ı değiştiren kodu doğrudan kaldırarak gas tasarrufu sağlamak mümkündür ve bu, sonraki program mantığını etkilemez.
Bu optimizasyon stratejisi kendisi açısından bir sorun teşkil etmemektedir, ancak belirli Solidity derleyici uygulamalarında, bu tür optimizasyonlar yalnızca tek bir assembly bloğuna uygulanmaktadır. Yukarıdaki PoC kodu için, bellek 0'a yazma ve erişim iki farklı assembly bloğunda bulunmaktadır ve derleyici yalnızca ayrı assembly bloğu üzerinde analiz ve optimizasyon yapmıştır. İlk assembly bloğunda bellek 0'a yazıldıktan sonra herhangi bir okuma işlemi yapılmadığı için, bu yazma komutu gereksiz olarak değerlendirilmekte ve kaldırılmaktadır, bu da bir hataya yol açmaktadır. Açık olan sürümde f() fonksiyonu 0 döndürecektir, oysaki doğru dönen değer 0x42 olmalıdır.
Bu güvenlik açığı, >= 0.5.8 < 0.8.16 sürümlerindeki derleyicileri etkilemektedir.
Aşağıdaki kodu dikkate al:
katılik
sözleşme C {
function f(string[1] calldata a) public pure returns (string memory) {
return abi.decode(abi.encode(a), (string[1]))[0];
}
}
Normal koşullarda, yukarıdaki kodun döndürdüğü a değişkeni "aaaa" olmalıdır. Ancak açığın bulunduğu versiyonda boş bir dize "" döndürülmektedir.
Bu açığın nedeni, Solidity'nin calldata türündeki diziler üzerinde abi.encode işlemi yaparken bazı verileri yanlışlıkla temizlemesidir; bu da komşu diğer verilerin değiştirilmesine yol açmış ve kodlama ile çözme sonrası verilerin tutarsız olmasına neden olmuştur.
Dikkat edilmesi gereken bir nokta, Solidity'nin external call ve emit event işlemleri sırasında, parametreleri aslında abi.encode ile gizli bir şekilde işlediğidir. Bu nedenle, yukarıda belirtilen güvenlik açığı kodunun ortaya çıkma olasılığı, sezgisel olarak düşündüğümüzden daha yüksektir.
Güvenlik Önerileri
Solidity derleyici açıkları tehdidi için 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. Daha yeni sürümler yeni güvenlik sorunları getirebilir, ancak bilinen güvenlik sorunları genellikle daha eski sürümlerde daha azdır.
Birim test senaryolarını iyileştirin. Çoğu derleyici düzeyindeki hata, kodun yürütme sonucunun beklentilerle uyuşmamasına neden olur. Bu tür sorunlar, kod incelemesi ile tespit edilmesi zor olsa da, test aşamasında ortaya çıkma olasılığı yüksektir. Kod kapsamını artırmak, bu tür sorunları en aza indirmeye yardımcı olabilir.
İç içe montaj, çok boyutlu diziler ve karmaşık yapıların ABI kodlama ve kod çözme gibi karmaşık işlemleri kullanmaktan kaçının; açık bir ihtiyaç yoksa dilin yeni özelliklerini ve deneysel işlevlerini körü körüne kullanmaktan kaçının. Tarihteki çoğu güvenlik açığı iç içe montaj, ABI kodlayıcıları gibi işlemlerle ilgilidir. Derleyici, karmaşık dil özelliklerini işlerken daha fazla hata yapma eğilimindedir. Öte yandan, geliştiriciler yeni özellikleri kullanırken de yanlış kullanımlara düşebilir ve bu durum güvenlik sorunlarına yol açabilir.
Güvenlik personeline:
Solidity kodunu güvenlik denetiminden geçirirken, 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 Sürümü.
İç SDL geliştirme sürecinde, geliştirme ekibini Solidity derleyici sürümünü yükseltmeye teşvik edin ve CI/CD sürecinde derleyici sürümü için otomatik kontrol getirmeyi düşünebilirsiniz.
Ancak derleyici açıkları konusunda aşırı panik yapmaya gerek yok; çoğu derleyici açığı yalnızca belirli kod kalıplarında 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.
Bazı pratik kaynaklar:
Solidity Ekibi'nin düzenli olarak yayınladığı Security Alerts gönderileri
Solidity resmi repo'sunun düzenli olarak güncellenen hata listesi
Tüm versiyonların derleyici hata listesi. CI/CD sürecinde derleyici sürüm kontrolü otomatik olarak yapılabilir ve mevcut sürümdeki güvenlik açıkları hakkında uyarılar verilebilir.
Kod sayfasının sağ üst köşesindeki üçgen ünlem işareti, mevcut sürüm derleyicisinde bulunan güvenlik açıklarını gösterebilir.
Özet
Bu makale, derleyicinin temel kavramlarından yola çıkarak, Solidity derleyici açıklarını tanıtmaktadır, bunların gerçek Ethereum geliştirme ortamında neden olabileceği güvenlik risklerini analiz etmekte ve geliştiriciler ile güvenlik uzmanlarına bazı pratik güvenlik önerileri sunmaktadır. Derleyici açıklarını anlamak ve önemsemek, akıllı sözleşmelerin güvenliğini daha kapsamlı bir şekilde sağlamaya yardımcı olabilir.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
18 Likes
Reward
18
9
Share
Comment
0/400
DAOplomacy
· 07-11 19:33
tartışmasız bir yönetişim perspektifinden başka bir alt-optimal uygulama...
View OriginalReply0
LightningLady
· 07-11 19:11
Bizim için birkaç derleme açığı olması neyi değiştirir?
View OriginalReply0
SandwichDetector
· 07-10 06:32
Bu da bizim yaptığımız iş değil mi?
View OriginalReply0
GateUser-00be86fc
· 07-08 20:59
Derleyicinin de denetlenmesi gerekiyor.
View OriginalReply0
CryptoTherapist
· 07-08 20:58
bu derleyici kaygısını işlemek için dikkatli bir an alalım... açıkçası klasik sistem travması gibi hissediyor
View OriginalReply0
CryptoPhoenix
· 07-08 20:56
Kaynak kodu, kaynağından daha kaynaştırıcıdır; düşüşe geçenler sonunda yeniden doğacaktır.
View OriginalReply0
OnlyOnMainnet
· 07-08 20:50
Yine kafa yakacak kod yazmam gerekecek.
View OriginalReply0
FrogInTheWell
· 07-08 20:47
Neyse ki artık kodu sol yazmıyorum.
View OriginalReply0
GasGuzzler
· 07-08 20:30
Vulnog Dog, denetim yapmak için insanları tekrar çağırmaya başlayacak.
Solidity Derleyici Açığı Analizi ve Önleme Stratejileri
Solidity Derleyici Açıkları Detaylı İnceleme ve Yanıt Stratejileri
Derleyici, modern bilgisayar sistemlerinin temel bileşenlerinden biridir. Bu, bilgisayar programıdır ve ana işlevi, yüksek seviyeli programlama dilinin kaynak kodunu bilgisayarın alt düzey CPU'su veya sanal makinesi tarafından çalıştırılabilir talimat koduna dönüştürmektir.
Çoğu geliştirici ve güvenlik uzmanı genellikle uygulama kodunun güvenliğine odaklansa da, derleyicinin güvenliği de aynı derecede önemlidir. Bir bilgisayar programı olarak, derleyicinin de güvenlik açıkları olabilir ve bazı durumlarda ciddi güvenlik riskleri oluşturabilir. Örneğin, bir tarayıcı JavaScript ön uç kodunu derleyip çözümlemeden önce, JavaScript çözümleme motorundaki bir güvenlik açığı nedeniyle kullanıcılar kötü niyetli bir web sayfasını ziyaret ettiklerinde saldırganlar tarafından hedef alınabilir ve sonunda kurbanın tarayıcısına hatta işletim sistemine kontrol sağlanabilir.
Solidity derleyicisinde de güvenlik açıkları bulunmaktadır. Solidity geliştirme ekibinin güvenlik uyarısına göre, farklı sürümlerdeki Solidity derleyicilerinde güvenlik sorunları tespit edilmiştir.
Solidity derleyici açığı
Solidity derleyicisinin ana işlevi, 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 Ethereum'a paketlenip yüklenir ve nihayetinde EVM tarafından çözülüp yürütülür.
Dikkat edilmesi gereken husus, Solidity derleyici açıklarının EVM'nin kendi açıklarından farklı olduğudur. EVM açıkları, sanal makinenin talimatları yürütmesi sırasında ortaya çıkan güvenlik sorunlarını ifade eder. Saldırganların Ethereum'a istedikleri kodu yükleyebilmesi nedeniyle, EVM'de bir güvenlik açığı varsa, bu durum tüm Ethereum ağını etkileyebilir, hizmet reddi (DoS) ve hatta tüm blok zincirinin saldırganlar tarafından ele geçirilmesine yol açabilir. Ancak, EVM tasarımı nispeten basittir, temel kod güncellemeleri sık sık yapılmaz, bu nedenle bu tür sorunların ortaya çıkma olasılığı düşüktür.
Solidity derleyici açığı, derleyicinin Solidity kodunu EVM koduna dönüştürürken karşılaştığı sorunları ifade eder. Kullanıcı istemcisinde JavaScript'in derlenip çalıştırılması durumunun aksine, Solidity'nin derleme süreci yalnızca akıllı sözleşme geliştiricisinin bilgisayarında gerçekleşir ve Ethereum üzerinde çalıştırılmaz. Bu nedenle, Solidity derleyici açıkları doğrudan Ethereum ağını etkilemez.
Solidity derleyici hatalarının başlıca tehlikelerinden biri, üretilen EVM kodunun geliştiricinin beklediğiyle tutarsız olabilmesidir. Ethereum üzerindeki akıllı sözleşmeler genellikle kullanıcıların kripto para varlıklarını içerdiğinden, derleyici kaynaklı herhangi bir 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 denetleyicileri, genellikle sözleşme kodunun mantıksal uygulanmasıyla ilgili sorunlara ve reentrancy, tam sayı taşması gibi Solidity düzeyindeki güvenlik sorunlarına odaklanabilirler. Ancak, derleyici açıkları genellikle yalnızca sözleşme kaynak kodunu denetleyerek tespit edilmesi zor olan sorunlardır. Akıllı sözleşmenin derleyici açıklarından etkilenip etkilenmediğini belirlemek için belirli bir derleyici sürümü ve belirli kod kalıplarıyla birlikte analiz yapılması gerekmektedir.
Solidity derleyici güvenlik 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 açık, erken dönem Solidity derleyici sürümlerinde bulunmaktadır (>=0.1.6 <0.4.4).
Aşağıdaki kodu göz önünde bulundurun:
katılık sözleşme C { uint32 a = 0x12345678; uint32 b = 0; function f() public { a = 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 0'ı döndürmelidir. Ancak, açık sürüm derleyicisi tarafından üretilen kodda, run() 1 döndürecektir.
Bu derleyici açığını anlamadan, sıradan geliştiricilerin basit bir kod incelemesi ile bu hatayı bulmaları zor. Bu örnek nispeten basit olsa da, özellikle ciddi sonuçlar doğurmaz; ancak, e değişkeni yetki doğrulama, varlık muhasebesi gibi amaçlar için kullanılıyorsa, beklenmeyen bu tutarsızlık çok ciddi sonuçlara yol açabilir.
Bu fenomenin nedeni, 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 seviye depolama alanındaki her slot da 32 byte boyutundadır. Solidity dili uint32 gibi 32 byte'tan daha küçük veri türlerini destekler. Derleyici bu türleri işlerken, yüksek bitlerini uygun şekilde temizleme işlemi yapması gerekmektedir (clean up) veri doğruluğunu sağlamak için. Yukarıda belirtilen durumda, toplama işlemi sonucunda tam sayı taşması gerçekleştiğinde, derleyici sonucu yüksek bitini doğru bir şekilde temizleyemediği için, taşma sonrası yüksek bitin 1'i storage'a yazıldı ve bu da a değişkeninin arkasındaki b değişkenini geçersiz kıldı, 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 sürümündeki derleyicilerde 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 yalnızca basit bir çeviri yapmakla kalmaz, aynı zamanda derin kontrol akışı ve veri analizi gerçekleştirerek, üretilen kodun boyutunu azaltmak ve yürütme sürecindeki gaz tüketimini optimize etmek için çeşitli derleme optimizasyonları uygular. Bu tür optimizasyonlar, çeşitli yüksek seviyeli dillerin derleyicilerinde oldukça yaygındır, ancak dikkate alınması gereken durumların karmaşık olması nedeniyle hata veya güvenlik açığı oluşma olasılığı yüksektir.
Yukarıdaki kodun açığı, bu tür optimizasyon işlemlerinden kaynaklanmaktadır. Eğer bir fonksiyonda bellek 0 offsetindeki verileri değiştiren bir kod varsa, ancak daha sonra bu veriler kullanılmıyorsa, o zaman bellek 0'ı değiştiren kodu doğrudan kaldırarak gas tasarrufu sağlamak mümkündür ve bu, sonraki program mantığını etkilemez.
Bu optimizasyon stratejisi kendisi açısından bir sorun teşkil etmemektedir, ancak belirli Solidity derleyici uygulamalarında, bu tür optimizasyonlar yalnızca tek bir assembly bloğuna uygulanmaktadır. Yukarıdaki PoC kodu için, bellek 0'a yazma ve erişim iki farklı assembly bloğunda bulunmaktadır ve derleyici yalnızca ayrı assembly bloğu üzerinde analiz ve optimizasyon yapmıştır. İlk assembly bloğunda bellek 0'a yazıldıktan sonra herhangi bir okuma işlemi yapılmadığı için, bu yazma komutu gereksiz olarak değerlendirilmekte ve kaldırılmaktadır, bu da bir hataya yol açmaktadır. Açık olan sürümde f() fonksiyonu 0 döndürecektir, oysaki doğru dönen değer 0x42 olmalıdır.
SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup
Bu güvenlik açığı, >= 0.5.8 < 0.8.16 sürümlerindeki derleyicileri etkilemektedir.
Aşağıdaki kodu dikkate al:
katılik sözleşme C { function f(string[1] calldata a) public pure returns (string memory) { return abi.decode(abi.encode(a), (string[1]))[0]; } }
Normal koşullarda, yukarıdaki kodun döndürdüğü a değişkeni "aaaa" olmalıdır. Ancak açığın bulunduğu versiyonda boş bir dize "" döndürülmektedir.
Bu açığın nedeni, Solidity'nin calldata türündeki diziler üzerinde abi.encode işlemi yaparken bazı verileri yanlışlıkla temizlemesidir; bu da komşu diğer verilerin değiştirilmesine yol açmış ve kodlama ile çözme sonrası verilerin tutarsız olmasına neden olmuştur.
Dikkat edilmesi gereken bir nokta, Solidity'nin external call ve emit event işlemleri sırasında, parametreleri aslında abi.encode ile gizli bir şekilde işlediğidir. Bu nedenle, yukarıda belirtilen güvenlik açığı kodunun ortaya çıkma olasılığı, sezgisel olarak düşündüğümüzden daha yüksektir.
Güvenlik Önerileri
Solidity derleyici açıkları tehdidi için 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. Daha yeni sürümler yeni güvenlik sorunları getirebilir, ancak bilinen güvenlik sorunları genellikle daha eski sürümlerde daha azdır.
Birim test senaryolarını iyileştirin. Çoğu derleyici düzeyindeki hata, kodun yürütme sonucunun beklentilerle uyuşmamasına neden olur. Bu tür sorunlar, kod incelemesi ile tespit edilmesi zor olsa da, test aşamasında ortaya çıkma olasılığı yüksektir. Kod kapsamını artırmak, bu tür sorunları en aza indirmeye yardımcı olabilir.
İç içe montaj, çok boyutlu diziler ve karmaşık yapıların ABI kodlama ve kod çözme gibi karmaşık işlemleri kullanmaktan kaçının; açık bir ihtiyaç yoksa dilin yeni özelliklerini ve deneysel işlevlerini körü körüne kullanmaktan kaçının. Tarihteki çoğu güvenlik açığı iç içe montaj, ABI kodlayıcıları gibi işlemlerle ilgilidir. Derleyici, karmaşık dil özelliklerini işlerken daha fazla hata yapma eğilimindedir. Öte yandan, geliştiriciler yeni özellikleri kullanırken de yanlış kullanımlara düşebilir ve bu durum güvenlik sorunlarına yol açabilir.
Güvenlik personeline:
Solidity kodunu güvenlik denetiminden geçirirken, 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 Sürümü.
İç SDL geliştirme sürecinde, geliştirme ekibini Solidity derleyici sürümünü yükseltmeye teşvik edin ve CI/CD sürecinde derleyici sürümü için otomatik kontrol getirmeyi düşünebilirsiniz.
Ancak derleyici açıkları konusunda aşırı panik yapmaya gerek yok; çoğu derleyici açığı yalnızca belirli kod kalıplarında 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.
Bazı pratik kaynaklar:
Özet
Bu makale, derleyicinin temel kavramlarından yola çıkarak, Solidity derleyici açıklarını tanıtmaktadır, bunların gerçek Ethereum geliştirme ortamında neden olabileceği güvenlik risklerini analiz etmekte ve geliştiriciler ile güvenlik uzmanlarına bazı pratik güvenlik önerileri sunmaktadır. Derleyici açıklarını anlamak ve önemsemek, akıllı sözleşmelerin güvenliğini daha kapsamlı bir şekilde sağlamaya yardımcı olabilir.