НовостиКриптовалютыКлиенты Ethereum Teku и Besu устранили уязвимости, подвергавшие риску вознаграждения валидаторов

Клиенты Ethereum Teku и Besu устранили уязвимости, подвергавшие риску вознаграждения валидаторов

Автор: Coincentral·

Ключевые выводы

  • •Teku выпустил версию 26.10.3 27 октября, а Besu выпустил версию 26.10.2 26 октября; оба обновления удаляют затронутые центры сертификации eMudhra из Docker-образов, используемых для запуска узлов Ethereum.
  • •Слабость сертификатов возникла потому, что восемь промежуточных сертификатов eMudhra опирались на закрытые ключи, которые злоумышленники могли вычислить из общедоступной информации, а отсутствие в Java проверки отзыва сертификатов по умолчанию оставляло клиенты на Java уязвимыми даже после отзыва.
  • •Teku предупредил, что подделанное соединение с удаленным узлом или внешним сервисом подписания могло перенаправить комиссии и вознаграждения за блоки, однако узел mainnet с настройками по умолчанию не требовал действий, а случаев эксплуатации зафиксировано не было.
  • •Ошибка маршрутизации депозитов в черновых правилах Glamsterdam, выявленная исследователем avsetsin, могла привести к зачислению депозитов стейкинга на счет билдера, если билдер и валидатор использовали один публичный ключ; пересмотренные правила сортируют ожидающие депозиты по кредитным полномочиям на вывод и были объединены 26 октября после первоначального отклонения командами клиентов.
  • •Операторам, запускающим Teku или Besu вне Docker, необходимо отдельно обновить Java, причем Teku посоветовал пользователям неподдерживаемой Java 26 перейти на Java 25, а обновление тестовой сети Hoodi отложено до новой даты активации.
Клиенты Ethereum Teku и Besu устранили уязвимости, подвергавшие риску вознаграждения валидаторов

Разработчики Ethereum устранили две отдельные уязвимости, которые могли подвергнуть риску депозиты валидаторов и вознаграждения за блоки: одна была связана с ненадежными сертификатами веб-сайтов, а другая была заложена в черновых правилах предстоящего обновления сети Glamsterdam. Консенсус-клиент Teku и клиент исполнения Besu выпустили патчи для устранения этой уязвимости. Узлы Ethereum работают одновременно с консенсус-клиентом и клиентом исполнения, поэтому оба уровня стека узла требовали одинаковой очистки сертификатов.

Teku выпустил версию 26.10.3 27 октября, на день после того, как Besu выпустил версию 26.10.2 26 октября. Оба релиза удаляют затронутые центры сертификации из Docker-образов, используемых для запуска узлов Ethereum, согласно странице релизов Teku.

Выявлены ненадежные сертификатные ключи

Исследователи обнаружили 17 октября, что восемь промежуточных сертификатов, выпущенных индийской компанией eMudhra, опирались на закрытые ключи, которые злоумышленники могли вычислить из общедоступной информации. Обладая этими ключами, злоумышленники могли выпускать сертификаты для поддельных сервисов. eMudhra отозвала сертификаты, но некоторые установки Java продолжали им доверять, поскольку Java по умолчанию не проверяет отзыв сертификатов. И Teku, и Besu написаны на Java, — именно так эта слабость затронула работу узлов Ethereum.

Это открытие произошло на той же неделе, когда Google представила систему безопасности криптокастодиального хранения, предназначенную для распределения закрытых ключей между отдельными средами.

Как могли быть перенаправлены комиссии валидаторов

Уязвимость сертификатов имела значение, поскольку валидаторы зависят от соединений с внешними сервисами. Злоумышленник, способный перехватить такое соединение, мог выдать себя за сервис на другом конце. Teku предупредил, что подделанное соединение с удаленным узлом могло привести к тому, что комиссии за блоки будут выплачены на адрес, контролируемый злоумышленником. В затронутых конфигурациях дополнительным риском были внешние сервисы подписания, поскольку злоумышленники могли получить подписи, перенаправляющие вознаграждения.

«Узел Teku по умолчанию в mainnet не затронут и не требует никаких действий», — сообщил Teku. Команда клиента не выявила случаев эксплуатации.

Исправлены правила депозитов Glamsterdam

В рамках отдельной работы разработчики пересмотрели предложенные правила Glamsterdam после того, как исследователь avsetsin выявил ошибку маршрутизации депозитов. Они также отложили обновление тестовой сети Hoodi, которое было запланировано на 26 октября.

Согласно более раннему черновику, билдер и валидатор с одним общим публичным ключом могли привести к тому, что депозиты стейкинга попадут на счет билдера. Glamsterdam призван разделить конструирование блоков и валидацию, а пересмотренное предложение сортирует ожидающие депозиты по кредитным полномочиям на вывод (withdrawal credentials), отличая депозиты валидаторов от депозитов билдеров.

Команды клиентов изначально отклонили исправление 19 октября из-за отсутствия согласия. Впоследствии разработчики добавили тесты и объединили исправленные правила 26 октября.

Разные дальнейшие шаги для операторов узлов

Исправление Glamsterdam внесено в спецификации Ethereum, однако командам разработчиков ПО еще предстоит его реализовать. Glamsterdam ранее был запущен в тестовой сети Sepolia, а Hoodi ожидает новой даты активации.

Операторам, запускающим Teku или Besu вне Docker, необходимо отдельно обновить Java. Риск, связанный с сертификатами, охватывал выплаты из комиссии за газ Ethereum, такие как приоритетные комиссии, выплачиваемые валидаторам, а не обычные балансы кошельков пользователей. Teku посоветовал пользователям неподдерживаемой Java 26 перейти на Java 25.

Патчи сертификатов устраняют проблему в затронутых Docker-образах, в то время как исправление Glamsterdam ожидает принятия во всей экосистеме клиентов Ethereum.