Один из консенсус-клиентов Ethereum объединил исправление для атаки отравления кэша публичных ключей валидаторов, согласно пул-реквесту на GitHub. Патч устраняет уязвимость, связанную с форком Gloas, которая могла привести к тому, что некоторые узлы отклоняли бы действительные подписи из-за ошибки в глобальном кэше публичных ключей.
Gloas — это часть уровня консенсуса предстоящего обновления Glamsterdam.
Три депозита, две цепочки
Проблема заключается в механизме, при котором клиент хранит публичные ключи валидаторов и их индексы в глобальном кэше.
Технически депозиты, которые уже финализированы, должны давать одних и тех же валидаторов в каждой цепочке, хотя на границе форка ситуация иная.
Атакующему нужно 3 ожидающих депозита непосредственно перед форком. Первый — это крупное пополнение для существующего валидатора. Другие два — это новые ключи: A с учётными данными билдера и B с обычными учётными данными валидатора.
В канонической цепочке пополнение расходует балансовый оборот, поэтому A и B обрабатываются после форка. A становится билдером, а B получает следующий индекс валидатора.
В боковой цепочке атакующего пополненный валидатор подвергается слэшингу до форка, и его депозит пропускается. Это приводит к тому, что A обрабатывается раньше, по сути занимая индекс B.
Ошибочный кэш предполагал, что обе цепочки создадут одних и тех же валидаторов, и глобально импортировал ключ A.
На форке затронутые узлы отклоняли бы все действительные подписи от B в канонической цепочке и отделялись бы в форк.
В реальности атака довольно сложна, поскольку требует слэшинга в нужный момент и боковой цепочки, поэтому вряд ли произойдёт случайно.
Что меняет исправление?
Согласно PR, исправление заключается в том, чтобы добавлять ключи в глобальный кэш публичных ключей только после того, как финализируется эпоха их права на активацию.
Новая структура HeadPubkeys также объединяет ключи из состояния головы и глобального кэша, чтобы узлы не пропускали ключи, если цепочка финализируется без новых блоков.
Предстоит подтвердить, была ли аналогичная проблема у других консенсус-клиентов. Иными словами, чем ближе Glamsterdam, тем больше краевых случаев вокруг границы форка приходится отлавливать разработчикам.
