ثنائية آلية Hook في Uniswap v4: الابتكار والمخاطر المحتملة
من المقرر إطلاق Uniswap v4 قريبًا، وهذه الترقية تعتبر طموحة للغاية. ستقدم النسخة الجديدة العديد من الوظائف الجديدة، بما في ذلك دعم عدد غير محدود من أحواض السيولة لكل زوج تداول، والرسوم الديناميكية، وتصميم فردي، ومحاسبة فورية، وآلية Hook، بالإضافة إلى دعم معيار ERC1155 للرموز. باستخدام تقنية التخزين المؤقت، من المتوقع أن يتم إصدار Uniswap v4 بعد ترقية إيثريوم كانكون.
بين العديد من الابتكارات، تحظى آلية Hook باهتمام كبير بسبب إمكانياتها القوية. تتيح هذه الآلية تنفيذ كود مخصص في نقاط محددة من دورة حياة بركة السيولة، مما يعزز بشكل كبير قابلية التوسع والمرونة للبركة.
ومع ذلك، قد تكون آلية Hook سيفًا ذو حدين. على الرغم من أنها قوية ومرنة، فإن الاستخدام الآمن لـ Hook يواجه أيضًا تحديات كبيرة. لا مفر من أن تعقيد Hook يجلب معه نقاط هجوم محتملة جديدة. لذلك، من الضروري تقديم نظرة شاملة حول القضايا الأمنية والمخاطر المحتملة المرتبطة بآلية Hook، من أجل تعزيز التنمية الآمنة للمجتمع، وستساعد هذه الرؤى في بناء Hook أكثر أمانًا لـ Uniswap v4.
ستقدم هذه المقالة مفاهيم آلية Hook في Uniswap v4، وتستعرض المخاطر الأمنية الموجودة.
ميكانيكا Uniswap V4
قبل الخوض في التفاصيل، نحتاج إلى فهم الأساسيات حول آلية Uniswap v4. وفقًا للإعلان الرسمي والمستند الأبيض، فإن Hook، والهندسة المعمارية الأحادية، والمحاسبة الفورية هي الوظائف الثلاثة المهمة لتحقيق برك السيولة المخصصة وتوجيه فعال عبر برك متعددة.
1.1 هوك
Hook هو عقد يعمل في مراحل مختلفة من دورة حياة تجمع السيولة ، حيث يأمل فريق Uniswap من خلال إدخال Hook أن يتمكن أي شخص من اتخاذ قرارات موازنة. يمكن أن يتيح هذا الدعم الأصلي للرسوم الديناميكية ، وإضافة أوامر محددة السعر على السلسلة ، أو من خلال صانع السوق الموزع للطلبات الكبيرة باستخدام المتوسط المرجح بالوقت (TWAMM).
يوجد حاليًا ثمانية استدعاءات Hook، مقسمة إلى أربع مجموعات ( تحتوي كل مجموعة على زوج من الاستدعاءات ):
قبل التهيئة/بعد التهيئة
قبل تعديل الموقف/بعد تعديل الموقف
قبل التبادل/بعد التبادل
قبل التبرع/بعد التبرع
قدمت فريق Uniswap بعض الأمثلة ( مثل طريقة تشغيل TWAMM Hook )، كما قدم المشاركون في المجتمع بعض المساهمات. تربط الوثائق الرسمية أيضًا بمستودع Awesome Uniswap v4 Hooks، الذي يجمع المزيد من أمثلة Hook.
1.2 نمط وحيد، محاسبة البرق وآلية القفل
تهدف بنية السجل الفردي والتسجيل الفوري إلى تحسين الأداء من خلال خفض التكاليف وضمان الكفاءة. وقد قدمت عقد singleton جديد، حيث يتم الاحتفاظ بجميع برك السيولة في نفس العقد الذكي. يعتمد هذا التصميم الفردي على PoolManager لتخزين وإدارة حالة جميع البرك.
يقدم الإصدار Uniswap v4 آلية محاسبة فورية وآلية قفل. تعمل آلية القفل كما يلي:
يتطلب عقد locker قفلًا على PoolManager.
يقوم PoolManager بإضافة عنوان عقد locker إلى قائمة lockData، ثم يستدعي رد الاتصال lockAcquired.
يتم تنفيذ منطق عقد locker في رد النداء. قد تؤدي التفاعلات بين عقد locker والمسبح خلال عملية التنفيذ إلى زيادة غير صفرية في العملات. ولكن عند انتهاء التنفيذ، يجب تسوية جميع الزيادات لتكون صفرًا. بالإضافة إلى ذلك، إذا كانت قائمة lockData غير فارغة، يمكن فقط لعقد locker الأخير تنفيذ العمليات.
يقوم PoolManager بفحص حالة قائمة lockData وحالة الزيادة في العملة. بعد التحقق، سيقوم PoolManager بحذف عقدة الlocker.
بشكل عام، تمنع آلية القفل الوصول المتزامن وتضمن تسوية جميع المعاملات. يتقدم عقد القفل للحصول على القفل بالترتيب، ثم يتم تنفيذ المعاملات من خلال رد الاتصال lockAcquired. قبل وبعد كل عملية في المسبح، سيتم استدعاء رد الاتصال المقابل. أخيرًا، سيتحقق PoolManager من الحالة.
تعني هذه الطريقة أن التعديلات التشغيلية تتعلق بالرصيد الصافي الداخلي ( أي دلتا )، وليس تنفيذ التحويل الفوري. سيتم تسجيل أي تعديلات في الرصيد الداخلي للمجمع، بينما يتم إجراء التحويل الفعلي عند انتهاء العملية ( أي قفل ). تضمن هذه العملية عدم وجود رموز غير مسددة، مما يحافظ على سلامة الأموال.
نظرًا لوجود آلية القفل، لا يمكن لجميع الحسابات الخارجية (EOA) التفاعل مباشرة مع PoolManager. بدلاً من ذلك، يجب أن تتم أي تفاعلات من خلال العقد. يعمل هذا العقد كخزانة وسيطة، ويجب طلب القفل قبل إجراء أي عمليات على المسبح.
يوجد نوعان رئيسيان من سيناريوهات التفاعل مع العقود:
عقد locker يأتي من مكتبة التعليمات البرمجية الرسمية، أو يتم نشره بواسطة المستخدم. يمكن اعتبار هذه الحالة تفاعل عبر جهاز التوجيه.
يتم دمج عقد locker وعقد Hook في نفس العقد، أو يتم التحكم فيه بواسطة كيان ثالث. يمكن اعتبار هذه الحالة تفاعلًا عبر Hook. في هذه الحالة، يلعب Hook دور عقد locker ويكون مسؤولاً أيضًا عن معالجة الاستدعاءات.
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-f652bf2a22ca7f28f19b4ce9880d0548.webp)
نموذج التهديد
قبل مناقشة المسائل الأمنية ذات الصلة، نحتاج إلى تحديد نموذج التهديد. يجب أن نأخذ في الاعتبار حالتين رئيسيتين:
نموذج التهديد I: هوك نفسه غير ضار، لكنه يحتوي على ثغرات.
نموذج التهديد II: هوك نفسه خبيث.
بعد ذلك، سيتم مناقشة القضايا الأمنية المحتملة بناءً على هذين النموذجين للتهديد.
2.1 مشاكل الأمان في نموذج التهديد I
نموذج التهديد I يركز على الثغرات المتعلقة بـ Hook نفسه. يفترض هذا النموذج أن المطورين و Hook الخاص بهم غير ضارين. ومع ذلك، قد تظهر الثغرات المعروفة الموجودة في العقود الذكية أيضًا في Hook. على سبيل المثال، إذا تم تنفيذ Hook كعقد قابل للتحديث، فقد يواجه مشكلات مشابهة لتلك المتعلقة بثغرة UUPSUpgradeable من OpenZeppelin.
نظرًا للعوامل المذكورة أعلاه، اخترنا التركيز على الثغرات المحتملة الخاصة بإصدار v4. في Uniswap v4، يعتبر Hook عقدًا ذكيًا قادرًا على تنفيذ منطق مخصص قبل أو بعد العمليات الأساسية في المسبح، بما في ذلك التهيئة، تعديل المواقع، التبادل وجمع (. على الرغم من أنه من المتوقع أن يحقق Hook واجهة معيارية، إلا أنه يسمح أيضًا بتضمين منطق مخصص. لذلك، ستقتصر مناقشتنا على المنطق المتعلق بواجهة Hook القياسية. ثم، سنحاول تحديد مصادر الثغرات المحتملة، مثل كيفية استغلال Hook لهذه الوظائف القياسية.
بشكل محدد، سنركز على نوعين من الـ Hook:
النوع الأول من الـhook، حفظ أموال المستخدمين. في هذه الحالة، قد يقوم المهاجم باستهداف هذا الـhook لنقل الأموال، مما يتسبب في خسارة الأصول.
النوع الثاني من الـ hook، تخزين بيانات الحالة الأساسية التي تعتمد عليها المستخدمين أو بروتوكولات أخرى. في هذه الحالة، قد يحاول المهاجم تغيير الحالة الأساسية. عندما يستخدم مستخدمون أو بروتوكولات أخرى حالة خاطئة، قد يؤدي ذلك إلى مخاطر محتملة.
يرجى ملاحظة أن الخطاطيف خارج هذين النطاقين ليست ضمن نطاق مناقشتنا.
بعد البحث المتعمق في مستودع Awesome Uniswap v4 Hooks، اكتشفنا عدة ثغرات خطيرة. تنبع هذه الثغرات بشكل أساسي من التفاعلات المائية بين hook و PoolManager و الأطراف الخارجية، ويمكن تقسيمها بشكل رئيسي إلى فئتين: مشاكل التحكم في الوصول ومشاكل التحقق من المدخلات.
بشكل عام، وجدنا 22 مشروعًا ذا صلة ) باستثناء المشاريع غير المتعلقة بـ Uniswap v4 (. من بين هذه المشاريع، نعتقد أن هناك 8 مشاريع )36% ( بها ثغرات. من بين هذه المشاريع الثمانية التي بها ثغرات، يوجد 6 بها مشاكل في التحكم بالوصول، و2 عرضة لاستدعاءات خارجية غير موثوقة.
)# 2.1.1 مشكلة التحكم في الوصول
في هذا الجزء من المناقشة، نركز بشكل أساسي على المشكلات التي قد تسببها دوال الاستدعاء في v4، بما في ذلك 8 دوال استدعاء (hook) واستدعاء (lock). بالطبع، هناك حالات أخرى تحتاج إلى التحقق، ولكن هذه الحالات تختلف حسب التصميم، لذا فهي خارج نطاق مناقشتنا.
يجب أن يتم استدعاء هذه الدوال فقط من قبل PoolManager، ولا يمكن استدعاؤها من عناوين أخرى ### بما في ذلك EOA والعقود (. على سبيل المثال، في حالة توزيع المكافآت بواسطة مفتاح صندوق التمويل، إذا كان يمكن استدعاء الدالة المقابلة من أي حساب، فقد يتم استلام المكافآت بشكل خاطئ.
لذلك، من الضروري بالنسبة لـ hook إنشاء آلية تحكم وصول قوية، خاصةً لأنها يمكن أن تُستدعى من قبل أطراف أخرى غير المجموعة نفسها. من خلال إدارة صلاحيات الوصول بدقة، يمكن لمجمع السيولة أن يقلل بشكل كبير من المخاطر المرتبطة بالتفاعل غير المصرح به أو التفاعل الخبيث مع hook.
)# 2.1.2 مشكلة التحقق من الإدخال
في Uniswap v4، نظرًا لوجود آلية القفل، يجب على المستخدمين الحصول على قفل من العقد قبل إجراء أي عمليات على مجموعة السيولة. وهذا يضمن أن العقد الذي يشارك حاليًا في التفاعل هو عقد القفل الأحدث.
ومع ذلك، لا يزال هناك سيناريو هجوم محتمل، وهو استدعاءات خارجية غير موثوق بها نتيجة لعدم التحقق المناسب من المدخلات في بعض تنفيذات Hook المعرضة للهجوم:
أولاً، لم يتحقق hook من بركة الأموال التي ينوي المستخدم التفاعل معها. قد تكون هذه بركة أموال خبيثة تحتوي على رموز مزيفة وتنفذ منطق ضار.
ثانياً، بعض الدوال الرئيسية (hook) تسمح باستدعاءات خارجية عشوائية.
الاستدعاءات الخارجية غير الموثوقة خطيرة للغاية، لأنها قد تؤدي إلى أنواع مختلفة من الهجمات، بما في ذلك هجوم إعادة الدخول المعروف لدينا.
للهجوم على هذه الخطافات المعرضة للهجوم، يمكن للمهاجمين تسجيل تجمعات مالية خبيثة لرموزهم المزيفة، ثم استدعاء الخطاف لتنفيذ العمليات في التجمع المالي. أثناء التفاعل مع التجمع المالي، يقوم منطق الرمز الخبيث بالاستيلاء على تدفق التحكم للقيام بسلوكيات غير مرغوب فيها.
2.1.3 تدابير الحماية ضد نموذج التهديد I
لتجنب هذه المشاكل الأمنية المتعلقة بالـhook، من الضروري تنفيذ التحكم في الوصول الضروري إلى الوظائف الخارجية/العامة الحساسة والتحقق من معلمات الإدخال للتحقق من التفاعلات. بالإضافة إلى ذلك، قد يساعد حماية إعادة الإدخال في ضمان عدم تنفيذ الـhook بشكل متكرر في تدفق المنطق القياسي. من خلال تنفيذ تدابير الأمان المناسبة، يمكن لخزانات الأموال تقليل المخاطر المرتبطة بهذه التهديدات.
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ]###https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp(
) 2.2 قضايا الأمان في نموذج التهديد II
في هذا النموذج من التهديدات، نفترض أن المطورين وhooks الخاصة بهم خبيثة. نظرًا لأن النطاق المعني واسع جدًا، فإننا نركز فقط على القضايا الأمنية المتعلقة بالإصدار v4. لذلك، المفتاح هو ما إذا كانت hooks المقدمة قادرة على التعامل مع تحويلات المستخدم أو تفويض الأصول المشفرة.
نظرًا لأن طريقة الوصول إلى hook تحدد الأذونات التي قد تُمنح لـ hook، لذا نقسم hook إلى فئتين:
هوك المدارة ### Managed Hooks (: هوك ليست نقطة دخول. يجب على المستخدمين التفاعل مع الهوك من خلال جهاز التوجيه ) الذي قد توفره Uniswap (.
خطافات مستقلة ) Standalone Hooks (: hook هو نقطة دخول، يسمح للمستخدمين بالتفاعل مباشرة معها.
)# 2.2.1 هوك مدارة
في هذه الحالة، تشمل أصول المستخدم المشفرة ### الرموز الأصلية ورموز أخرى ( التي تم تحويلها أو تفويضها إلى router. نظرًا لأن PoolManager قد نفذ فحص الرصيد، فإنه من الصعب على الـ hook الخبيث سرقة هذه الأصول مباشرة. ومع ذلك، لا يزال هناك احتمالات لهجمات محتملة. على سبيل المثال، قد يتمكن المهاجمون من التلاعب بآلية إدارة الرسوم في الإصدار v4 من خلال الـ hook.
)# 2.2.2 نوع مستقل من Hook
عندما يتم استخدام الHook كنقطة دخول، تصبح الأمور أكثر تعقيدًا. في هذه الحالة، نظرًا لأن المستخدم يمكنه التفاعل مباشرة مع الHook، يحصل الHook على مزيد من السلطة. نظريًا، يمكن أن ينفذ الHook أي عملية يريدها من خلال هذا التفاعل.
في الإصدار v4، يعتبر التحقق من منطق الشفرة أمرًا بالغ الأهمية. تكمن المشكلة الرئيسية في إمكانية التلاعب بمنطق الشفرة. إذا كانت الدالة القابلة للتوصيل قابلة للتحديث، فهذا يعني أن دالة قابلة للتوصيل تبدو آمنة قد تصبح خبيثة بعد التحديث، مما يشكل خطرًا كبيرًا. تشمل هذه المخاطر:
يمكن مهاجمة الوكيل القابل للتحديث ### مباشرة (;
تحتوي على منطق تدمير ذاتي. يمكن أن تتعرض لهجوم في حالة الاستدعاء المشترك لـ selfdestruct و create2.
)# 2.2.3 تدابير الحماية ضد نموذج التهديد II
النقطة الأساسية هي تقييم ما إذا كان الـ hook ضارًا. بشكل أكثر تحديدًا، بالنسبة للـ hook المُدار، يجب أن نركز على سلوك إدارة الرسوم؛ بينما بالنسبة للـ hook المستقل، فإن النقطة الرئيسية هي ما إذا كانت قابلة للتحديث.
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
الاستنتاج
تقدم هذه المقالة أولاً لمحة موجزة عن الآليات الأساسية المتعلقة بمشكلات أمان Hook في Uniswap v4. بعد ذلك، نقترح نموذجين للتهديدات ونقدم لمحة موجزة عن المخاطر الأمنية ذات الصلة.
في المقالات التالية، سنقوم بتحليل متعمق للمسائل الأمنية تحت كل نموذج تهديد.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 17
أعجبني
17
5
مشاركة
تعليق
0/400
OfflineValidator
· 07-31 11:18
لا بد أن V4 قد فهمت الأمور جيدًا
شاهد النسخة الأصليةرد0
MetaMisery
· 07-30 04:35
لم يكن أفضل من v3 ، هل تريد فقط التلاعب بالمفاهيم مرة أخرى؟
شاهد النسخة الأصليةرد0
SatoshiNotNakamoto
· 07-30 04:24
انتظار ظهور الأخطاء في v4
شاهد النسخة الأصليةرد0
TokenGuru
· 07-30 04:17
نسخة مطورة من المشروع القديم، حمقى يتوافقون مع الفكرة مرة أخرى سيعانون
تحليل أمان آلية Hook في Uniswap v4: الابتكار والمخاطر تتواجد معًا
ثنائية آلية Hook في Uniswap v4: الابتكار والمخاطر المحتملة
من المقرر إطلاق Uniswap v4 قريبًا، وهذه الترقية تعتبر طموحة للغاية. ستقدم النسخة الجديدة العديد من الوظائف الجديدة، بما في ذلك دعم عدد غير محدود من أحواض السيولة لكل زوج تداول، والرسوم الديناميكية، وتصميم فردي، ومحاسبة فورية، وآلية Hook، بالإضافة إلى دعم معيار ERC1155 للرموز. باستخدام تقنية التخزين المؤقت، من المتوقع أن يتم إصدار Uniswap v4 بعد ترقية إيثريوم كانكون.
بين العديد من الابتكارات، تحظى آلية Hook باهتمام كبير بسبب إمكانياتها القوية. تتيح هذه الآلية تنفيذ كود مخصص في نقاط محددة من دورة حياة بركة السيولة، مما يعزز بشكل كبير قابلية التوسع والمرونة للبركة.
ومع ذلك، قد تكون آلية Hook سيفًا ذو حدين. على الرغم من أنها قوية ومرنة، فإن الاستخدام الآمن لـ Hook يواجه أيضًا تحديات كبيرة. لا مفر من أن تعقيد Hook يجلب معه نقاط هجوم محتملة جديدة. لذلك، من الضروري تقديم نظرة شاملة حول القضايا الأمنية والمخاطر المحتملة المرتبطة بآلية Hook، من أجل تعزيز التنمية الآمنة للمجتمع، وستساعد هذه الرؤى في بناء Hook أكثر أمانًا لـ Uniswap v4.
ستقدم هذه المقالة مفاهيم آلية Hook في Uniswap v4، وتستعرض المخاطر الأمنية الموجودة.
ميكانيكا Uniswap V4
قبل الخوض في التفاصيل، نحتاج إلى فهم الأساسيات حول آلية Uniswap v4. وفقًا للإعلان الرسمي والمستند الأبيض، فإن Hook، والهندسة المعمارية الأحادية، والمحاسبة الفورية هي الوظائف الثلاثة المهمة لتحقيق برك السيولة المخصصة وتوجيه فعال عبر برك متعددة.
1.1 هوك
Hook هو عقد يعمل في مراحل مختلفة من دورة حياة تجمع السيولة ، حيث يأمل فريق Uniswap من خلال إدخال Hook أن يتمكن أي شخص من اتخاذ قرارات موازنة. يمكن أن يتيح هذا الدعم الأصلي للرسوم الديناميكية ، وإضافة أوامر محددة السعر على السلسلة ، أو من خلال صانع السوق الموزع للطلبات الكبيرة باستخدام المتوسط المرجح بالوقت (TWAMM).
يوجد حاليًا ثمانية استدعاءات Hook، مقسمة إلى أربع مجموعات ( تحتوي كل مجموعة على زوج من الاستدعاءات ):
قدمت فريق Uniswap بعض الأمثلة ( مثل طريقة تشغيل TWAMM Hook )، كما قدم المشاركون في المجتمع بعض المساهمات. تربط الوثائق الرسمية أيضًا بمستودع Awesome Uniswap v4 Hooks، الذي يجمع المزيد من أمثلة Hook.
1.2 نمط وحيد، محاسبة البرق وآلية القفل
تهدف بنية السجل الفردي والتسجيل الفوري إلى تحسين الأداء من خلال خفض التكاليف وضمان الكفاءة. وقد قدمت عقد singleton جديد، حيث يتم الاحتفاظ بجميع برك السيولة في نفس العقد الذكي. يعتمد هذا التصميم الفردي على PoolManager لتخزين وإدارة حالة جميع البرك.
يقدم الإصدار Uniswap v4 آلية محاسبة فورية وآلية قفل. تعمل آلية القفل كما يلي:
يتطلب عقد locker قفلًا على PoolManager.
يقوم PoolManager بإضافة عنوان عقد locker إلى قائمة lockData، ثم يستدعي رد الاتصال lockAcquired.
يتم تنفيذ منطق عقد locker في رد النداء. قد تؤدي التفاعلات بين عقد locker والمسبح خلال عملية التنفيذ إلى زيادة غير صفرية في العملات. ولكن عند انتهاء التنفيذ، يجب تسوية جميع الزيادات لتكون صفرًا. بالإضافة إلى ذلك، إذا كانت قائمة lockData غير فارغة، يمكن فقط لعقد locker الأخير تنفيذ العمليات.
يقوم PoolManager بفحص حالة قائمة lockData وحالة الزيادة في العملة. بعد التحقق، سيقوم PoolManager بحذف عقدة الlocker.
بشكل عام، تمنع آلية القفل الوصول المتزامن وتضمن تسوية جميع المعاملات. يتقدم عقد القفل للحصول على القفل بالترتيب، ثم يتم تنفيذ المعاملات من خلال رد الاتصال lockAcquired. قبل وبعد كل عملية في المسبح، سيتم استدعاء رد الاتصال المقابل. أخيرًا، سيتحقق PoolManager من الحالة.
تعني هذه الطريقة أن التعديلات التشغيلية تتعلق بالرصيد الصافي الداخلي ( أي دلتا )، وليس تنفيذ التحويل الفوري. سيتم تسجيل أي تعديلات في الرصيد الداخلي للمجمع، بينما يتم إجراء التحويل الفعلي عند انتهاء العملية ( أي قفل ). تضمن هذه العملية عدم وجود رموز غير مسددة، مما يحافظ على سلامة الأموال.
نظرًا لوجود آلية القفل، لا يمكن لجميع الحسابات الخارجية (EOA) التفاعل مباشرة مع PoolManager. بدلاً من ذلك، يجب أن تتم أي تفاعلات من خلال العقد. يعمل هذا العقد كخزانة وسيطة، ويجب طلب القفل قبل إجراء أي عمليات على المسبح.
يوجد نوعان رئيسيان من سيناريوهات التفاعل مع العقود:
عقد locker يأتي من مكتبة التعليمات البرمجية الرسمية، أو يتم نشره بواسطة المستخدم. يمكن اعتبار هذه الحالة تفاعل عبر جهاز التوجيه.
يتم دمج عقد locker وعقد Hook في نفس العقد، أو يتم التحكم فيه بواسطة كيان ثالث. يمكن اعتبار هذه الحالة تفاعلًا عبر Hook. في هذه الحالة، يلعب Hook دور عقد locker ويكون مسؤولاً أيضًا عن معالجة الاستدعاءات.
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-f652bf2a22ca7f28f19b4ce9880d0548.webp)
نموذج التهديد
قبل مناقشة المسائل الأمنية ذات الصلة، نحتاج إلى تحديد نموذج التهديد. يجب أن نأخذ في الاعتبار حالتين رئيسيتين:
نموذج التهديد I: هوك نفسه غير ضار، لكنه يحتوي على ثغرات.
نموذج التهديد II: هوك نفسه خبيث.
بعد ذلك، سيتم مناقشة القضايا الأمنية المحتملة بناءً على هذين النموذجين للتهديد.
2.1 مشاكل الأمان في نموذج التهديد I
نموذج التهديد I يركز على الثغرات المتعلقة بـ Hook نفسه. يفترض هذا النموذج أن المطورين و Hook الخاص بهم غير ضارين. ومع ذلك، قد تظهر الثغرات المعروفة الموجودة في العقود الذكية أيضًا في Hook. على سبيل المثال، إذا تم تنفيذ Hook كعقد قابل للتحديث، فقد يواجه مشكلات مشابهة لتلك المتعلقة بثغرة UUPSUpgradeable من OpenZeppelin.
نظرًا للعوامل المذكورة أعلاه، اخترنا التركيز على الثغرات المحتملة الخاصة بإصدار v4. في Uniswap v4، يعتبر Hook عقدًا ذكيًا قادرًا على تنفيذ منطق مخصص قبل أو بعد العمليات الأساسية في المسبح، بما في ذلك التهيئة، تعديل المواقع، التبادل وجمع (. على الرغم من أنه من المتوقع أن يحقق Hook واجهة معيارية، إلا أنه يسمح أيضًا بتضمين منطق مخصص. لذلك، ستقتصر مناقشتنا على المنطق المتعلق بواجهة Hook القياسية. ثم، سنحاول تحديد مصادر الثغرات المحتملة، مثل كيفية استغلال Hook لهذه الوظائف القياسية.
بشكل محدد، سنركز على نوعين من الـ Hook:
النوع الأول من الـhook، حفظ أموال المستخدمين. في هذه الحالة، قد يقوم المهاجم باستهداف هذا الـhook لنقل الأموال، مما يتسبب في خسارة الأصول.
النوع الثاني من الـ hook، تخزين بيانات الحالة الأساسية التي تعتمد عليها المستخدمين أو بروتوكولات أخرى. في هذه الحالة، قد يحاول المهاجم تغيير الحالة الأساسية. عندما يستخدم مستخدمون أو بروتوكولات أخرى حالة خاطئة، قد يؤدي ذلك إلى مخاطر محتملة.
يرجى ملاحظة أن الخطاطيف خارج هذين النطاقين ليست ضمن نطاق مناقشتنا.
بعد البحث المتعمق في مستودع Awesome Uniswap v4 Hooks، اكتشفنا عدة ثغرات خطيرة. تنبع هذه الثغرات بشكل أساسي من التفاعلات المائية بين hook و PoolManager و الأطراف الخارجية، ويمكن تقسيمها بشكل رئيسي إلى فئتين: مشاكل التحكم في الوصول ومشاكل التحقق من المدخلات.
بشكل عام، وجدنا 22 مشروعًا ذا صلة ) باستثناء المشاريع غير المتعلقة بـ Uniswap v4 (. من بين هذه المشاريع، نعتقد أن هناك 8 مشاريع )36% ( بها ثغرات. من بين هذه المشاريع الثمانية التي بها ثغرات، يوجد 6 بها مشاكل في التحكم بالوصول، و2 عرضة لاستدعاءات خارجية غير موثوقة.
)# 2.1.1 مشكلة التحكم في الوصول
في هذا الجزء من المناقشة، نركز بشكل أساسي على المشكلات التي قد تسببها دوال الاستدعاء في v4، بما في ذلك 8 دوال استدعاء (hook) واستدعاء (lock). بالطبع، هناك حالات أخرى تحتاج إلى التحقق، ولكن هذه الحالات تختلف حسب التصميم، لذا فهي خارج نطاق مناقشتنا.
يجب أن يتم استدعاء هذه الدوال فقط من قبل PoolManager، ولا يمكن استدعاؤها من عناوين أخرى ### بما في ذلك EOA والعقود (. على سبيل المثال، في حالة توزيع المكافآت بواسطة مفتاح صندوق التمويل، إذا كان يمكن استدعاء الدالة المقابلة من أي حساب، فقد يتم استلام المكافآت بشكل خاطئ.
لذلك، من الضروري بالنسبة لـ hook إنشاء آلية تحكم وصول قوية، خاصةً لأنها يمكن أن تُستدعى من قبل أطراف أخرى غير المجموعة نفسها. من خلال إدارة صلاحيات الوصول بدقة، يمكن لمجمع السيولة أن يقلل بشكل كبير من المخاطر المرتبطة بالتفاعل غير المصرح به أو التفاعل الخبيث مع hook.
)# 2.1.2 مشكلة التحقق من الإدخال
في Uniswap v4، نظرًا لوجود آلية القفل، يجب على المستخدمين الحصول على قفل من العقد قبل إجراء أي عمليات على مجموعة السيولة. وهذا يضمن أن العقد الذي يشارك حاليًا في التفاعل هو عقد القفل الأحدث.
ومع ذلك، لا يزال هناك سيناريو هجوم محتمل، وهو استدعاءات خارجية غير موثوق بها نتيجة لعدم التحقق المناسب من المدخلات في بعض تنفيذات Hook المعرضة للهجوم:
أولاً، لم يتحقق hook من بركة الأموال التي ينوي المستخدم التفاعل معها. قد تكون هذه بركة أموال خبيثة تحتوي على رموز مزيفة وتنفذ منطق ضار.
ثانياً، بعض الدوال الرئيسية (hook) تسمح باستدعاءات خارجية عشوائية.
الاستدعاءات الخارجية غير الموثوقة خطيرة للغاية، لأنها قد تؤدي إلى أنواع مختلفة من الهجمات، بما في ذلك هجوم إعادة الدخول المعروف لدينا.
للهجوم على هذه الخطافات المعرضة للهجوم، يمكن للمهاجمين تسجيل تجمعات مالية خبيثة لرموزهم المزيفة، ثم استدعاء الخطاف لتنفيذ العمليات في التجمع المالي. أثناء التفاعل مع التجمع المالي، يقوم منطق الرمز الخبيث بالاستيلاء على تدفق التحكم للقيام بسلوكيات غير مرغوب فيها.
2.1.3 تدابير الحماية ضد نموذج التهديد I
لتجنب هذه المشاكل الأمنية المتعلقة بالـhook، من الضروري تنفيذ التحكم في الوصول الضروري إلى الوظائف الخارجية/العامة الحساسة والتحقق من معلمات الإدخال للتحقق من التفاعلات. بالإضافة إلى ذلك، قد يساعد حماية إعادة الإدخال في ضمان عدم تنفيذ الـhook بشكل متكرر في تدفق المنطق القياسي. من خلال تنفيذ تدابير الأمان المناسبة، يمكن لخزانات الأموال تقليل المخاطر المرتبطة بهذه التهديدات.
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ]###https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp(
) 2.2 قضايا الأمان في نموذج التهديد II
في هذا النموذج من التهديدات، نفترض أن المطورين وhooks الخاصة بهم خبيثة. نظرًا لأن النطاق المعني واسع جدًا، فإننا نركز فقط على القضايا الأمنية المتعلقة بالإصدار v4. لذلك، المفتاح هو ما إذا كانت hooks المقدمة قادرة على التعامل مع تحويلات المستخدم أو تفويض الأصول المشفرة.
نظرًا لأن طريقة الوصول إلى hook تحدد الأذونات التي قد تُمنح لـ hook، لذا نقسم hook إلى فئتين:
هوك المدارة ### Managed Hooks (: هوك ليست نقطة دخول. يجب على المستخدمين التفاعل مع الهوك من خلال جهاز التوجيه ) الذي قد توفره Uniswap (.
خطافات مستقلة ) Standalone Hooks (: hook هو نقطة دخول، يسمح للمستخدمين بالتفاعل مباشرة معها.
)# 2.2.1 هوك مدارة
في هذه الحالة، تشمل أصول المستخدم المشفرة ### الرموز الأصلية ورموز أخرى ( التي تم تحويلها أو تفويضها إلى router. نظرًا لأن PoolManager قد نفذ فحص الرصيد، فإنه من الصعب على الـ hook الخبيث سرقة هذه الأصول مباشرة. ومع ذلك، لا يزال هناك احتمالات لهجمات محتملة. على سبيل المثال، قد يتمكن المهاجمون من التلاعب بآلية إدارة الرسوم في الإصدار v4 من خلال الـ hook.
)# 2.2.2 نوع مستقل من Hook
عندما يتم استخدام الHook كنقطة دخول، تصبح الأمور أكثر تعقيدًا. في هذه الحالة، نظرًا لأن المستخدم يمكنه التفاعل مباشرة مع الHook، يحصل الHook على مزيد من السلطة. نظريًا، يمكن أن ينفذ الHook أي عملية يريدها من خلال هذا التفاعل.
في الإصدار v4، يعتبر التحقق من منطق الشفرة أمرًا بالغ الأهمية. تكمن المشكلة الرئيسية في إمكانية التلاعب بمنطق الشفرة. إذا كانت الدالة القابلة للتوصيل قابلة للتحديث، فهذا يعني أن دالة قابلة للتوصيل تبدو آمنة قد تصبح خبيثة بعد التحديث، مما يشكل خطرًا كبيرًا. تشمل هذه المخاطر:
يمكن مهاجمة الوكيل القابل للتحديث ### مباشرة (;
تحتوي على منطق تدمير ذاتي. يمكن أن تتعرض لهجوم في حالة الاستدعاء المشترك لـ selfdestruct و create2.
)# 2.2.3 تدابير الحماية ضد نموذج التهديد II
النقطة الأساسية هي تقييم ما إذا كان الـ hook ضارًا. بشكل أكثر تحديدًا، بالنسبة للـ hook المُدار، يجب أن نركز على سلوك إدارة الرسوم؛ بينما بالنسبة للـ hook المستقل، فإن النقطة الرئيسية هي ما إذا كانت قابلة للتحديث.
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
الاستنتاج
تقدم هذه المقالة أولاً لمحة موجزة عن الآليات الأساسية المتعلقة بمشكلات أمان Hook في Uniswap v4. بعد ذلك، نقترح نموذجين للتهديدات ونقدم لمحة موجزة عن المخاطر الأمنية ذات الصلة.
في المقالات التالية، سنقوم بتحليل متعمق للمسائل الأمنية تحت كل نموذج تهديد.