Uniswap v4 Hook mekanizmasının çift yönlülüğü: yenilik ve potansiyel risklerin bir arada bulunması
Uniswap v4 yakında piyasaya sürülecek, bu güncelleme oldukça iddialı. Yeni versiyon, her ticaret çifti için sonsuz sayıda likidite havuzu ve dinamik ücretler, tek örnek tasarımı, anlık muhasebe, Hook mekanizması ve ERC1155 token standardı desteği gibi birçok yeni özellik sunacak. Geçici depolama teknolojisini kullanarak, Uniswap v4'ın Ethereum Cancun güncellemesinden sonra piyasaya sürülmesi bekleniyor.
Birçok yenilik arasında, Hook mekanizması güçlü potansiyeli nedeniyle dikkat çekmektedir. Bu mekanizma, likidite havuzunun yaşam döngüsündeki belirli noktalarda özel kodun yürütülmesine olanak tanır ve havuzun ölçeklenebilirliğini ve esnekliğini büyük ölçüde artırır.
Ancak, Hook mekanizması da çift taraflı bir kılıç olabilir. Güçlü ve esnek olmasına rağmen, Hook'u güvenli bir şekilde kullanmak da önemli zorluklarla karşı karşıya kalmaktadır. Hook'un karmaşıklığı kaçınılmaz olarak yeni potansiyel saldırı vektörlerini beraberinde getirmektedir. Bu nedenle, Hook mekanizması ile ilgili güvenlik sorunlarını ve potansiyel riskleri sistematik bir şekilde tanıtmak gereklidir, böylece topluluğun güvenli gelişimini teşvik edebiliriz. Bu bilgiler, 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 var olan güvenlik riskleri özetlenecektir.
Uniswap V4 Mekaniği
Derinlemesine incelemeden önce, Uniswap v4'ün mekanizmasını temel düzeyde anlamamız gerekiyor. Resmi duyuru ve beyaz bültene göre, Hook, tekil mimari ve flaş muhasebe, özel likidite havuzları oluşturmak ve birden fazla havuz arasında verimli yönlendirme sağlamak için üç önemli işlevdir.
1.1 Kanca
Hook, likidite havuzunun yaşam döngüsünün farklı aşamalarında çalışan sözleşmeleri ifade eder. Uniswap ekibi, Hook'u tanıtarak herkesin karar vermesine yardımcı olmayı umuyor. Bu yöntem, dinamik ücretlerin yerel olarak desteklenmesini, zincir üzerinde limit emirlerin eklenmesini veya zaman ağırlıklı ortalama yapıcı (TWAMM) ile büyük emirlerin dağıtılmasını sağlayabilir.
Şu anda sekiz Hook geri çağrısı var, dört gruba ayrılmıştır ( her grup bir çift geri çağrı içerir ):
beforeInitialize/afterInitialize
beforeModifyPosition/afterModifyPosition
beforeSwap/afterSwap
beforeDonate/afterDonate
Uniswap ekibi, bazı örnekler sağladı ( TWAMM Hook ) uygulama yöntemini tanıtırken, topluluk katılımcıları da bazı katkılarda bulundu. Resmi belgeler ayrıca, daha fazla Hook örneği toplayan Awesome Uniswap v4 Hooks deposuna bağlantı vermektedir.
1.2 Singleton, şimşek muhasebe ve kilit mekanizması
Singleton mimarisi ve lightning muhasebesi, maliyetleri düşürerek ve verimliliği sağlayarak performansı artırmayı amaçlamaktadır. Tüm likidite havuzlarının aynı akıllı sözleşmede saklandığı yeni bir singleton sözleşmesi tanıtılmaktadır. Bu singleton tasarımı, tüm havuzların durumunu saklamak ve yönetmek için PoolManager'a dayanmaktadır.
Uniswap v4 versiyonu, flash hesaplama ve kilitleme mekanizmasını tanıttı. Kilitleme mekanizmasının çalışma şekli şu şekildedir:
locker sözleşmesi PoolManager üzerinde lock talep eder.
PoolManager, bu locker sözleşme adresini lockData kuyruğuna ekler ve lockAcquired geri çağrısını çağırır.
locker sözleşmesi geri çağırmada mantığını yerine getirir. Uygulama sürecinde, locker sözleşmesi ile havuzun etkileşimi sıfırdan farklı para artışlarına neden olabilir. Ancak uygulama sonunda, tüm artışlar sıfıra hesaplanmalıdır. Ayrıca, 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 bu locker sözleşmesini silecektir.
Sonuç olarak, kilit mekanizması eşzamanlı erişimi engeller ve tüm işlemlerin tasfiye edilmesini garanti eder. locker sözleşmesi sırayla lock talep eder, ardından lockAcquired geri çağrısı ile işlemi gerçekleştirir. Havuz işlemi öncesinde 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, anlık transferlerin gerçekleştirilmediği anlamına gelir. Herhangi bir değişiklik, havuzun iç bakiyesinde kaydedilecektir, gerçek transfer ise işlem ( yani lock ) sona erdiğinde gerçekleştirilecektir. Bu süreç, herhangi bir tasfiye edilmemiş token olmadığını garanti eder ve böylece fonların bütünlüğünü korur.
Kilitleme mekanizması nedeniyle, dışardaki tüm hesaplar (EOA) doğrudan PoolManager ile etkileşime giremez. Aksine, herhangi bir etkileşim mutlaka 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 kilitleyici olarak işlev görmektedir.
Ana olarak iki tür sözleşme etkileşim senaryosu vardır:
locker sözleşmesi resmi kod deposundan gelir veya kullanıcı tarafından dağıtılır. Bu durum, yönlendirici aracılığıyla etkileşim olarak düşünülebilir.
locker sözleşmesi ve Hook'un aynı sözleşmeye entegre edilmesi veya üçüncü taraf bir varlık tarafından kontrol edilmesi. Bu durum, Hook aracılığıyla etkileşim olarak görülebilir. 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 açıklar vardır.
Tehdit modeli II: Hook kendisi kötü niyetlidir.
Sonraki aşamada, bu iki tehdit modeli temelinde potansiyel güvenlik sorunları tartışılacaktır.
2.1 Tehdit Modeli I'ndeki Güvenlik Sorunları
Tehdit modeli I, Hook'un kendisiyle ilgili zafiyetlere odaklanmaktadır. Bu tehdit modeli, geliştiricinin ve Hook'un kötü niyetli olmadığını varsayar. Ancak, akıllı sözleşmelerdeki mevcut bilinen zafiyetler Hook'ta da ortaya çıkabilir. Örneğin, eğer Hook, yükseltilebilir bir sözleşme olarak uygulanmışsa, OpenZeppelin'in UUPSUpgradeable zafiyetiyle ilgili benzer sorunlarla karşılaşabilir.
Yukarıdaki faktörler göz önüne alındığında, v4 sürümüne özgü potansiyel güvenlik açıklarına odaklanmayı seçiyoruz. Uniswap v4'te, Hook, temel havuz işlemleri ('i (başlatma, konum değiştirme, takas yapma ve )'i toplama) gerçekleştirmeden önce veya sonra özel mantık yürütmesine olanak tanıyan bir akıllı sözleşmedir. Hook'un standart bir arayüz sağlaması beklenirken, aynı zamanda özel mantık içermesine de izin verilmektedir. Bu nedenle, tartışmamız standard Hook arayüzü ile ilgili mantıkla sınırlı olacaktır. Ardından, Hook'un bu standart Hook işlevlerini nasıl kötüye kullanabileceği gibi olası güvenlik açığı kaynaklarını belirlemeye ç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'a saldırarak fonları transfer edebilir ve 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 depolamaktır. Bu durumda, saldırgan kritik durumu değiştirmeye çalışabilir. Diğer kullanıcılar veya protokoller hatalı durumu kullandığında potansiyel riskler ortaya çıkabilir.
Lütfen dikkat edin, bu iki aralığın dışındaki kancalar tartışmamızın kapsamına girmemektedir.
Awesome Uniswap v4 Hooks deposunun derinlemesine incelenmesi sonucunda birkaç ciddi güvenlik açığı tespit ettik. Bu güvenlik açıkları esasen hook, PoolManager ve dış üçüncü taraflar arasındaki risk etkileşimlerinden kaynaklanıyor ve iki ana kategoriye ayrılabilir: erişim kontrol sorunları ve girdi doğrulama sorunları.
Genel olarak, Uniswap v4 ile ilgisi olmayan projeleri ( dışlayarak 22 ilgili proje bulduk. Bu projelerden 8'inin )36%( güvenlik açığı olduğunu düşünüyoruz. Bu 8 güvenlik açığına sahip projeden 6'sında erişim kontrolü sorunları, 2'sinde ise güvensiz dış çağrılara karşı hassasiyet bulunmaktadır.
)# 2.1.1 Erişim Kontrolü Sorunu
Bu bölümde, v4 içindeki geri çağırma fonksiyonlarının neden olabileceği sorunlara odaklanıyoruz, bunlar arasında 8 adet hook geri çağırması ve lock geri çağırması bulunmaktadır. Elbette, doğrulanması gereken başka durumlar da vardır, ancak bu durumlar tasarıma bağlı olduğu için tartışma kapsamımızda değildir.
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 havuzu anahtarı tarafından dağıtıldığında, ilgili fonksiyon herhangi bir hesap tarafından çağrılabiliyorsa, ödüller yanlışlıkla alınabilir.
Bu nedenle, hook için güçlü bir erişim kontrol mekanizması oluşturmak son derece önemlidir, özellikle de bunların havuzun kendisi dışında başka taraflarca çağrılabilmesi durumunda. Erişim izinlerini sıkı bir şekilde yöneterek, likidite havuzları, hook'un yetkisiz veya kötü niyetli etkileşimleri ile ilişkili riskleri önemli ölçüde azaltabilir.
)# 2.1.2 Giriş doğrulama sorunu
Uniswap v4'te, bir kilitleme mekanizması olduğu için, kullanıcıların herhangi bir likidite havuzu işlemi gerçekleştirmeden önce sözleşmeden bir lock alması gerekmektedir. Bu, etkileşime giren mevcut sözleşmenin en son locker sözleşmesi olduğunu garanti eder.
Bununla birlikte, bazı savunmasız Hook uygulamalarında giriş doğrulamasının yetersiz olması nedeniyle güvensiz dış çağrılara yol açabilecek bir olası saldırı senaryosu vardır:
Öncelikle, hook kullanıcıların etkileşim kurmayı düşündüğü likidite havuzunu doğrulamamıştır. Bu, sahte tokenlar içeren ve zararlı mantık yürüten kötü niyetli bir likidite havuzu olabilir.
İkincisi, bazı kritik hook fonksiyonları herhangi bir dış çağrıya izin verir.
Güvenilmeyen dış çağrılar son derece tehlikelidir, çünkü bu çeşitli saldırı türlerine 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, saldırgan sahte token'leri için kötü niyetli bir likidite havuzu kaydedebilir ve ardından havuzda işlem yapmak için hook'u çağırabilir. Likidite havuzuyla etkileşimde bulunurken, kötü niyetli token mantığı, kötü davranışlar gerçekleştirmek için kontrol akışını ele geçirir.
2.1.3 Tehdit Modeli I için önlemler
Bu tür güvenlik sorunlarıyla ilişkili hook'ları önlemek için, hassas dış/kamu fonksiyonlarına gerekli erişim kontrolünü uygun bir şekilde uygulamak ve giriş parametrelerini doğrulamak, etkileşimleri doğrulamak açısından son derece önemlidir. Ayrıca, yeniden giriş koruması, hook'un standart mantık akışı içinde tekrar tekrar çalıştırılmadığından emin olmaya yardımcı olabilir. Uygun güvenlik önlemleri uygulayarak, fon havuzları bu tür tehditlerle ilişkili riskleri azaltabilir.
![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-ba4bfa88e0ac0b6246e82ad879361ff3.webp(
) 2.2 Tehdit Modeli II'ndeki Güvenlik Sorunları
Bu tehdit modelinde, geliştiricinin ve onun hook'larının kötü niyetli olduğunu varsayıyoruz. Kapsam geniş olduğundan, yalnızca v4 sürümü ile ilgili güvenlik sorunlarına odaklanıyoruz. Bu nedenle, sağlanan hook'un kullanıcı transferlerini veya yetkilendirmelerini işleyip işleyemeyeceği önemlidir.
Hook'a erişim yöntemleri, hook'a verilebilecek yetkileri belirlediğinden, bu nedenle hook'u iki kategoriye 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 ) yönlendirici üzerinden geçmelidir.
Bağımsız Hook(Standalone Hooks): hook, kullanıcıların doğrudan etkileşimde bulunmalarını sağlayan bir giriş noktasıdır.
(# 2.2.1 Yönetilen Hook
Bu durumda, kullanıcının kripto varlıkları ), yerel tokenler ve diğer tokenler ### router'a aktarılır veya yetkilendirilir. PoolManager bakiye kontrolü yaptığı için, kötü niyetli hook'ların bu varlıkları doğrudan çalması kolay değildir. Ancak, yine de 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.
(# 2.2.2 Bağımsız Tip Hook
Hook bir giriş noktası olarak kullanıldığında, durum daha karmaşık hale gelir. Bu durumda, kullanıcıların doğrudan hook ile etkileşimde bulunabilmesi nedeniyle, hook daha fazla yetki kazanır. Teorik olarak, hook bu etkileşim aracılığıyla istenen herhangi bir işlemi gerçekleştirebilir.
v4 sürümünde, kod mantığının doğrulanması son derece önemlidir. Temel 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ükseltme sonrasında kötü niyetli hale gelebileceği anlamına gelir ve bu da önemli bir risk oluşturur. Bu riskler şunları içerir:
Yükseltilebilir ajan ) doğrudan saldırıya uğrayabilir ###;
Kendini yok etme mantığına sahip. selfdestruct ve create2'nin birleşik çağrısında saldırıya uğrayabilir.
(# 2.2.3 Tehdit Modeli II için Önlemler
Kritik bir 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 dikkat etmeliyiz; bağımsız hook'lar için ise, esas odak noktası bunların güncellenebilir olup olmadıkları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 öncelikle Uniswap v4'teki Hook güvenlik sorunlarıyla ilgili temel mekanizmaları kısaca özetlemektedir. Ardından, iki tehdit modeli sunuyoruz ve ilgili güvenlik risklerini kısaca özetliyoruz.
Sonraki makalelerde, her bir tehdit modeli altında 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.
15 Likes
Reward
15
5
Share
Comment
0/400
OfflineValidator
· 07-31 11:18
V4'ü iyi anlamak gerekiyor.
View OriginalReply0
MetaMisery
· 07-30 04:35
v3 kadar stabil değil, yine bir kavramı pazarlamak istiyorsun.
View OriginalReply0
SatoshiNotNakamoto
· 07-30 04:24
v4'ün hatalarının ortaya çıkmasını bekliyorum.
View OriginalReply0
TokenGuru
· 07-30 04:17
Eski projelerin evrim geçirmiş hali, körü körüne gemiye binen enayiler yine zor durumda.
View OriginalReply0
SigmaValidator
· 07-30 04:16
Anladım, bu çukurdan kısa devre yapma fırsatı güzel.
Uniswap v4 Hook mekanizmasının güvenlik analizi: Yenilik ve risk iç içe
Uniswap v4 Hook mekanizmasının çift yönlülüğü: yenilik ve potansiyel risklerin bir arada bulunması
Uniswap v4 yakında piyasaya sürülecek, bu güncelleme oldukça iddialı. Yeni versiyon, her ticaret çifti için sonsuz sayıda likidite havuzu ve dinamik ücretler, tek örnek tasarımı, anlık muhasebe, Hook mekanizması ve ERC1155 token standardı desteği gibi birçok yeni özellik sunacak. Geçici depolama teknolojisini kullanarak, Uniswap v4'ın Ethereum Cancun güncellemesinden sonra piyasaya sürülmesi bekleniyor.
Birçok yenilik arasında, Hook mekanizması güçlü potansiyeli nedeniyle dikkat çekmektedir. Bu mekanizma, likidite havuzunun yaşam döngüsündeki belirli noktalarda özel kodun yürütülmesine olanak tanır ve havuzun ölçeklenebilirliğini ve esnekliğini büyük ölçüde artırır.
Ancak, Hook mekanizması da çift taraflı bir kılıç olabilir. Güçlü ve esnek olmasına rağmen, Hook'u güvenli bir şekilde kullanmak da önemli zorluklarla karşı karşıya kalmaktadır. Hook'un karmaşıklığı kaçınılmaz olarak yeni potansiyel saldırı vektörlerini beraberinde getirmektedir. Bu nedenle, Hook mekanizması ile ilgili güvenlik sorunlarını ve potansiyel riskleri sistematik bir şekilde tanıtmak gereklidir, böylece topluluğun güvenli gelişimini teşvik edebiliriz. Bu bilgiler, 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 var olan güvenlik riskleri özetlenecektir.
Uniswap V4 Mekaniği
Derinlemesine incelemeden önce, Uniswap v4'ün mekanizmasını temel düzeyde anlamamız gerekiyor. Resmi duyuru ve beyaz bültene göre, Hook, tekil mimari ve flaş muhasebe, özel likidite havuzları oluşturmak ve birden fazla havuz arasında verimli yönlendirme sağlamak için üç önemli işlevdir.
1.1 Kanca
Hook, likidite havuzunun yaşam döngüsünün farklı aşamalarında çalışan sözleşmeleri ifade eder. Uniswap ekibi, Hook'u tanıtarak herkesin karar vermesine yardımcı olmayı umuyor. Bu yöntem, dinamik ücretlerin yerel olarak desteklenmesini, zincir üzerinde limit emirlerin eklenmesini veya zaman ağırlıklı ortalama yapıcı (TWAMM) ile büyük emirlerin dağıtılmasını sağlayabilir.
Şu anda sekiz Hook geri çağrısı var, dört gruba ayrılmıştır ( her grup bir çift geri çağrı içerir ):
Uniswap ekibi, bazı örnekler sağladı ( TWAMM Hook ) uygulama yöntemini tanıtırken, topluluk katılımcıları da bazı katkılarda bulundu. Resmi belgeler ayrıca, daha fazla Hook örneği toplayan Awesome Uniswap v4 Hooks deposuna bağlantı vermektedir.
1.2 Singleton, şimşek muhasebe ve kilit mekanizması
Singleton mimarisi ve lightning muhasebesi, maliyetleri düşürerek ve verimliliği sağlayarak performansı artırmayı amaçlamaktadır. Tüm likidite havuzlarının aynı akıllı sözleşmede saklandığı yeni bir singleton sözleşmesi tanıtılmaktadır. Bu singleton tasarımı, tüm havuzların durumunu saklamak ve yönetmek için PoolManager'a dayanmaktadır.
Uniswap v4 versiyonu, flash hesaplama ve kilitleme mekanizmasını tanıttı. Kilitleme mekanizmasının çalışma şekli şu şekildedir:
locker sözleşmesi PoolManager üzerinde lock talep eder.
PoolManager, bu locker sözleşme adresini lockData kuyruğuna ekler ve lockAcquired geri çağrısını çağırır.
locker sözleşmesi geri çağırmada mantığını yerine getirir. Uygulama sürecinde, locker sözleşmesi ile havuzun etkileşimi sıfırdan farklı para artışlarına neden olabilir. Ancak uygulama sonunda, tüm artışlar sıfıra hesaplanmalıdır. Ayrıca, 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 bu locker sözleşmesini silecektir.
Sonuç olarak, kilit mekanizması eşzamanlı erişimi engeller ve tüm işlemlerin tasfiye edilmesini garanti eder. locker sözleşmesi sırayla lock talep eder, ardından lockAcquired geri çağrısı ile işlemi gerçekleştirir. Havuz işlemi öncesinde 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, anlık transferlerin gerçekleştirilmediği anlamına gelir. Herhangi bir değişiklik, havuzun iç bakiyesinde kaydedilecektir, gerçek transfer ise işlem ( yani lock ) sona erdiğinde gerçekleştirilecektir. Bu süreç, herhangi bir tasfiye edilmemiş token olmadığını garanti eder ve böylece fonların bütünlüğünü korur.
Kilitleme mekanizması nedeniyle, dışardaki tüm hesaplar (EOA) doğrudan PoolManager ile etkileşime giremez. Aksine, herhangi bir etkileşim mutlaka 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 kilitleyici olarak işlev görmektedir.
Ana olarak iki tür sözleşme etkileşim senaryosu vardır:
locker sözleşmesi resmi kod deposundan gelir veya kullanıcı tarafından dağıtılır. Bu durum, yönlendirici aracılığıyla etkileşim olarak düşünülebilir.
locker sözleşmesi ve Hook'un aynı sözleşmeye entegre edilmesi veya üçüncü taraf bir varlık tarafından kontrol edilmesi. Bu durum, Hook aracılığıyla etkileşim olarak görülebilir. 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 açıklar vardır.
Tehdit modeli II: Hook kendisi kötü niyetlidir.
Sonraki aşamada, bu iki tehdit modeli temelinde potansiyel güvenlik sorunları tartışılacaktır.
2.1 Tehdit Modeli I'ndeki Güvenlik Sorunları
Tehdit modeli I, Hook'un kendisiyle ilgili zafiyetlere odaklanmaktadır. Bu tehdit modeli, geliştiricinin ve Hook'un kötü niyetli olmadığını varsayar. Ancak, akıllı sözleşmelerdeki mevcut bilinen zafiyetler Hook'ta da ortaya çıkabilir. Örneğin, eğer Hook, yükseltilebilir bir sözleşme olarak uygulanmışsa, OpenZeppelin'in UUPSUpgradeable zafiyetiyle ilgili benzer sorunlarla karşılaşabilir.
Yukarıdaki faktörler göz önüne alındığında, v4 sürümüne özgü potansiyel güvenlik açıklarına odaklanmayı seçiyoruz. Uniswap v4'te, Hook, temel havuz işlemleri ('i (başlatma, konum değiştirme, takas yapma ve )'i toplama) gerçekleştirmeden önce veya sonra özel mantık yürütmesine olanak tanıyan bir akıllı sözleşmedir. Hook'un standart bir arayüz sağlaması beklenirken, aynı zamanda özel mantık içermesine de izin verilmektedir. Bu nedenle, tartışmamız standard Hook arayüzü ile ilgili mantıkla sınırlı olacaktır. Ardından, Hook'un bu standart Hook işlevlerini nasıl kötüye kullanabileceği gibi olası güvenlik açığı kaynaklarını belirlemeye ç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'a saldırarak fonları transfer edebilir ve 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 depolamaktır. Bu durumda, saldırgan kritik durumu değiştirmeye çalışabilir. Diğer kullanıcılar veya protokoller hatalı durumu kullandığında potansiyel riskler ortaya çıkabilir.
Lütfen dikkat edin, bu iki aralığın dışındaki kancalar tartışmamızın kapsamına girmemektedir.
Awesome Uniswap v4 Hooks deposunun derinlemesine incelenmesi sonucunda birkaç ciddi güvenlik açığı tespit ettik. Bu güvenlik açıkları esasen hook, PoolManager ve dış üçüncü taraflar arasındaki risk etkileşimlerinden kaynaklanıyor ve iki ana kategoriye ayrılabilir: erişim kontrol sorunları ve girdi doğrulama sorunları.
Genel olarak, Uniswap v4 ile ilgisi olmayan projeleri ( dışlayarak 22 ilgili proje bulduk. Bu projelerden 8'inin )36%( güvenlik açığı olduğunu düşünüyoruz. Bu 8 güvenlik açığına sahip projeden 6'sında erişim kontrolü sorunları, 2'sinde ise güvensiz dış çağrılara karşı hassasiyet bulunmaktadır.
)# 2.1.1 Erişim Kontrolü Sorunu
Bu bölümde, v4 içindeki geri çağırma fonksiyonlarının neden olabileceği sorunlara odaklanıyoruz, bunlar arasında 8 adet hook geri çağırması ve lock geri çağırması bulunmaktadır. Elbette, doğrulanması gereken başka durumlar da vardır, ancak bu durumlar tasarıma bağlı olduğu için tartışma kapsamımızda değildir.
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 havuzu anahtarı tarafından dağıtıldığında, ilgili fonksiyon herhangi bir hesap tarafından çağrılabiliyorsa, ödüller yanlışlıkla alınabilir.
Bu nedenle, hook için güçlü bir erişim kontrol mekanizması oluşturmak son derece önemlidir, özellikle de bunların havuzun kendisi dışında başka taraflarca çağrılabilmesi durumunda. Erişim izinlerini sıkı bir şekilde yöneterek, likidite havuzları, hook'un yetkisiz veya kötü niyetli etkileşimleri ile ilişkili riskleri önemli ölçüde azaltabilir.
)# 2.1.2 Giriş doğrulama sorunu
Uniswap v4'te, bir kilitleme mekanizması olduğu için, kullanıcıların herhangi bir likidite havuzu işlemi gerçekleştirmeden önce sözleşmeden bir lock alması gerekmektedir. Bu, etkileşime giren mevcut sözleşmenin en son locker sözleşmesi olduğunu garanti eder.
Bununla birlikte, bazı savunmasız Hook uygulamalarında giriş doğrulamasının yetersiz olması nedeniyle güvensiz dış çağrılara yol açabilecek bir olası saldırı senaryosu vardır:
Öncelikle, hook kullanıcıların etkileşim kurmayı düşündüğü likidite havuzunu doğrulamamıştır. Bu, sahte tokenlar içeren ve zararlı mantık yürüten kötü niyetli bir likidite havuzu olabilir.
İkincisi, bazı kritik hook fonksiyonları herhangi bir dış çağrıya izin verir.
Güvenilmeyen dış çağrılar son derece tehlikelidir, çünkü bu çeşitli saldırı türlerine 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, saldırgan sahte token'leri için kötü niyetli bir likidite havuzu kaydedebilir ve ardından havuzda işlem yapmak için hook'u çağırabilir. Likidite havuzuyla etkileşimde bulunurken, kötü niyetli token mantığı, kötü davranışlar gerçekleştirmek için kontrol akışını ele geçirir.
2.1.3 Tehdit Modeli I için önlemler
Bu tür güvenlik sorunlarıyla ilişkili hook'ları önlemek için, hassas dış/kamu fonksiyonlarına gerekli erişim kontrolünü uygun bir şekilde uygulamak ve giriş parametrelerini doğrulamak, etkileşimleri doğrulamak açısından son derece önemlidir. Ayrıca, yeniden giriş koruması, hook'un standart mantık akışı içinde tekrar tekrar çalıştırılmadığından emin olmaya yardımcı olabilir. Uygun güvenlik önlemleri uygulayarak, fon havuzları bu tür tehditlerle ilişkili riskleri azaltabilir.
![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-ba4bfa88e0ac0b6246e82ad879361ff3.webp(
) 2.2 Tehdit Modeli II'ndeki Güvenlik Sorunları
Bu tehdit modelinde, geliştiricinin ve onun hook'larının kötü niyetli olduğunu varsayıyoruz. Kapsam geniş olduğundan, yalnızca v4 sürümü ile ilgili güvenlik sorunlarına odaklanıyoruz. Bu nedenle, sağlanan hook'un kullanıcı transferlerini veya yetkilendirmelerini işleyip işleyemeyeceği önemlidir.
Hook'a erişim yöntemleri, hook'a verilebilecek yetkileri belirlediğinden, bu nedenle hook'u iki kategoriye 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 ) yönlendirici üzerinden geçmelidir.
Bağımsız Hook(Standalone Hooks): hook, kullanıcıların doğrudan etkileşimde bulunmalarını sağlayan bir giriş noktasıdır.
(# 2.2.1 Yönetilen Hook
Bu durumda, kullanıcının kripto varlıkları ), yerel tokenler ve diğer tokenler ### router'a aktarılır veya yetkilendirilir. PoolManager bakiye kontrolü yaptığı için, kötü niyetli hook'ların bu varlıkları doğrudan çalması kolay değildir. Ancak, yine de 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.
(# 2.2.2 Bağımsız Tip Hook
Hook bir giriş noktası olarak kullanıldığında, durum daha karmaşık hale gelir. Bu durumda, kullanıcıların doğrudan hook ile etkileşimde bulunabilmesi nedeniyle, hook daha fazla yetki kazanır. Teorik olarak, hook bu etkileşim aracılığıyla istenen herhangi bir işlemi gerçekleştirebilir.
v4 sürümünde, kod mantığının doğrulanması son derece önemlidir. Temel 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ükseltme sonrasında kötü niyetli hale gelebileceği anlamına gelir ve bu da önemli bir risk oluşturur. Bu riskler şunları içerir:
Yükseltilebilir ajan ) doğrudan saldırıya uğrayabilir ###;
Kendini yok etme mantığına sahip. selfdestruct ve create2'nin birleşik çağrısında saldırıya uğrayabilir.
(# 2.2.3 Tehdit Modeli II için Önlemler
Kritik bir 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 dikkat etmeliyiz; bağımsız hook'lar için ise, esas odak noktası bunların güncellenebilir olup olmadıkları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 öncelikle Uniswap v4'teki Hook güvenlik sorunlarıyla ilgili temel mekanizmaları kısaca özetlemektedir. Ardından, iki tehdit modeli sunuyoruz ve ilgili güvenlik risklerini kısaca özetliyoruz.
Sonraki makalelerde, her bir tehdit modeli altında güvenlik sorunlarını derinlemesine analiz edeceğiz.