Один із клієнтів консенсусу Ethereum злив виправлення для атаки отруєння кешу публічних ключів валідаторів, згідно з pull request на GitHub. Патч усуває вразливість навколо форку Gloas, яка могла призвести до того, що деякі вузли відхиляли дійсні підписи через помилку в глобальному кеші публічних ключів.
Gloas — це частина рівня консенсусу майбутнього оновлення Glamsterdam.
Три депозити, два ланцюги
Проблема полягає в механізмі, де клієнт зберігає публічні ключі валідаторів та їхні індекси в глобальному кеші.
Технічно депозити, які вже фіналізовані, мають давати однакових валідаторів на кожному ланцюзі, хоча на межі форку ситуація інша.
Атакувальнику потрібні 3 незавершені депозити безпосередньо перед форком. Перший — це велике поповнення для існуючого валідатора. Інші два — це нові ключі: A з обліковими даними будівельника та B зі звичайними обліковими даними валідатора.
На канонічному ланцюзі поповнення споживає обіг балансу, тому A і B обробляються після форку. A стає будівельником, а B отримує наступний індекс валідатора.
На бічному ланцюзі атакувальника поповнений валідатор зазнає слешингу перед форком, і його депозит пропускається. Це призводить до того, що A обробляється раніше, по суті займаючи індекс B.
Помилковий кеш припускав, що обидва ланцюги створять однакових валідаторів, і глобально імпортував ключ A.
На форку уражені вузли відхиляли б усі дійсні підписи від B на канонічному ланцюзі та відгалужувалися б.
Реалістично атака є дещо складною, оскільки потребує слешингу в потрібний момент і бічного ланцюга, тому малоймовірно, що вона станеться випадково.
Що змінює виправлення?
Згідно з PR, виправлення полягає в тому, щоб додавати ключі до глобального кешу публічних ключів лише після фіналізації епохи їхньої придатності до активації.
Нова структура HeadPubkeys також об'єднує ключі зі стану голови та глобального кешу, щоб вузли не пропускали ключі, якщо ланцюг фіналізується без нових блоків.
Чи мали інші клієнти консенсусу подібну проблему, ще належить підтвердити. Іншими словами, чим ближче Glamsterdam, тим більше граничних випадків навколо межі форку доводиться виявляти розробникам.
