حادثه سپولیا | وبلاگ بنیاد اتریوم

این پست وبلاگ تهدیدی را علیه شبکه اتریوم که از زمان ادغام تا هارد فورک Dencun وجود داشت، افشا می کند.

پس زمینه

قبل از ادغام، محدودیت‌های مختلف اندازه پیام برای ارتباطات RPC برای محافظت از مشتریان در برابر حملات انکار سرویس (DOS) تنظیم شده بود. این محدودیت‌ها که برای پیام‌های دریافتی از طریق نقاط پایانی HTTP اعمال می‌شوند، به API موتور منتقل می‌شوند، که نقش مهمی در اتصال کلاینت‌های Execution و Consensus Layer در طول تولید بلوک بازی می‌کند. با توجه به دخالت موتور API در تولید بلوک، امکان تولید بلوک‌هایی فراهم شد که از محدودیت‌های اندازه RPC برخی مشتریان فراتر می‌رفت اما در محدوده قابل قبول برای برخی دیگر باقی می‌ماند.

اگر یک مهاجم پیامی ایجاد کند که از محدودیت اندازه مشتری با کمترین تنظیمات بیشتر باشد، در حالی که همچنان به الزامات محدودیت گاز پایبند است، و سپس منتظر بماند تا یک بلوک تولید شود، می تواند منجر به وضعیتی شود که برخی از مشتریان به بلوک توجه کنند. معتبر است، در حالی که دیگران آن را رد می کنند، کد خطای HTTP “413: محتوای خیلی بزرگ” را صادر می کنند.

تاثیر

مهاجمی که بتواند این پیام‌ها را ایجاد کند، می‌تواند اکثر گره‌ها (=geth) را مجبور به رد بلوک‌هایی کند که یک اقلیت می‌پذیرند. این بلوک ها از بین می روند و پیشنهاد دهنده جوایز را از دست می دهد.

در ابتدا فکر می‌کردیم که ایجاد این بلوک‌ها تنها با استفاده از سازنده‌ها یا یک نسخه تغییر یافته از یک کلاینت امکان‌پذیر است. Geth دارای محدودیت داخلی 128 کیلوبایت برای تراکنش‌ها است، به این معنی که تراکنش بزرگی مانند آنچه مورد بحث است در استخر تراکنش‌های هیچ گره دریافتی قرار نمی‌گیرد. با این حال، همچنان می‌توان با داشتن یک کلاینت با محدودیت بالاتر بلوک را پیشنهاد کرد و CL درخواست اعتبار برای این بلوک بزرگ‌تر پیشنهادی کرد.

ما راه حلی را برای کاهش موقت محدودیت RPC در همه مشتریان به کمترین مقدار (5 مگابایت) پیشنهاد کردیم. این باعث می شود بلوک نامعتبر باشد و مهاجم در هرج و مرجی که می تواند در شبکه ایجاد کند بسیار محدود می شود زیرا اکثر گره ها بلوک های خود را رد می کنند.

با این حال، در 7 فوریه متوجه شدیم که می‌توان بلوکی را ایجاد کرد که به سقف 5 مگابایت برسد با تعداد زیادی تراکنش که زیر سقف 128 کیلوبایت هستند و از 30 میلیون گاز تجاوز نمی‌کنند.

این یک مسئله بزرگتر است زیرا متوجه شدیم که یک مهاجم می تواند یک دسته از تراکنش های پردرآمد ایجاد کند و آنها را به شبکه بفرستد. از آنجایی که او از همه افراد دیگر در ممپول پیشی می گیرد، هر گره (حتی گره های دریافتی) تراکنش های حمله را در بلوک خود شامل می شود، بنابراین بلوکی ایجاد می کند که توسط اکثریت شبکه پذیرفته نمی شود و در نتیجه فورک های زیادی ایجاد می شود (همه به نظر می رسد معتبر توسط گره های اقلیت) و زنجیره مرتباً مرتب می شود.

بعداً در 7 فوریه، به این نتیجه رسیدیم که هرکسی محدودیت‌های RPC خود را افزایش دهد، جایگزین امن‌تری خواهد بود.

جدول زمانی

• 06-02-2024 13:00: تونی (EF)، پری (EF) و جاستین (بسو) سعی می کنند یک تراکنش خاص به شبکه ارسال کنند. این تراکنش در صورت فشرده شدن سریع به بلوک های 2.7 مگابایتی کمک می کند.
• 06-02-2024 13:25: Pari خطاهایی را از گره Geth محلی خود دریافت می کند، اگرچه تراکنش باید معتبر باشد.
• 2024-02-06 15:14: جاستین موفق شد تراکنش را در یک بلوک قرار داده و آن را از طریق مشتری Besu ارسال کند.
• 06-02-2024 20:46: سام (EF) به پری هشدار داد (با تشکر ویژه از mysticryuujin در X)، تونی و الکس در مورد گره های Sepolia در حال مبارزه هستند.
• 06-02-2024 21:05: تیم با ماریوس از Geth چک می کند و اشکال را تأیید می کند.
• 2024-02-06 21:10: باند دور هم جمع می شوند تا آن را رفع اشکال کنند.
• 2024-02-07 23:40: ما تصمیم گرفتیم همه مشتریان محدودیت درخواست RPC خود را به 5 مگابایت محدود کنند.
• 2024-02-07 6:40: ما متوجه شدیم که ممکن است مشکل بزرگتری وجود داشته باشد و حمله را می توان با تراکنش هایی با اندازه کمتر از 128 کیلوبایت اجرا کرد.
• 2024-02-07 10:00: ما تصمیم گرفتیم که همه مشتریان محدودیت درخواست RPC را افزایش دهند.
• 2024-02-07 21:00: رفع مشکل در geth ادغام شد.
• 09-02-2024: گث آزاد شد

در حالی که Geth تنها مشتری تحت تأثیر این اشکال بود، سایر مشتریان نیز پیش فرض های خود را به روز کرده اند تا از این حمله ایمن باشند حتی اگر محدودیت های گاز افزایش یابد. تیم‌های مشتری نشان دادند که به‌روزرسانی‌های زیر دارای محدودیت‌های امن rpc هستند:

Geth: نسخه 1.13.12

Nethermind: نسخه 1.25.4

عنوان: 24.1.2

اریگون: نسخه 2.58.0

Reth: v0.1.0-alpha.18