Ethereum client security fixes leave binary users with a separate Java check
Кратко
- Версии Teku 26.10.3 и Besu 26.10.2 удаляют четыре корневых сертификата из образов Docker в связи с инцидентом, произошедшим в компании eMudhra.
- Установки бинарных версий зависят от отдельно управляемой Java, которую операторам необходимо проверить и исправить, если она все еще подвержена влиянию.
- Teku сообщает об отсутствии случаев эксплуатации; основные узлы по умолчанию, не использующие HTTPS-URL, не затронуты этой проблемой с сертификатами.
Teku и Besu, программное обеспечение, используемое для работы узлов Ethereum, выпустили обновления безопасности для образов Docker после компрометации центра сертификации в компании eMudhra. Операторы, использующие затронутые образы, могут обновить эти контейнеры. Для установок бинарных версий требуется отдельная проверка Java-среды выполнения.
Teku 26.10.3, выпущенная 27 октября, и Besu 26.10.2, выпущенная 26 октября, прекращают использование четырех корневых сертификатов в своих образах Docker: emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 и AAA Certificate Services.
Для Teku степень подверженности зависит от конфигурации. В сообщении о безопасности команда сообщает, что основные узлы по умолчанию, не использующие HTTPS-URL, не затронуты этой проблемой. В случае использования необновленной среды выполнения, злоумышленнику потребуется перехватить затронутое HTTPS-соединение, чтобы выдать себя за конечную точку. В сообщении также говорится об отсутствии случаев эксплуатации.
Основной причиной инцидента стали уязвимые закрытые ключи для восьми промежуточных центров сертификации emSign G3. Компания eMudhra признала наличие ошибки в скрипте, которая привела к созданию слабых ключей, и заявила, что промежуточные сертификаты были отозваны после сообщения, опубликованного 17 октября. В уведомлении Teku говорится, что Java по умолчанию не проверяет отзыв сертификатов, поэтому затронутые среды выполнения все равно нуждаются в отдельной корректировке.
Что необходимо проверить операторам
Новые образы клиентов устраняют проблему, связанную со встроенными хранилищами доверия, списками центров сертификации, которые Java принимает. В уведомлении Teku указаны все образы Docker до версии 26.10.2, включая варианты -jdk25 и -jdk26, которые содержат указанный корневой сертификат emSign ECC. Обновление Java на хосте не изменяет среду выполнения внутри этих контейнеров.
Besu явно ограничивает изменение, связанное с удалением корневых сертификатов, только образами Docker: пользователи, использующие tar/zip-архивы, могут по-прежнему использовать JDK, который доверяет этим корневым сертификатам. Бинарная дистрибуция Teku также использует Java-среду выполнения, установленную оператором. Для этих установок необходимо проверить эту среду выполнения и, если она все еще подвержена влиянию, исправить ее отдельно от программного обеспечения клиента.
Зависимости Teku от HTTPS могут включать удаленные подписывающие сервисы, узлы консенсуса, клиенты выполнения и строители или ретрансляторы, а также конфигурацию предлагающих, данные для запуска и сервисы мониторинга. В уведомлении также упоминаются Sepolia, Hoodi и Ephemery, которые загружают начальное состояние через HTTPS при запуске с пустой базой данных.
В случае использования системы без соответствующих мер безопасности, злоумышленник, перехватывающий соединение, может выдать себя за удаленный узел-маяк. Это может привести к перенаправлению комиссий за предложения или к невыполнению валидаторами своих обязанностей. Злоумышленник, выдающий себя за внешний узел, имеющий доступ к подписи, может получить подписи, необходимые для выхода валидатора из системы. В уведомлении говорится, что взаимная аутентификация клиентов с использованием TLS ограничивает влияние этой проблемы только отказом в обслуживании.
Система одноранговой сети Teku, включая libp2p и discv5, не использует центры сертификации и, следовательно, не подвержена этой проблеме.
Контекст статьи.
