Uniswap v4'ün yakında herkesin kullanımına sunulacağına inanıyorum!

Bu sefer Uniswap ekibinin iddialı hedefleri var ve sınırsız sayıda likidite havuzu desteği ve her işlem çifti için dinamik ücretler, tekil tasarım, yıldırım muhasebesi, Kancalar ve ERC1155 token desteği dahil olmak üzere birçok yeni özelliği [1] tanıtmayı planlıyorlar standart. EIP-1153 tarafından sunulan geçici depolamadan yararlanan Uniswap v4'ün, Ethereum Cancun yükseltmesinden sonra piyasaya sürülmesi bekleniyor.

Pek çok yeniliğin arasında Kanca mekanizması da güçlü potansiyeli nedeniyle geniş ilgi gördü. Hook mekanizması, likidite havuzu yaşam döngüsünün belirli noktalarında belirli kodun yürütülmesini destekleyerek havuzun ölçeklenebilirliğini ve esnekliğini büyük ölçüde artırır.

Ancak kanca mekanizması aynı zamanda iki ucu keskin bir kılıç da olabilir. Güçlü ve esnek olmasına rağmen Hook'u güvenli bir şekilde kullanmak da büyük bir zorluktur. Kancaların karmaşıklığı kaçınılmaz olarak yeni potansiyel saldırı vektörlerini beraberinde getirir. Bu nedenle, topluluğun güvenlik gelişimini teşvik etmek amacıyla Hook mekanizmasıyla ilgili güvenlik sorunlarını ve potansiyel riskleri sistematik olarak tanıtmak için bir dizi makale yazmayı umuyoruz.Bu içgörülerin güvenli bir Uniswap v4 Hook oluşturmaya yardımcı olacağına inanıyoruz.

Bu makale serisinin başlangıcı olan bu makalede, Uniswap v4'teki Hook mekanizması ile ilgili kavramlar tanıtılmakta ve Hook mekanizmasının güvenlik riskleri ana hatlarıyla verilmektedir.

1.Uniswap V4 mekanizması

Bu konuyu derinlemesine incelemeden önce Uniswap v4'ün mekanizması hakkında temel bir anlayışa sahip olmamız gerekiyor. Resmi duyuruya [1] ve tanıtım belgesine [2] göre, Hook'lar, tekil mimari ve yıldırım muhasebesi, özel likidite havuzlarını uygulamak ve birden fazla havuz arasında verimli yönlendirme sağlamak için üç önemli işlevdir.

1.1 Kanca

Hook'lar, likidite havuzu yaşam döngüsünün farklı aşamalarında çalışan sözleşmeleri ifade ediyor. Uniswap ekibi, Hook'ları tanıtarak herkesin takas kararları vermesine olanak sağlamayı umuyor. Bu şekilde, dinamik ücretleri yerel olarak desteklemek, zincir üstü limit emirleri eklemek veya büyük emirleri zaman ağırlıklı ortalama piyasa yapıcı (TWAMM) aracılığıyla dağıtmak mümkün olur.

Şu anda dört gruba ayrılmış sekiz Hook geri araması vardır (her grup bir çift geri arama içerir):

Teknik incelemede [2] tanıtılan Kancaların değiştirilme süreci aşağıdadır.

Şekil 1: Kanca değiştirme işlemi

Uniswap ekibi çalışma yöntemini bazı örneklerle (TWAMM Hook[3] gibi) tanıttı ve topluluk katılımcılarının da katkıları oldu. Resmi belgeler[4] aynı zamanda daha fazla Hook örneği toplayan Awesome Uniswap v4 Hooks[5] deposuna da bağlantı vermektedir.

1.2 Singleton, yıldırım muhasebesi ve kilitleme mekanizması

Uniswap ekibi çalışma yöntemini bazı örneklerle (TWAMM Hook[3] gibi) tanıttı ve topluluk katılımcılarının da katkıları oldu. Resmi belgeler[4] aynı zamanda daha fazla Hook örneği toplayan Awesome Uniswap v4 Hooks[5] deposuna da bağlantı vermektedir.

1.2 Singleton, yıldırım muhasebesi ve kilitleme mekanizması

Singleton mimarisi ve flash muhasebe, maliyetleri düşürerek ve verimliliği sağlayarak performansı artırmak için tasarlanmıştır. Tüm likidite havuzlarının aynı akıllı sözleşmede tutulduğu yeni bir tekli sözleşme getiriyor. Bu tekil tasarım, tüm havuzların durumunu depolamak ve yönetmek için bir PoolManager'a dayanır.

Uniswap protokolünün önceki sürümlerinde, likidite değişimi veya eklenmesi gibi işlemler doğrudan token transferlerini içeriyordu.V4 sürümü, yıldırım muhasebesi ve bir kilit mekanizması sunması bakımından farklıdır.

👇🏻 Kilit mekanizması şu şekilde çalışır:

Özetle kilitleme mekanizması eş zamanlı erişimi engeller ve tüm işlemlerin silinebilmesini sağlar. Soyunma sözleşmesi kilitler için sırayla uygulanır ve ardından işlemleri lockAcquired geri çağrısı aracılığıyla yürütür. İlgili Hook geri araması, her havuz işleminden önce ve sonra tetiklenecektir. Son olarak PoolManager durumu kontrol eder.

Bu yaklaşım, operasyonun anında transfer gerçekleştirmek yerine iç net bakiyeyi (yani deltayı) ayarlaması anlamına gelir. Herhangi bir değişiklik havuzun iç bakiyesine kaydedilecek ve asıl transfer işlemin (yani kilitlenmenin) sonunda yapılacaktır. Bu süreç ödenmemiş token kalmamasını sağlar ve böylece fonların bütünlüğünü korur.

Kilitleme mekanizması nedeniyle Harici Sahiplik Hesapları (EOA) PoolManager ile doğrudan etkileşime giremez. Bunun yerine, herhangi bir etkileşimin bir sözleşme yoluyla gerçekleşmesi gerekir. Bu sözleşme bir ara dolap görevi görür ve herhangi bir havuz işlemi gerçekleştirmeden önce kilit talep edilmesi gerekir.

👇🏻 İki ana sözleşme etkileşim senaryosu vardır:

2. Tehdit modeli

İlgili güvenlik konularını tartışmadan önce tehdit modelini tanımlamamız gerekiyor. Esas olarak aşağıdaki iki durumu göz önünde bulunduruyoruz:

Aşağıdaki bölümlerde bu iki tehdit modeline dayalı olarak olası güvenlik sorunlarını tartışıyoruz.

2.1 Tehdit modeli I'deki güvenlik sorunları

Tehdit Modeli I, Hook'un kendisiyle ilgili güvenlik açıklarına odaklanıyor. Bu tehdit modeli, geliştiricilerin ve kancalarının zararsız olduğunu varsayar. Ancak akıllı sözleşmelerdeki mevcut bilinen güvenlik açıkları Hooks’ta da ortaya çıkabiliyor. Örneğin, bir Hook yükseltilebilir bir sözleşme olarak uygulanırsa, OpenZeppelin'in UUPSUpgradeable güvenlik açığıyla ilgili sorunlarla karşılaşabilir.

Tehdit Modeli I, Hook'un kendisiyle ilgili güvenlik açıklarına odaklanıyor. Bu tehdit modeli, geliştiricilerin ve kancalarının zararsız olduğunu varsayar. Ancak akıllı sözleşmelerdeki mevcut bilinen güvenlik açıkları Hooks’ta da ortaya çıkabiliyor. Örneğin, bir Hook yükseltilebilir bir sözleşme olarak uygulanırsa, OpenZeppelin'in UUPSUpgradeable güvenlik açığıyla ilgili sorunlarla karşılaşabilir.

Yukarıdaki faktörler ışığında v4 sürümüne özel potansiyel güvenlik açıklarına odaklanmayı seçtik. Uniswap v4'te Kancalar, çekirdek havuz işlemlerinden önce veya sonra (başlatma, konumu değiştirme, değiştirme ve toplama dahil) özel mantığı yürütebilen akıllı sözleşmelerdir. Hook'ların standart arayüzleri uygulaması beklenmesine rağmen, aynı zamanda özel mantığın dahil edilmesine de izin verir. Bu nedenle tartışmamız standart Hook arayüzünü içeren mantıkla sınırlı olacaktır. Daha sonra, örneğin Hook'ların bu standart Hook işlevlerini nasıl kötüye kullanabileceği gibi olası güvenlik açıkları kaynaklarını belirlemeye çalışacağız.

👇🏻 Özellikle aşağıdaki iki Kanca türüne odaklanacağız:

Bu iki kapsamın dışındaki kancaların tartışmamızın kapsamı dışında olduğunu lütfen unutmayın.

Bu yazının yazıldığı sırada Hook'ların gerçek kullanım durumları olmadığından, Awesome Uniswap v4 Hooks deposundan bazı bilgiler alacağız.

Awesome Uniswap v4 Hooks deposu üzerinde derinlemesine bir çalışma yaptıktan sonra (hash 3a0a444922f26605ec27a41929f3ced924af6075'i taahhüt edin), birkaç kritik güvenlik açığı keşfettik. Bu güvenlik açıkları temel olarak kancalar, PoolManager ve harici üçüncü taraflar arasındaki risk etkileşimlerinden kaynaklanır ve temel olarak iki kategoriye ayrılabilir: erişim kontrolü sorunları ve giriş doğrulama sorunları. Spesifik bulgular için lütfen aşağıdaki tabloya bakın:

Toplamda 22 ilgili proje bulduk (Uniswap v4 ile ilgili olmayan projeler hariç). Bu projelerden 8'inin (%36) hassas olduğunu düşünüyoruz. Savunmasız olan sekiz projeden altısında erişim kontrolü sorunları vardı ve ikisinde güvenilmeyen dış aramalara karşı savunmasızdı.

2.1.1 Erişim kontrolü sorunları

Tartışmanın bu bölümünde, esas olarak v4'teki geri çağırma işlevlerinin neden olabileceği, 8 kancalı geri arama ve kilit geri aramaları da dahil olmak üzere sorunlara odaklanıyoruz. Elbette doğrulanması gereken başka durumlar da var ancak bu durumlar tasarıma göre değişiklik gösterir ve tartışmamızın kapsamı dışındadır.

Bu işlevler yalnızca PoolManager tarafından çağrılmalı ve diğer adresler (EOA ve sözleşmeler dahil) tarafından çağrılamamalıdır. Örneğin, ödüllerin havuz anahtarları ile dağıtıldığı durumda, karşılık gelen işlevin herhangi bir hesap tarafından çağrılabilmesi durumunda ödüller hatalı bir şekilde talep edilebilir.

Bu nedenle, özellikle havuzun kendisi dışındaki taraflarca da çağrılabilecekleri için kancalar için güçlü erişim kontrol mekanizmaları oluşturmak çok önemlidir. Likidite havuzları, erişim haklarını sıkı bir şekilde yöneterek, kancalarla yetkisiz veya kötü niyetli etkileşim riskini önemli ölçüde azaltabilir.

2.1.2 Giriş doğrulama soruları

Uniswap v4'te kilit mekanizması nedeniyle kullanıcıların herhangi bir fon havuzu işlemi yapmadan önce sözleşme yoluyla kilit alması gerekmektedir. Bu, halihazırda etkileşime katılan sözleşmenin en son kilit sözleşme olmasını sağlar.

Bununla birlikte, bazı savunmasız Hook uygulamalarında hatalı giriş doğrulaması nedeniyle güvenilmeyen harici çağrılar gibi olası bir saldırı senaryosu hala mevcuttur:

Güvenilmeyen dış çağrılar son derece tehlikelidir çünkü yeniden giriş saldırıları olarak bildiğimiz saldırılar da dahil olmak üzere çeşitli türde saldırılara yol açabilirler.

Güvenilmeyen dış çağrılar son derece tehlikelidir çünkü yeniden giriş saldırıları olarak bildiğimiz saldırılar da dahil olmak üzere çeşitli türde saldırılara yol açabilirler.

Saldırgan, bu savunmasız kancalara saldırmak için kendi sahte token'ları için kötü amaçlı bir fon havuzu kaydedebilir ve ardından fon havuzundaki işlemleri gerçekleştirmek için kancayı çağırabilir. Havuzla etkileşimde bulunurken, kötü niyetli belirteç mantığı, istenmeyen davranışlara girişmek için kontrol akışını ele geçirir.

2.1.3 Tehdit modeline karşı önleyici tedbirler I

Kancalarla ilgili bu tür güvenlik sorunlarını aşmak için, hassas harici/genel işlevlere gerekli erişim kontrollerini uygun şekilde uygulayarak ve giriş parametrelerini doğrulayarak etkileşimlerin kimliğini doğrulamak çok önemlidir. Ek olarak, yeniden giriş koruması, kancaların standart mantık akışında tekrar tekrar çalıştırılmamasını sağlamaya yardımcı olabilir. Havuzlar, uygun güvenlik önlemlerini uygulayarak bu tür tehditlerle ilişkili riskleri azaltabilir.

2.2 Tehdit Modeli II'deki Güvenlik Sorunları

Bu tehdit modelinde geliştiricinin ve kancasının kötü niyetli olduğunu varsayıyoruz. Kapsamın geniş olması nedeniyle yalnızca v4 sürümüyle ilgili güvenlik sorunlarına odaklanıyoruz. Bu nedenle önemli olan, sağlanan kancanın kullanıcı tarafından aktarılan veya yetkilendirilen kripto varlıklarını işleyip işleyemeyeceğidir.

Kancaya erişim yöntemi, kancaya verilebilecek izinleri belirlediğinden, kancaları iki kategoriye ayırıyoruz:

Şekil 2: Kötü amaçlı kanca örneği

2.2.1 Yönetilen Kanca

Bu durumda kullanıcının kripto varlıkları (yerel tokenlar ve diğer tokenlar dahil) yönlendiriciye aktarılır veya yetkilendirilir. PoolManager bakiye kontrolleri yaptığı için kötü niyetli kancaların bu varlıkları doğrudan çalması kolay değildir. Ancak hâlâ potansiyel bir saldırı yüzeyi mevcut. Örneğin v4 sürümünün gider yönetimi mekanizması, saldırganlar tarafından kancalar aracılığıyla manipüle edilebilir.

2.2.2 Bağımsız Kanca

Kancalar giriş noktası olarak kullanıldığında durum daha karmaşıktır. Bu durumda kanca daha fazla güç kazanır çünkü kullanıcı onunla doğrudan etkileşime girebilir. Teorik olarak bir kanca bu etkileşimle istediği her şeyi yapabilir.

V4 sürümünde kod mantığının doğrulanması oldukça kritiktir. Asıl mesele kod mantığının manipüle edilip edilemeyeceğidir. Bir kanca yükseltilebilirse, bu, görünüşte güvenli olan bir kancanın yükseltildikten sonra kötü amaçlı hale gelebileceği ve önemli bir risk oluşturabileceği anlamına gelir. Bu riskler şunları içerir:

2.2.3 Tehdit modeline karşı önleyici tedbirler II

Kancanın kötü amaçlı olup olmadığını değerlendirmek çok önemlidir. Özellikle, yönetilen kancalar için maliyet yönetimi davranışına odaklanmalıyız; bağımsız kancalar için ise ana odak bunların yükseltilebilir olup olmadığıdır.

3.Sonuç

Kancanın kötü amaçlı olup olmadığını değerlendirmek çok önemlidir. Özellikle, yönetilen kancalar için maliyet yönetimi davranışına odaklanmalıyız; bağımsız kancalar için ise ana odak bunların yükseltilebilir olup olmadığıdır.

3.Sonuç

Bu makalede öncelikle Uniswap v4'ün Hook güvenlik sorunlarıyla ilgili temel mekanizmalara kısa bir genel bakış sunuyoruz. Daha sonra iki tehdit modeli öneriyoruz ve ilgili güvenlik risklerini kısaca özetliyoruz.

Sonraki makalelerde her tehdit modeli kapsamındaki güvenlik sorunlarının derinlemesine bir analizini yapacağız.