Uniswap v4 geliyor! Ekip, her işlem çifti için (teorik olarak) sınırsız sayıda havuz ve dinamik ücret oranları, tekil yapı (singleton), anlık muhasebe (flash accounting), kancalar (hooks) ve ERC1155 desteği dahil olmak üzere bir dizi yeni özellik[1] sunmayı planlıyor. EIP-1153 ile tanıtılan geçici depolamadan (transient storage) yararlanan Uniswap v4'ün, Ethereum'un Cancun yükseltmesinin ardından kullanıma sunulması beklenmektedir.
Bu yenilikler arasında kanca (hook) mekanizması, güçlü potansiyeli nedeniyle büyük ilgi görmektedir. Mekanizma, bir havuzun işleyişi sırasında belirli noktalarda özel kodların çalıştırılmasına olanak tanıyarak havuzların genişletilebilirliğini ve esnekliğini önemli ölçüde artırmaktadır.
Ancak kanca mekanizması aynı zamanda iki tarafı keskin bir kılıç gibi de olabilir. Güçlü ve esnek olmasının yanı sıra, güvenli bir şekilde kullanılmasındaki zorluk göz ardı edilemez. Bu karmaşıklık, kaçınılmaz olarak yeni potansiyel saldırı vektörlerini de beraberinde getirmektedir. Güvenlik perspektifinden topluma katkıda bulunmak amacıyla hedefimiz, bu mekanizmayla ilgili güvenlik sorunlarını ve endişelerini sistematik bir şekilde ele alan bir makale serisi sunmaktır. Bu içgörülerin, güvenli Uniswap v4 kancaları oluşturulmasına ışık tutacağına inanıyoruz.
Bu makale serinin ilki olup okuyucularımıza kapsamlı bir genel bakış ve temel bir anlayış sunmaktadır. Daha fazla bilgilendirici tartışma için bizi takip etmeye devam edin!
Uniswap v4'ün Mekanizması
Ayrıntılara girmeden önce, Uniswap v4'ün mekanizması hakkında temel bir anlayışa sahip olmamız gerekmektedir. Resmi duyuruya[1] ve teknik rapora (whitepaper)[2] göre kancalar, tekil yapı (singleton) mimarisi ve anlık muhasebe (flash accounting); havuz özelleştirmesini ve birçok havuz arasında verimli yönlendirmeyi sağlayan üç temel özelliktir.
Kancalar (Hooks)
v4'teki kancalar, bir havuz eyleminin yaşam döngüsünün çeşitli noktalarında çalışan sözleşmeler olan kancalar aracılığıyla herkesin tercih kararları almasına olanak tanımak üzere tasarlanmıştır. Bu sayede, dinamik ücretleri yerel olarak destekleyen havuzların özelleştirilmesi, zincir üstü limit emirlerinin eklenmesi veya büyük emirleri zaman içinde yaymak için zaman ağırlıklı ortalama piyasa yapıcısı (TWAMM) olarak hareket edilmesi mümkün olmaktadır.
Şu anda, dört grup halinde düzenlenmiş sekiz kanca geri çağırması (hook callback) bulunmaktadır (her grup bir çift geri çağırma içerir):
- beforeInitialize/afterInitialize
- beforeModifyPosition/afterModifyPosition
- beforeSwap/afterSwap
- beforeDonate/afterDonate
Aşağıda, teknik rapor[2] tarafından sağlanan takas kancası akışı gösterilmektedir.
Uniswap ekibi, kullanımı göstermek için bazı örnekler (örneğin, TWAMM Kancası[3]) sağlamış olup topluluktaki katılımcılar da katkılarını sunmaktadır. Resmi belge[4], daha fazla kanca örneği derleyen Awesome Uniswap v4 Hooks[5] deposuna bağlantı vermektedir.
Tekil Yapı (Singleton), Anlık Muhasebe (Flash Accounting) ve Kilit Mekanizması
Tekil yapı ve anlık muhasebe, maliyetleri azaltarak ve verimliliği sağlayarak performansı iyileştirmek amacıyla tasarlanmıştır. Özellikle, tüm havuzların tek bir akıllı sözleşme içinde bulunduğu yeni bir singleton sözleşmesi tanıtılmaktadır. Bu tekil yapı tasarımı, tüm havuzlar için tüm durumları depolamak ve yönetmek amacıyla bir PoolManager'a dayanmaktadır.
Takas veya likidite ekleme gibi işlemlerin doğrudan token transferlerini içerdiği Uniswap Protokolü'nün önceki sürümlerinden farklı olarak Uniswap v4, anlık muhasebeyi bir kilit mekanizması ile birlikte tanıtmaktadır.
Özellikle, kilit mekanizması aşağıdaki şekilde çalışmaktadır:
- Bir kilitleyici sözleşme,
PoolManagerüzerinde kilit talep eder. PoolManager, kilitleyicinin adresini lockData kuyruğuna ekler velockAcquiredgeri çağırmasını başlatır.- Kilitleyici, geri çağırma içindeki mantığını çalıştırır. Kilitleyicinin yürütülmesi sırasında havuzlarla etkileşimleri sıfır olmayan para birimi deltalarına yol açabilir. Ancak yürütmenin sonunda tüm deltalar sıfıra kapatılmalıdır. Bunun yanı sıra, lockData kuyruğu boş değilse yalnızca son kilitleyici işlem gerçekleştirebilir.
- Ardından,
PoolManagerlockData kuyruğunun ve para birimi deltalarının durumunu kontrol eder. Doğrulama üzerine,PoolManagerkilitleyiciyi kaldırır.
Özetle, kilit mekanizması eş zamanlı erişimi önler ve kapatmayı sağlar. Kilitleyiciler kilitler için sıraya girer, ardından lockAcquired geri çağırması aracılığıyla çalışır. Havuz eylemlerinden önce ve sonra, belirtilen kanca geri çağırmaları başlatılır. Son olarak, PoolManager durumu kontrol eder.
Bu yaklaşım, işlemlerin anlık transferler gerçekleştirmek yerine dahili bir net bakiyeyi (yani delta) ayarladığı anlamına gelir. Herhangi bir değişiklik havuzun dahili bakiyesine kaydedilir; gerçek transferler ise işlemin sonunda (yani kilit) gerçekleşir. Bu süreç, bekleyen token olmamasını garanti ederek ödeme gücünü korur.
Kilit mekanizması nedeniyle, bir EOA (Harici Sahipli Hesap) doğrudan PoolManager ile etkileşime giremez. Bunun yerine, her etkileşimin bir sözleşme üzerinden gerçekleşmesi gerekir. Sözleşme, herhangi bir havuz eyleminden önce kilit talep etmek için ara bir kilitleyici olarak görev yapar.
Başlıca iki sözleşme etkileşim senaryosu vardır:
-
Kilitleyici sözleşme, resmi depodan gelir veya kullanıcılar tarafından dağıtılmıştır. Bu durumlarda, etkileşimleri bir yönlendirici aracılığıyla gerçekleşiyor olarak değerlendirebiliriz.
-
Kilitleyici ve kanca aynı sözleşmeye entegre edilmiş veya üçüncü taraf bir kuruluş tarafından kontrol ediliyor. Bu senaryo için, etkileşimleri bir kanca aracılığıyla gerçekleşiyor olarak değerlendirebiliriz. Dolayısıyla kanca, hem kilitleyici hem de geri çağırma işleyicisi olarak çift rol üstlenir.
Tehdit Modelleri
Karşılık gelen güvenlik sorunlarını tartışmadan önce tehdit modellerinin belirlenmesi gerekmektedir. Temel olarak, kancaları kullanırken ortaya çıkan belirli hususlar vardır:
- Tehdit modeli I: Kancalar zararsız ancak savunmasızdır.
- Tehdit modeli II: Kancalar kötü niyetlidir.
Aşağıdaki bölümlerde, tehdit modellerine dayalı olası güvenlik sorunlarını/endişelerini ele alacağız.
Tehdit Modeli I'deki Güvenlik Endişeleri
Tehdit modeli I, kancaların kendileriyle ilgili güvenlik açıklarına odaklanmaktadır. Açıkça belirtmek gerekirse, bu tehdit modeli geliştiricilerin ve kancalarının zararsız olduğunu varsaymaktadır. Ancak, akıllı sözleşmelerin mevcut bilinen güvenlik açıkları kancalarda da ortaya çıkabilir. Örneğin, kanca yükseltilebilir bir sözleşme olarak uygulanmışsa, OZ kütüphanesinin UUPSUpgradeable güvenlik açığına[6] benzer bazı güvenlik açıklarından etkilenebilir.
Bu hususlar göz önüne alındığında, v4'e özgü potansiyel güvenlik açıklarına odaklanmayı tercih ediyoruz. Özellikle, Uniswap v4'te kancalar; temel havuz eylemlerinden (initialize, modifyPosition, swap ve donate dahil) önce veya sonra mantık çalıştırabilen özelleştirilebilir akıllı sözleşmelerdir. Kancaların standart kanca arayüzünü uygulaması beklenmektedir; ancak özelleştirilmiş mantığı da bünyelerine katabilirler. Bu nedenle, kapsamımız standart kanca arayüzüyle ilişkili mantıkla sınırlıdır. Daha sonra, kancaların bu standart kanca işlevlerini nasıl kullanabileceğini özetleyerek potansiyel güvenlik açığı kaynaklarını tespit edebiliriz.
Genel olarak, kancalar iki kategoriye ayrılabilir:
- Kullanıcı fonlarının koruyucusu olarak hareket eden kancalar. Bu durumlarda, saldırganlar fonları transfer etmek için kancayı hedef alabilir ve bu da varlık kayıplarına yol açabilir.
- Kullanıcılar veya diğer protokoller tarafından güvenilen kritik durum verilerini depolayan kancalar. Bu tür kancalar için saldırganlar, kritik durumları kasıtlı olarak değiştirebilir. Yanlış durumlar, diğer kullanıcılar veya protokoller tarafından kullanıldığında potansiyel riskler doğurur.
Bu iki kategoriye uymayan kancaların tartışma kapsamımız dışında olduğunu unutmayın.
Sınırlı kapsama rağmen, burada tüm olasılıkları saymak hâlâ mümkün değildir. Bu yazının hazırlandığı tarihte gerçek uygulamalar bulunmadığından, bazı içgörüler için Awesome Uniswap v4 Hooks deposunu incelemeye karar verdik.
Depoyu (3a0a444922f26605ec27a41929f3ced924af6075 commit karması ile) kapsamlı bir şekilde inceledikten sonra, birkaç kritik güvenlik açığı tespit ettik. Bunlar esas olarak kancalar, PoolManager ve harici üçüncü taraflar arasındaki riskli etkileşimlerden kaynaklanmaktadır. Güvenlik açıkları iki ana kategoriye ayrılmaktadır: hatalı erişim kontrolü ve uygunsuz girdi doğrulaması. Bulgular aşağıdaki tabloda özetlenmiştir:
| # hatalı proje sayısı | # hatalı erişim kontrolü sayısı | # uygunsuz girdi doğrulaması sayısı |
|---|---|---|
| 8 | 6 | 2 |
Genel olarak, 22 ilgili proje belirledik (Uniswap v4 ile ilgisiz görünenler hariç). Bunlardan 8'i (veya %36'sı) savunmasız olarak değerlendirildi. Özellikle, bu savunmasız projelerden 6'sında hatalı erişim kontrolü tespit edilirken 2'si güvenilmez harici çağrılara karşı savunmasızdı.
Hatalı Erişim Kontrolü
Bu tartışmada, 8 kanca geri çağırması ve kilit geri çağırmasını içeren v4'ün geri çağırma işlevlerinden kaynaklanan v4 ile ilgili erişim kontrolü sorunlarına odaklanıyoruz. Elbette, diğer durumların da doğrulanması gerekebilir. Ancak bu durumlar tasarıma bağlıdır ve önceki tartışmamızda belirlenen kapsamın dışındadır.
Bu işlevler yalnızca PoolManager tarafından çağrılmalıdır; diğer adresler (EOA'lar ve sözleşmeler dahil) tarafından değil. Örneğin, bir ödülün havuz anahtarına göre dağıtıldığı bir durumu düşünün. Karşılık gelen işlev keyfi hesaplar tarafından çağrılabilirse, ödül hatalı şekilde talep edilebilir.
Bu göz önünde bulundurulduğunda, kancalar için sağlam erişim kontrolü mekanizmaları oluşturmak kritik öneme sahiptir; özellikle havuzun kendisi dışındaki taraflarca çağrılabilecekleri için. Erişim izinlerinin dikkatli yönetimi ile havuzlar, kancalarla yetkisiz veya kötü niyetli etkileşimlerin riskini önemli ölçüde azaltabilir.
Uygunsuz Girdi Doğrulaması
Uniswap v4'te, kilit mekanizması nedeniyle kullanıcıların herhangi bir havuz eylemi gerçekleştirmeden önce bir sözleşme aracılığıyla kilit edinmesi gerekir. Bu, şu anda etkileşimde bulunan sözleşmenin en son kilitleyici olmasını sağlar.
Buna rağmen, bazı savunmasız kanca uygulamalarında uygunsuz girdi doğrulaması nedeniyle güvenilmez harici çağrı gibi potansiyel bir saldırı senaryosu hâlâ mevcuttur:
- İlk olarak, kanca kullanıcıların etkileşime girmek istediği havuzu doğrulamaz. Bu, sahte tokenlar taşıyan ve zararlı mantık çalıştıran kötü niyetli bir havuz olabilir.
- İkinci olarak, bazı kritik kanca işlevleri keyfi harici çağrılara izin vermektedir.
Güvenilmez harici çağrı son derece tehlikelidir; çünkü iyi bilinen yeniden giriş (reentrancy) sorunları da dahil olmak üzere çeşitli saldırı türlerine yol açabilir.
Bu tür savunmasız kancaları istismar etmek için bir saldırgan, sahte tokenları için kötü niyetli bir havuz kaydedebilir, ardından kancayı havuz üzerinde eylem gerçekleştirmek için çağırabilir. Havuzla etkileşim sırasında, kötü niyetli token mantığı kötü davranışları kolaylaştırmak için kontrol akışını ele geçirir.
Tehdit Modeli I için Azaltma Önlemleri
Kancalardaki bu tür sorunları aşmak için, hassas harici/genel işlevlere uygun erişim kontrolü zorunlu kılarak ve girdi argümanlarını doğrulayarak etkileşimlerin geçerliliğini sağlamak önemlidir. Bunun yanı sıra, bir yeniden giriş koruması (reentrancy guard), kancaların standart mantık akışı içinde tekrar tekrar çalıştırılamamasını sağlamak için yararlı olabilir. Uygun güvenlik önlemleri alarak havuzlar, bu tür tehditlerle ilişkili riskleri azaltabilir.
Tehdit Modeli II'deki Güvenlik Endişeleri
Bu tehdit modelinde geliştiricilerin ve kancalarının kötü niyetli olduğu varsayılmaktadır. Geniş olasılık yelpazesi göz önüne alındığında, öncelikle v4 ile ilgili sorunlara odaklanmayı tercih ettik. Sonuç olarak, sağlanan kancaların kullanıcıların transfer ettiği veya onay verdiği kripto varlıkları yönetip yönetemeyeceği temel bir husus olmaktadır.
Kancalara erişim yöntemine göre -bu yöntem, kancalara verilen potansiyel izinleri belirler- kancaları iki farklı kategoriye ayırabiliriz:
- Yönetilen Kancalar (Managed Hooks): Kancalar giriş noktası değildir. Kullanıcıların kancalarla muhtemelen Uniswap tarafından sağlanan bir yönlendirici aracılığıyla etkileşime girmesi gerekir.
- Bağımsız Kancalar (Standalone Hooks): Kancalar giriş noktasıdır ve kullanıcıların doğrudan onlarla etkileşime girmesine olanak tanır.
Yönetilen Kancalar (Managed Hooks)
Yönetilen Kancalar durumunda, kullanıcıların kripto varlıkları (yerel tokenlar ve diğerleri dahil) yönlendiriciye transfer edilir veya onay verilir. PoolManager tarafından uygulanan bakiye kontrolü nedeniyle, kötü niyetli kancaların bu varlıkları doğrudan ele geçirmesi kolay değildir.
Ancak potansiyel saldırı yüzeyleri hâlâ mevcuttur. Örneğin, v4'teki ücret yönetimi mekanizması, kancalar aracılığıyla saldırganlar tarafından potansiyel olarak manipüle edilebilir.
Bağımsız Kancalar (Standalone Hooks)
Kancalar, Bağımsız Kancalar biçiminde giriş noktası olarak kullanıldığında durum daha karmaşık hale gelir. Bu senaryoda, kullanıcıların doğrudan onlarla etkileşime girebilmesi nedeniyle kancalar daha fazla güç kazanır. Teorik olarak, kancalar bu etkileşim aracılığıyla istedikleri her eylemi gerçekleştirebilir.
v4 senaryosunda, kod mantığının doğrulanması kritik bir noktadır. Temel endişe, kod mantığının manipüle edilip edilemeyeceğidir. Kancalar yükseltilebilir olarak uygulanabilir; bu, güvenli görünen bir kancanın daha sonra potansiyel olarak kötü niyetli bir versiyona yükseltilebileceği ve önemli bir risk oluşturabileceği anlamına gelir. Bu şunları içerir:
- Doğrudan istismar edilebilen yükseltilebilir proxy'ler;
selfdestructvecreate2'nin birlikte kullanımından dolayı istismar edilebilen kendi kendini imha eden mantıkla donatılmış yapılar.
Tehdit Modeli II için Azaltma Önlemleri
Kancaların kötü niyetli olup olmadığını değerlendirmek önemlidir. Özellikle, yönetilen kancalar için ücret yönetiminin davranışına odaklanmalıyız; bağımsız kancalar için ise temel endişe, yükseltilebilir olup olmadıklarıdır.
Sonuç
Bu makalede, öncelikle v4 kancalarının güvenlik sorunlarıyla ilgili Uniswap v4'ün temel mekanizmalarına ilişkin kısa bir özet sunuyoruz. Ardından iki tehdit modeli tanımlıyor ve her birinin güvenlik sorunları hakkında üst düzey bir tartışma sunuyoruz. Bu serinin önümüzdeki makalelerinde, her tehdit modeli kapsamındaki güvenlik sorunlarının ayrıntılı analizlerini sunacağız. Takipte kalın!
Kaynakça
[1] Uniswap V4 için Vizyonumuz
[2] Uniswap v4 teknik rapor taslağı
[4] Kanca Örnekleri
[5] Harika Uniswap v4 Kancaları
[6] UUPSUpgradeable Güvenlik Açığı Olay Sonrası İncelemesi
