Uniswap v4 yakında piyasaya sürülüyor, Hook mekanizması güvenlik riskleri barındırıyor
Uniswap v4 yakında piyasaya sürülecek, bu güncelleme her işlem çifti için sonsuz sayıda likidite havuzu ve dinamik ücretler, tekil tasarım, flaş muhasebe, Hook mekanizması ve ERC1155 token standardına destek gibi birçok yeni özellik getiriyor. v4'ün Ethereum Cancun güncellemesinden sonra piyasaya sürülmesi bekleniyor.
Birçok yenilik arasında, Hook mekanizması güçlü potansiyeli nedeniyle büyük ilgi görmektedir. Likidite havuzunun yaşam döngüsündeki belirli zaman noktalarında özel kodların yürütülmesine olanak tanır ve bu da havuzun ölçeklenebilirliğini ve esnekliğini büyük ölçüde artırır.
Ancak, Hook mekanizması çift taraflı bir kılıç olabilir. Güçlü ve esnek olmasına rağmen, Hook'u güvenli bir şekilde kullanmak da zorluklarla karşı karşıyadır. Hook'un karmaşıklığı kaçınılmaz olarak yeni potansiyel saldırı vektörlerini beraberinde getirmektedir. Bu nedenle, Hook mekanizmasıyla ilgili güvenlik sorunlarını ve potansiyel riskleri sistematik bir şekilde tanıtmak son derece önemlidir; bu, daha güvenli bir Uniswap v4 Hook inşa etmeye yardımcı olacaktır.
Bu makalede Uniswap v4'teki Hook mekanizmasının ilgili kavramları tanıtılacak ve mevcut güvenlik riskleri özetlenecektir.
Uniswap V4'ün mekanizması
Derinlemesine tartışmadan önce, Uniswap v4'ün mekanizması hakkında temel bir anlayışa ihtiyaç duyuyoruz. Resmi duyurular ve beyaz kitaplara göre, Hook, tekil mimari ve anlık muhasebe, özel likidite havuzları oluşturma ve birden fazla havuzda verimli yönlendirme sağlama konusunda üç önemli işlevdir.
Kanca
Hook, likidite fon havuzunun yaşam döngüsünün farklı aşamalarında çalışan bir sözleşmeyi ifade eder. Uniswap ekibi, Hook'u tanıtarak herkesin denge kararları alabilmesini ummaktadır. Bu yöntem, dinamik ücretlerin yerel olarak desteklenmesini, zincir üstü limit emir eklemeyi veya zaman ağırlıklı ortalama yapıcı (TWAMM) büyük siparişleri dağıtmak için kullanmayı mümkün kılabilir.
Şu anda dört gruba ayrılmış sekiz Hook geri çağrısı var ( her grup bir çift geri çağrı içeriyor ):
beforeInitialize/afterInitialize
beforeModifyPosition/afterModifyPosition
beforeSwap/afterSwap
beforeDonate/afterDonate
Singleton, yıldırım muhasebesi ve kilit mekanizması
Singleton mimarisi ve hızlı muhasebe, maliyetleri azaltarak ve verimliliği sağlayarak performansı artırmayı amaçlamaktadır. Tüm likidite havuzlarının aynı akıllı sözleşme içinde saklandığı yeni bir singleton sözleşmesi tanıtmaktadır. Bu singleton tasarımı, tüm havuzların durumunu depolamak ve yönetmek için bir PoolManager'a dayanır.
v4 sürümü, ışık muhasebesi ve kilitleme mekanizmasını tanıttı. Kilitleme mekanizmasının çalışma şekli şöyledir:
locker sözleşmesi PoolManager üzerinde lock talep eder.
PoolManager, bu locker sözleşmesinin adresini lockData kuyruğuna ekler ve lockAcquired geri çağrısını çağırır.
locker sözleşmesi geri çağırma sırasında mantığını yürütür. Yürütme sürecinde, locker sözleşmesinin havuzla etkileşimi sıfırdan farklı para artışlarına neden olabilir. Ancak, yürütme sona erdiğinde, tüm artışlar sıfıra eşitlenmelidir. Ayrıca, eğer lockData kuyruğu boş değilse, yalnızca son locker sözleşmesi işlem yapabilir.
PoolManager, lockData kuyruğunu ve para artışının durumunu kontrol eder. Doğrulandıktan sonra, PoolManager o locker sözleşmesini kaldıracaktır.
Sonuç olarak, kilit mekanizması eşzamanlı erişimi önler ve tüm işlemlerin tasfiye edilmesini garanti eder. locker sözleşmesi kilit için sırayla başvurur, ardından lockAcquired geri çağrısıyla işlemi gerçekleştirir. Her havuz işlemi öncesi ve sonrasında ilgili Hook geri çağrısı tetiklenir. Son olarak, PoolManager durumu kontrol eder.
Bu yöntem, işlemin ayarladığı şeyin iç net bakiye ( yani delta ) olduğu anlamına gelir, anlık transfer gerçekleştirilmez. Herhangi bir değişiklik, havuzun iç bakiyesinde kaydedilir, gerçek transfer ise işlem ( yani lock ) sona erdiğinde gerçekleştirilir. Bu süreç, açığa çıkmamış token olmadığını garanti eder, böylece fonların bütünlüğü korunur.
Kilitleme mekanizmasının varlığı nedeniyle, dışarıdaki tüm hesaplar (EOA) doğrudan PoolManager ile etkileşime giremez. Bunun yerine, herhangi bir etkileşim bir sözleşme aracılığıyla gerçekleştirilmelidir. Bu sözleşme, herhangi bir havuz işlemi gerçekleştirilmeden önce lock talep edilmesi gereken ara bir locker olarak işlev görür.
İki ana sözleşme etkileşim senaryosu vardır:
locker sözleşmesi resmi kod deposundan veya kullanıcı tarafından dağıtılan bir sözleşmeden gelmektedir. Bu durumda, etkileşimi bir yönlendirici aracılığıyla gerçekleştirdiğimizi düşünebiliriz.
locker sözleşmesi ve Hook'un aynı sözleşme içinde entegre edilmesi ya da üçüncü taraf bir varlık tarafından kontrol edilmesi durumudur. Bu durumda etkileşimi Hook aracılığıyla geçiş olarak görebiliriz. Bu durumda Hook, hem locker sözleşmesinin rolünü üstlenir hem de geri çağırmayı işlemekten sorumludur.
Tehdit Modeli
İlgili güvenlik sorunlarını tartışmadan önce, tehdit modelini belirlememiz gerekiyor. Ana olarak aşağıdaki iki durumu dikkate alıyoruz:
Tehdit modeli I: Hook kendisi iyidir, ancak bir güvenlik açığı bulunmaktadır.
Tehdit Modeli II: Hook kendisi kötü niyetlidir.
Sonraki bölümde, bu iki tehdit modeli temelinde potansiyel güvenlik sorunlarını tartışacağız.
Tehdit Modeli I'ndeki güvenlik sorunları
Tehdit modeli I, Hook ile ilgili açıkları dikkate alır. Bu tehdit modeli, geliştiricinin ve Hook'un kötü niyetli olmadığını varsayar. Ancak, akıllı sözleşmelerdeki mevcut bilinen açıklar Hook'ta da ortaya çıkabilir.
Uniswap v4'teki Hook, çekirdek havuz işlemleri ('de özelleştirilmiş mantığı uygulamak için, başlangıç, konum değiştirme, takas yapma ve ) toplama gibi işlemlerden önce veya sonra çalışabilen bir akıllı sözleşmedir. Hook'un standart bir arayüz sağlaması bekleniyor olsa da, özelleştirilmiş mantığın da dahil edilmesine izin vermektedir. Bu nedenle, tartışmamız standart Hook arayüzü ile ilgili mantıkla sınırlı olacaktır. Ardından, Hook'un bu standart Hook fonksiyonlarını nasıl kötüye kullanabileceği gibi potansiyel açık kaynaklarını bulmaya çalışacağız.
Özellikle, aşağıdaki iki tür Hook'a odaklanacağız:
İlk tür hook, kullanıcı fonlarını saklamaktır. Bu durumda, saldırgan bu hook'u hedef alabilir ve fonları transfer ederek varlık kaybına neden olabilir.
İkinci tür hook, kullanıcıların veya diğer protokollerin bağımlı olduğu kritik durum verilerini saklar. Bu durumda, saldırgan kritik durumu değiştirmeye çalışabilir. Diğer kullanıcılar veya protokoller yanlış durumu kullandığında, potansiyel riskler ortaya çıkabilir.
Awesome Uniswap v4 Hooks deposunun derinlemesine incelenmesi sonucunda, birkaç ciddi güvenlik açığı tespit ettik. Bu açıklar, esasen hook, PoolManager ve dış üçüncü taraflar arasındaki risk etkileşimlerinden kaynaklanıyor ve temel olarak iki ana kategoriye ayrılabiliyor: erişim kontrolü sorunları ve girdi doğrulama sorunları.
Genel olarak, 22 ilgili proje ( Uniswap v4 ile ilgisi olmayan projeler ) hariç tutulmuştur. Bu projeler arasında, 8 tanesinin (36%) güvenlik açığı içerdiğini düşünüyoruz. Bu 8 güvenlik açığı olan projeden 6'sında erişim kontrol sorunları, 2'sinde ise güvenilmeyen dış çağrılara karşı hassasiyet bulunmaktadır.
Erişim kontrolü sorunu
Bu bölümde, v4'teki geri çağırma fonksiyonlarının neden olabileceği sorunlara odaklanıyoruz, bunlar arasında 8 adet hook geri çağırma ve lock geri çağırma bulunmaktadır. Bu fonksiyonlar yalnızca PoolManager tarafından çağrılmalıdır, diğer adresler ( dahil EOA ve sözleşmeler ) tarafından çağrılamaz. Örneğin, ödüller fon havuz anahtarı ile dağıtıldığında, ilgili fonksiyon herhangi bir hesap tarafından çağrılabiliyorsa, ödüller yanlış bir şekilde alınabilir.
Bu nedenle, hook için güçlü bir erişim kontrol mekanizması oluşturmak kritik öneme sahiptir, özellikle de bunların havuzun kendisi dışında başka taraflar tarafından çağrılabilmesidir. Erişim izinlerini sıkı bir şekilde yöneterek, likidite havuzları, hook'un yetkisiz etkileşimler veya kötü niyetli etkileşimler ile ilgili riskini önemli ölçüde azaltabilir.
Giriş doğrulama sorunu
Uniswap v4'te, bir kilitleme mekanizması bulunduğundan, kullanıcıların herhangi bir havuz işlemi gerçekleştirmeden önce sözleşmeden bir lock alması gerekmektedir. Bu, etkileşimde bulunan mevcut sözleşmenin en son locker sözleşmesi olduğunu garanti eder.
Yine de, bazı savunmasız Hook uygulamalarında giriş doğrulamasının yetersiz olması nedeniyle güvenilmeyen dış çağrılarla sonuçlanabilecek bir olası saldırı senaryosu bulunmaktadır:
Öncelikle, hook kullanıcının etkileşimde bulunmayı düşündüğü likidite havuzunu doğrulamıyor. Bu, sahte tokenler içeren ve zararlı mantık yürüten kötü niyetli bir likidite havuzu olabilir.
İkincisi, bazı anahtar hook fonksiyonları herhangi bir dış çağrıya izin verir.
Güvenilmeyen dış çağrılar son derece tehlikelidir, çünkü çeşitli türde saldırılara yol açabilir, bunlar arasında iyi bildiğimiz yeniden giriş saldırısı da bulunmaktadır.
Bu savunmasız hook'lara saldırmak için, bir saldırgan sahte token'ı için kötü niyetli bir fon havuzu kaydedebilir ve ardından hook'u fon havuzunda işlem gerçekleştirmek için çağırabilir. Fon havuzuyla etkileşimde bulunurken, kötü niyetli token mantığı kontrol akışını ele geçirerek kötü niyetli davranışlar gerçekleştirebilir.
Tehdit Modeli I için Önleme Tedbirleri
Bu tür güvenlik sorunlarının hook ile ilgili olarak önlenmesi için, hassas dış/kamu fonksiyonlarına gerekli erişim kontrolünün uygun şekilde uygulanması ve giriş parametrelerinin doğrulanması yoluyla etkileşimlerin doğrulanması hayati öneme sahiptir. Ayrıca, yeniden giriş koruması, hook'un standart mantık akışında tekrar çalıştırılmadığından emin olmaya yardımcı olabilir. Uygun güvenlik önlemlerinin uygulanmasıyla, fon havuzları bu tür tehditlerle ilişkili riskleri azaltabilir.
Tehdit Modeli II'ndeki güvenlik sorunları
Bu tehdit modelinde, geliştiricilerin ve onların hook'larının kötü niyetli olduğu varsayılmaktadır. Kapsam çok geniş olduğundan, yalnızca v4 sürümüyle ilgili güvenlik sorunlarına odaklanıyoruz. Bu nedenle, sağlanan hook'un kullanıcı transferleri veya yetkilendirmeleri ile ilgili kripto varlıkları işleyip işleyemeyeceği kritik öneme sahiptir.
Hook'a erişim yönteminin, hook'a verilebilecek izinleri belirlemesi nedeniyle, hook'u iki sınıfa ayırıyoruz:
Yönetilen Hook(Managed Hooks):hook bir giriş noktası değildir. Kullanıcı, hook ile etkileşimde bulunmak için Uniswap tarafından sağlanabilecek bir yönlendirici( aracılığıyla geçmelidir.
Bağımsız Hook)Bağımsız Kancalar(:hook, kullanıcıların doğrudan etkileşimde bulunmasına olanak tanıyan bir giriş noktasıdır.
)# Yönetilen Hook
Bu durumda, kullanıcının kripto varlıkları ###, yerel tokenler ve diğer tokenler ( router'a transfer edilir veya yetkilendirilir. PoolManager bakiye kontrolü yaptığı için, kötü niyetli hook'ların bu varlıkları doğrudan çalması kolay değildir. Ancak, hala potansiyel bir saldırı yüzeyi vardır. Örneğin, v4 sürümündeki ücret yönetim mekanizması, saldırganlar tarafından hook aracılığıyla manipüle edilebilir.
)# Bağımsız Tipi Hook
Hook bir giriş noktası olarak kullanıldığında, durum daha da karmaşık hale gelir. Bu durumda, kullanıcıların doğrudan hook ile etkileşimde bulunabilmesi nedeniyle, hook daha fazla güç kazanır. Teorik olarak, hook bu etkileşim yoluyla istenilen her türlü işlemi gerçekleştirebilir.
v4 sürümünde, kod mantığının doğrulanması çok kritiktir. Ana sorun, kod mantığının manipüle edilip edilemeyeceğidir. Eğer hook yükseltilebilir ise, bu, görünüşte güvenli bir hook'un yükseltmeden sonra kötü niyetli hale gelebileceği anlamına gelir ve bu da önemli bir risk oluşturur. Bu riskler şunları içerir:
Yükseltilebilir vekil ### doğrudan saldırıya uğrayabilir (;
Kendini yok etme mantığı taşır. selfdestruct ve create2'nin birleşik çağrılması durumunda saldırıya uğrayabilir.
)# Tehdit Modeli II için Önlemler
En önemli nokta, hook'un kötü niyetli olup olmadığını değerlendirmektir. Özellikle, barındırılan hook'lar için, maliyet yönetimi davranışlarına odaklanmalıyız; bağımsız hook'lar için ise, esas odak noktası bunların yükseltilebilir olup olmadığıdır.
![Neden Hook'un Uniswap V4 için bir "çift taraflı kılıç" olduğunu söylüyoruz?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Sonuç
Bu makale, Uniswap v4'ün Hook güvenlik sorunlarıyla ilgili temel mekanizmaları kısaca özetlemekte, iki tehdit modeli önermekte ve ilgili güvenlik risklerini özetlemektedir.
Sonraki makalelerde, her bir tehdit modelinin güvenlik sorunlarını derinlemesine analiz edeceğiz.
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.
Uniswap v4 Hook mekanizması güvenlik açığı barındırıyor, uzmanlar dikkatli kullanılmasını öneriyor.
Uniswap v4 yakında piyasaya sürülüyor, Hook mekanizması güvenlik riskleri barındırıyor
Uniswap v4 yakında piyasaya sürülecek, bu güncelleme her işlem çifti için sonsuz sayıda likidite havuzu ve dinamik ücretler, tekil tasarım, flaş muhasebe, Hook mekanizması ve ERC1155 token standardına destek gibi birçok yeni özellik getiriyor. v4'ün Ethereum Cancun güncellemesinden sonra piyasaya sürülmesi bekleniyor.
Birçok yenilik arasında, Hook mekanizması güçlü potansiyeli nedeniyle büyük ilgi görmektedir. Likidite havuzunun yaşam döngüsündeki belirli zaman noktalarında özel kodların yürütülmesine olanak tanır ve bu da havuzun ölçeklenebilirliğini ve esnekliğini büyük ölçüde artırır.
Ancak, Hook mekanizması çift taraflı bir kılıç olabilir. Güçlü ve esnek olmasına rağmen, Hook'u güvenli bir şekilde kullanmak da zorluklarla karşı karşıyadır. Hook'un karmaşıklığı kaçınılmaz olarak yeni potansiyel saldırı vektörlerini beraberinde getirmektedir. Bu nedenle, Hook mekanizmasıyla ilgili güvenlik sorunlarını ve potansiyel riskleri sistematik bir şekilde tanıtmak son derece önemlidir; bu, daha güvenli bir Uniswap v4 Hook inşa etmeye yardımcı olacaktır.
Bu makalede Uniswap v4'teki Hook mekanizmasının ilgili kavramları tanıtılacak ve mevcut güvenlik riskleri özetlenecektir.
Uniswap V4'ün mekanizması
Derinlemesine tartışmadan önce, Uniswap v4'ün mekanizması hakkında temel bir anlayışa ihtiyaç duyuyoruz. Resmi duyurular ve beyaz kitaplara göre, Hook, tekil mimari ve anlık muhasebe, özel likidite havuzları oluşturma ve birden fazla havuzda verimli yönlendirme sağlama konusunda üç önemli işlevdir.
Kanca
Hook, likidite fon havuzunun yaşam döngüsünün farklı aşamalarında çalışan bir sözleşmeyi ifade eder. Uniswap ekibi, Hook'u tanıtarak herkesin denge kararları alabilmesini ummaktadır. Bu yöntem, dinamik ücretlerin yerel olarak desteklenmesini, zincir üstü limit emir eklemeyi veya zaman ağırlıklı ortalama yapıcı (TWAMM) büyük siparişleri dağıtmak için kullanmayı mümkün kılabilir.
Şu anda dört gruba ayrılmış sekiz Hook geri çağrısı var ( her grup bir çift geri çağrı içeriyor ):
Singleton, yıldırım muhasebesi ve kilit mekanizması
Singleton mimarisi ve hızlı muhasebe, maliyetleri azaltarak ve verimliliği sağlayarak performansı artırmayı amaçlamaktadır. Tüm likidite havuzlarının aynı akıllı sözleşme içinde saklandığı yeni bir singleton sözleşmesi tanıtmaktadır. Bu singleton tasarımı, tüm havuzların durumunu depolamak ve yönetmek için bir PoolManager'a dayanır.
v4 sürümü, ışık muhasebesi ve kilitleme mekanizmasını tanıttı. Kilitleme mekanizmasının çalışma şekli şöyledir:
locker sözleşmesi PoolManager üzerinde lock talep eder.
PoolManager, bu locker sözleşmesinin adresini lockData kuyruğuna ekler ve lockAcquired geri çağrısını çağırır.
locker sözleşmesi geri çağırma sırasında mantığını yürütür. Yürütme sürecinde, locker sözleşmesinin havuzla etkileşimi sıfırdan farklı para artışlarına neden olabilir. Ancak, yürütme sona erdiğinde, tüm artışlar sıfıra eşitlenmelidir. Ayrıca, eğer lockData kuyruğu boş değilse, yalnızca son locker sözleşmesi işlem yapabilir.
PoolManager, lockData kuyruğunu ve para artışının durumunu kontrol eder. Doğrulandıktan sonra, PoolManager o locker sözleşmesini kaldıracaktır.
Sonuç olarak, kilit mekanizması eşzamanlı erişimi önler ve tüm işlemlerin tasfiye edilmesini garanti eder. locker sözleşmesi kilit için sırayla başvurur, ardından lockAcquired geri çağrısıyla işlemi gerçekleştirir. Her havuz işlemi öncesi ve sonrasında ilgili Hook geri çağrısı tetiklenir. Son olarak, PoolManager durumu kontrol eder.
Bu yöntem, işlemin ayarladığı şeyin iç net bakiye ( yani delta ) olduğu anlamına gelir, anlık transfer gerçekleştirilmez. Herhangi bir değişiklik, havuzun iç bakiyesinde kaydedilir, gerçek transfer ise işlem ( yani lock ) sona erdiğinde gerçekleştirilir. Bu süreç, açığa çıkmamış token olmadığını garanti eder, böylece fonların bütünlüğü korunur.
Kilitleme mekanizmasının varlığı nedeniyle, dışarıdaki tüm hesaplar (EOA) doğrudan PoolManager ile etkileşime giremez. Bunun yerine, herhangi bir etkileşim bir sözleşme aracılığıyla gerçekleştirilmelidir. Bu sözleşme, herhangi bir havuz işlemi gerçekleştirilmeden önce lock talep edilmesi gereken ara bir locker olarak işlev görür.
İki ana sözleşme etkileşim senaryosu vardır:
locker sözleşmesi resmi kod deposundan veya kullanıcı tarafından dağıtılan bir sözleşmeden gelmektedir. Bu durumda, etkileşimi bir yönlendirici aracılığıyla gerçekleştirdiğimizi düşünebiliriz.
locker sözleşmesi ve Hook'un aynı sözleşme içinde entegre edilmesi ya da üçüncü taraf bir varlık tarafından kontrol edilmesi durumudur. Bu durumda etkileşimi Hook aracılığıyla geçiş olarak görebiliriz. Bu durumda Hook, hem locker sözleşmesinin rolünü üstlenir hem de geri çağırmayı işlemekten sorumludur.
Tehdit Modeli
İlgili güvenlik sorunlarını tartışmadan önce, tehdit modelini belirlememiz gerekiyor. Ana olarak aşağıdaki iki durumu dikkate alıyoruz:
Tehdit modeli I: Hook kendisi iyidir, ancak bir güvenlik açığı bulunmaktadır.
Tehdit Modeli II: Hook kendisi kötü niyetlidir.
Sonraki bölümde, bu iki tehdit modeli temelinde potansiyel güvenlik sorunlarını tartışacağız.
Tehdit Modeli I'ndeki güvenlik sorunları
Tehdit modeli I, Hook ile ilgili açıkları dikkate alır. Bu tehdit modeli, geliştiricinin ve Hook'un kötü niyetli olmadığını varsayar. Ancak, akıllı sözleşmelerdeki mevcut bilinen açıklar Hook'ta da ortaya çıkabilir.
Uniswap v4'teki Hook, çekirdek havuz işlemleri ('de özelleştirilmiş mantığı uygulamak için, başlangıç, konum değiştirme, takas yapma ve ) toplama gibi işlemlerden önce veya sonra çalışabilen bir akıllı sözleşmedir. Hook'un standart bir arayüz sağlaması bekleniyor olsa da, özelleştirilmiş mantığın da dahil edilmesine izin vermektedir. Bu nedenle, tartışmamız standart Hook arayüzü ile ilgili mantıkla sınırlı olacaktır. Ardından, Hook'un bu standart Hook fonksiyonlarını nasıl kötüye kullanabileceği gibi potansiyel açık kaynaklarını bulmaya çalışacağız.
Özellikle, aşağıdaki iki tür Hook'a odaklanacağız:
İlk tür hook, kullanıcı fonlarını saklamaktır. Bu durumda, saldırgan bu hook'u hedef alabilir ve fonları transfer ederek varlık kaybına neden olabilir.
İkinci tür hook, kullanıcıların veya diğer protokollerin bağımlı olduğu kritik durum verilerini saklar. Bu durumda, saldırgan kritik durumu değiştirmeye çalışabilir. Diğer kullanıcılar veya protokoller yanlış durumu kullandığında, potansiyel riskler ortaya çıkabilir.
Awesome Uniswap v4 Hooks deposunun derinlemesine incelenmesi sonucunda, birkaç ciddi güvenlik açığı tespit ettik. Bu açıklar, esasen hook, PoolManager ve dış üçüncü taraflar arasındaki risk etkileşimlerinden kaynaklanıyor ve temel olarak iki ana kategoriye ayrılabiliyor: erişim kontrolü sorunları ve girdi doğrulama sorunları.
Genel olarak, 22 ilgili proje ( Uniswap v4 ile ilgisi olmayan projeler ) hariç tutulmuştur. Bu projeler arasında, 8 tanesinin (36%) güvenlik açığı içerdiğini düşünüyoruz. Bu 8 güvenlik açığı olan projeden 6'sında erişim kontrol sorunları, 2'sinde ise güvenilmeyen dış çağrılara karşı hassasiyet bulunmaktadır.
Erişim kontrolü sorunu
Bu bölümde, v4'teki geri çağırma fonksiyonlarının neden olabileceği sorunlara odaklanıyoruz, bunlar arasında 8 adet hook geri çağırma ve lock geri çağırma bulunmaktadır. Bu fonksiyonlar yalnızca PoolManager tarafından çağrılmalıdır, diğer adresler ( dahil EOA ve sözleşmeler ) tarafından çağrılamaz. Örneğin, ödüller fon havuz anahtarı ile dağıtıldığında, ilgili fonksiyon herhangi bir hesap tarafından çağrılabiliyorsa, ödüller yanlış bir şekilde alınabilir.
Bu nedenle, hook için güçlü bir erişim kontrol mekanizması oluşturmak kritik öneme sahiptir, özellikle de bunların havuzun kendisi dışında başka taraflar tarafından çağrılabilmesidir. Erişim izinlerini sıkı bir şekilde yöneterek, likidite havuzları, hook'un yetkisiz etkileşimler veya kötü niyetli etkileşimler ile ilgili riskini önemli ölçüde azaltabilir.
Giriş doğrulama sorunu
Uniswap v4'te, bir kilitleme mekanizması bulunduğundan, kullanıcıların herhangi bir havuz işlemi gerçekleştirmeden önce sözleşmeden bir lock alması gerekmektedir. Bu, etkileşimde bulunan mevcut sözleşmenin en son locker sözleşmesi olduğunu garanti eder.
Yine de, bazı savunmasız Hook uygulamalarında giriş doğrulamasının yetersiz olması nedeniyle güvenilmeyen dış çağrılarla sonuçlanabilecek bir olası saldırı senaryosu bulunmaktadır:
Öncelikle, hook kullanıcının etkileşimde bulunmayı düşündüğü likidite havuzunu doğrulamıyor. Bu, sahte tokenler içeren ve zararlı mantık yürüten kötü niyetli bir likidite havuzu olabilir.
İkincisi, bazı anahtar hook fonksiyonları herhangi bir dış çağrıya izin verir.
Güvenilmeyen dış çağrılar son derece tehlikelidir, çünkü çeşitli türde saldırılara yol açabilir, bunlar arasında iyi bildiğimiz yeniden giriş saldırısı da bulunmaktadır.
Bu savunmasız hook'lara saldırmak için, bir saldırgan sahte token'ı için kötü niyetli bir fon havuzu kaydedebilir ve ardından hook'u fon havuzunda işlem gerçekleştirmek için çağırabilir. Fon havuzuyla etkileşimde bulunurken, kötü niyetli token mantığı kontrol akışını ele geçirerek kötü niyetli davranışlar gerçekleştirebilir.
Tehdit Modeli I için Önleme Tedbirleri
Bu tür güvenlik sorunlarının hook ile ilgili olarak önlenmesi için, hassas dış/kamu fonksiyonlarına gerekli erişim kontrolünün uygun şekilde uygulanması ve giriş parametrelerinin doğrulanması yoluyla etkileşimlerin doğrulanması hayati öneme sahiptir. Ayrıca, yeniden giriş koruması, hook'un standart mantık akışında tekrar çalıştırılmadığından emin olmaya yardımcı olabilir. Uygun güvenlik önlemlerinin uygulanmasıyla, fon havuzları bu tür tehditlerle ilişkili riskleri azaltabilir.
Tehdit Modeli II'ndeki güvenlik sorunları
Bu tehdit modelinde, geliştiricilerin ve onların hook'larının kötü niyetli olduğu varsayılmaktadır. Kapsam çok geniş olduğundan, yalnızca v4 sürümüyle ilgili güvenlik sorunlarına odaklanıyoruz. Bu nedenle, sağlanan hook'un kullanıcı transferleri veya yetkilendirmeleri ile ilgili kripto varlıkları işleyip işleyemeyeceği kritik öneme sahiptir.
Hook'a erişim yönteminin, hook'a verilebilecek izinleri belirlemesi nedeniyle, hook'u iki sınıfa ayırıyoruz:
Yönetilen Hook(Managed Hooks):hook bir giriş noktası değildir. Kullanıcı, hook ile etkileşimde bulunmak için Uniswap tarafından sağlanabilecek bir yönlendirici( aracılığıyla geçmelidir.
Bağımsız Hook)Bağımsız Kancalar(:hook, kullanıcıların doğrudan etkileşimde bulunmasına olanak tanıyan bir giriş noktasıdır.
)# Yönetilen Hook
Bu durumda, kullanıcının kripto varlıkları ###, yerel tokenler ve diğer tokenler ( router'a transfer edilir veya yetkilendirilir. PoolManager bakiye kontrolü yaptığı için, kötü niyetli hook'ların bu varlıkları doğrudan çalması kolay değildir. Ancak, hala potansiyel bir saldırı yüzeyi vardır. Örneğin, v4 sürümündeki ücret yönetim mekanizması, saldırganlar tarafından hook aracılığıyla manipüle edilebilir.
)# Bağımsız Tipi Hook
Hook bir giriş noktası olarak kullanıldığında, durum daha da karmaşık hale gelir. Bu durumda, kullanıcıların doğrudan hook ile etkileşimde bulunabilmesi nedeniyle, hook daha fazla güç kazanır. Teorik olarak, hook bu etkileşim yoluyla istenilen her türlü işlemi gerçekleştirebilir.
v4 sürümünde, kod mantığının doğrulanması çok kritiktir. Ana sorun, kod mantığının manipüle edilip edilemeyeceğidir. Eğer hook yükseltilebilir ise, bu, görünüşte güvenli bir hook'un yükseltmeden sonra kötü niyetli hale gelebileceği anlamına gelir ve bu da önemli bir risk oluşturur. Bu riskler şunları içerir:
Yükseltilebilir vekil ### doğrudan saldırıya uğrayabilir (;
Kendini yok etme mantığı taşır. selfdestruct ve create2'nin birleşik çağrılması durumunda saldırıya uğrayabilir.
)# Tehdit Modeli II için Önlemler
En önemli nokta, hook'un kötü niyetli olup olmadığını değerlendirmektir. Özellikle, barındırılan hook'lar için, maliyet yönetimi davranışlarına odaklanmalıyız; bağımsız hook'lar için ise, esas odak noktası bunların yükseltilebilir olup olmadığıdır.
![Neden Hook'un Uniswap V4 için bir "çift taraflı kılıç" olduğunu söylüyoruz?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Sonuç
Bu makale, Uniswap v4'ün Hook güvenlik sorunlarıyla ilgili temel mekanizmaları kısaca özetlemekte, iki tehdit modeli önermekte ve ilgili güvenlik risklerini özetlemektedir.
Sonraki makalelerde, her bir tehdit modelinin güvenlik sorunlarını derinlemesine analiz edeceğiz.