Недавно обнаруженная уязвимость, связанная с неподтвержденными каналами, могла привести к многократным сбоям Eclair, реализации Bitcoin Lightning, без необходимости злоумышленнику тратить BTC в основной сети. Уязвимость затронула доступные узлы, работающие под управлением версий v0.14.0 и более ранних, при этом сохраненные записи о каналах делали перезапуск недостаточным для восстановления работоспособности.
Исследователь Эрик Честари опубликовал информацию об уязвимости, вызывающей постоянные сбои, 30 сентября и объяснил ее вместе с отдельным багом типа «отказ в обслуживании» в сообщении для разработчиков от 1 октября. Оба бага были исправлены в версии v0.14.1, выпущенной в июле, до публичного раскрытия. ACINQ теперь рекомендует более поздний выпуск безопасности v0.14.3 для устранения других уязвимостей.
Почему перезапуск мог не помочь
Eclair ограничивал количество ожидающих каналов, которые мог открыть узел-партнер, но несогласованные проверки временных и окончательных идентификаторов каналов позволяли счетчику недоучитывать неподтвержденные каналы. Вредоносный узел-партнер мог накапливать сохраненные запросы, не транслируя транзакцию финансирования и не оплачивая комиссию в основной сети.
Это различие имеет значение: BTC, обычно необходимый для финансирования канала, не требовалось блокировать, чтобы уязвимый узел понес затраты на память и базу данных. Атака все же требовала вычислительных ресурсов и сетевого трафика.
В демонстрации Честари Eclair v0.14.0 работал в режиме regtest, локальной тестовой среде Bitcoin. Он сообщил, что узел исчерпал 4 ГБ памяти виртуальной машины Java примерно за 47 минут 43 секунды, накопив 217 623 строки в базе данных каналов. Это лабораторный тест, а не универсальное время атаки.
Первоначальный сбой оставил эти записи на диске. При запуске Eclair перезагружал каналы и снова исчерпывал память. Честари описал увеличение объема памяти или ручное удаление фальшивых записей о каналах как меры восстановления. Многократные перезапуски не устраняли основную нагрузку.
Демонстрация касается доступности одного уязвимого узла. Она не подтверждает реальную эксплуатацию или количество необновленных узлов.
ACINQ объединил PR #3324 17 июля. Патч усилил проверки на дублирование каналов, а v0.14.1 вышел 29 июля. По данным Эрика Честари / Delving Bitcoin, уязвимы версии v0.14.0 и более ранние, тогда как v0.14.1 и более поздние устраняют эти два типа отказа в обслуживании.
Второй баг, раскрытый Мэттом Морхаусом / lnfuzz под названием LNF-2026-0003, представлял собой гонку при открытии канала, которая оставляла «осиротевшие» процессы каналов, потребляющие память или процессорное время. В его консультативном заключении указано, что протестированный узел восстанавливался после отключения или перезапуска без потерь. Этот результат восстановления относится к багу гонки, а не к постоянной перегрузке базы данных.
Эти находки также отличаются от уязвимостей, связанных с потерей средств, о которых CryptoSlate писал 21 сентября и которые были исправлены в v0.14.3. Поэтому июльское минимальное исправление не следует рассматривать как полную текущую рекомендацию по безопасности.
ACINQ рекомендует обновиться до версии v0.14.3, выпущенной 14 сентября, поскольку злонамеренные узлы могли использовать некоторые из исправленных ею проблем. Предотвращение новых перегрузок неподтвержденными каналами и восстановление уже перегруженной базы данных — это отдельные задачи для операторов.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Liam 'Akiba' Wright
