Bitcoin Core empieza a pagar el costo de adaptarse a la IA con su nueva política
Недавняя ошибка, которая уже была исправлена, позволяла удаленно отключать узлы, не использующие Linux.
Даже после обновления некоторые узлы остаются уязвимыми из-за ограничений их аппаратного обеспечения.
Команда Bitcoin Core, программное обеспечение, которое работает на большинстве узлов сети, неделю назад изменила свою политику безопасности, чтобы быстрее публиковать исправления ошибок, которые легче обнаруживаются с помощью искусственного интеллекта (ИИ). Это изменение уже привело к первым последствиям: быстрая публикация защищает тех, кто обновляется, но оставляет другие узлы без защиты.
В результате этого изменения, основное следствие заключается в том, что эта защита не распространилась на всех: некоторые узлы остаются уязвимыми, пока они обновляются, потому что об уязвимости уже стало известно; другие остаются уязвимыми даже после обновления, потому что их компьютер имеет техническое ограничение, которое исправление не устраняет.
Обе эти ситуации важны, потому что каждый узел хранит копию всех транзакций Bitcoin и проверяет, соответствуют ли они правилам. Если узел отключается из-за уязвимости, оператор этого узла теряет собственную возможность проверки и должен полагаться на то, что проверяют другие.
В соответствии с новой политикой, каждая уязвимость публикуется вместе с ее исправлением, и те, кто не устанавливает обновление сразу, остаются уязвимыми для атаки, которую любой злоумышленник может обнаружить, прочитав уведомление.
Новая политика ускоряет публикацию информации в Core
Раньше Bitcoin Core хранила в секрете детали уязвимости в течение определенного периода времени, называемого "запретом", который мог длиться около года, если уязвимость была средней или высокой степени серьезности (по шкале от низкой до критической).
Но теперь, в соответствии с объявленным 22 октября изменением, "запрет" отменен для уязвимостей, которые легко обнаруживаются. То есть, для тех, которые, по мнению команды, стоящей за Core, любой может обнаружить с помощью простой команды для модели ИИ или чье исправление само по себе выдает уязвимость. Для этих уязвимостей команда исправляет все поддерживаемые версии и публикует уведомление.
Антуан Пуансо, разработчик Bitcoin Core, заявил, что "запрет" только задерживает исправление в этих случаях, потому что исследование с помощью ИИ все равно может обнаружить уязвимость.
Пуансо во время конференции OPNETX, которая проходила в апреле. Источник: YouTube.
28 октября, в соответствии с этой новой политикой, были опубликованы три исправленные уязвимости, о чем сообщило CriptoNoticias. Две из них имеют среднюю степень серьезности, а одна - низкую. Project Loupe, инициатива по безопасности от Spiral, обнаружила их с помощью сканирования на основе ИИ.
Узлы Bitcoin Core: два способа остаться уязвимым
Между публикацией информации об исправлении и его установкой на каждом узле существует период уязвимости, то есть время, в течение которого об уязвимости уже известно, но узел еще не обновлен.
Согласно данным панели Clark Moody, 29 октября, через два дня после выхода версии 32.1 (с исправлением), по крайней мере, 94,9% из примерно 18 190 узлов все еще не использовали обновленную версию.
1,2% узлов Bitcoin используют обновленную версию 32.1. Источник: Clark Moody.
Ошибки средней серьезности позволяли злоумышленнику, подключенному к сети, выводить из строя любые узлы, работающие под управлением Windows, macOS или BSD. Он отправлял им срочные данные по протоколу TCP (протоколу передачи данных в интернете), которые перегружали их память, что приводило к сбоям, как было отмечено в сообщении об уязвимости. Узлы, работающие под управлением Linux, не подвергались воздействию.
Другая ошибка средней серьезности позволяла бесконтрольно увеличивать объем памяти узла (до 5 МБ в час на одно соединение), если злоумышленник имитировал отказ в поддержке сообщений проверки протокола BIP-31.
Для оценки масштаба проблемы перегрузки данными необходимо знать, сколько узлов используют Windows, macOS или BSD. Разработчик b10c предоставил 9 октября данные сканирования узлов:
| Количество узлов по системе | 14 июля | 2 августа | 1 сентября | 1 октября |
|---|---|---|---|---|
| Windows | 483 | 514 | 599 | 539 |
| macOS | 96 | 93 | 106 | 114 |
| BSD | 191 | 232 | 140 | 156 |
| Итого (Windows, macOS, BSD) | 770 | 839 | 845 | 809 |
| % от общего числа | 7,3% | 7,5% | 7,2% | 6,8% |
| Linux | 7 559 | 7 779 | 7 889 | 7 847 |
| Не идентифицированы | 2 199 | 2 544 | 2 846 | 3 202 |
| % от общего числа | 20,7% | 22,6% | 24,4% | 26,8% |
В октябре узлов с Windows, macOS или BSD было 809, что составляет 6,8% от общего числа в 11 958, что является стабильным показателем с июля.
Если бы все узлы обновились, около 770 из них оставались бы уязвимыми. Эта оценка является гипотетической, поскольку предполагает, что кто-то попытается использовать эту уязвимость, и, кроме того, это минимальная оценка, поскольку количество неидентифицированных узлов увеличилось с 2 199 до 3 202. На момент публикации этой статьи ни один из отчетов Bitcoin Core не сообщал об атакованных узлах.
Ошибки, которые остаются актуальными после обновления
Ошибка, классифицированная как "средняя", содержится в файлах отката, где узел записывает информацию о том, какие ресурсы он использовал в каждом блоке, чтобы иметь возможность отменить эти операции. Эти файлы хранили данные в формате 32-битных чисел, и майнер мог создавать действительные блоки, которые приводили к переполнению этих чисел и выводили узел из строя, пока он не восстанавливал свои данные.
Исправление расширяет эти позиции до 64 бит, но не охватывает компьютеры с 32-битными процессорами или диски FAT32, которые ограничивают размер каждого файла. При достижении этого предела узел выключается при каждом перезапуске.
В сообщении отмечается, что принудительное переполнение на 64-битном компьютере непрактично, поскольку требует около месяца работы всей сети по созданию блоков, а на 32-битном компьютере – около половины этого времени. Хотя не указано, сколько узлов используют 32-битные процессоры или диски FAT32, и политика не устанавливала ограничение на размер файлов.
Что обсуждалось до принятия новой стратегии Core
В ходе обсуждения исправления разработчик stickies-v 20 октября предупредил, что злоумышленникам выгодно автоматически отслеживать общедоступный код проекта, поэтому они узнают об уязвимости сразу после появления исправления, а большинство пользователей – только через дни или недели.
Poinsot ответил, что предупреждение об уязвимости до выпуска исправленной версии может принести больше вреда, чем пользы, в случае некритических уязвимостей (критические уязвимости рассматриваются в индивидуальном порядке).
Политика была изменена в процессе ее реализации. 27 октября Пуансо предложил уточнить в примечаниях к версии 32.1, что эмбарго не распространяется на легко обнаруживаемые уязвимости, и эти изменения были внесены 28 октября.
Цена задержки ложится на тех, кто обновляется медленно.
Уязвимость в файлах отката была обнаружена тремя независимыми источниками за 107 дней, а уязвимость в протоколе BIP-31 – двумя источниками за шесть дней. Если несколько человек обнаруживают одну и ту же уязвимость без координации, то эмбарго обеспечивает меньшую защиту, чем кажется, как утверждал Пуансо.
По мнению Пуансо, длительный период эмбарго существовал, в том числе, из-за культуры медленных обновлений. Для легко обнаруживаемых уязвимостей команда отказалась от этого периода и отдала приоритет скорости. Тот, кто обновляется быстро, защищен, а тот, кто задерживается, несет последствия.
Тот факт, что цена задержки ложится на тех, кто обновляется медленно, не означает, что длительное эмбарго было лучше. Неизвестно, сколько злоумышленников могли бы обнаружить эти уязвимости, и многочисленные сообщения об обнаружении указывают на то, что эмбарго обеспечило бы небольшую защиту. Это больше похоже на перераспределение риска на тех, кто обновляется медленно, чем на новый риск, по моему мнению.
Кроме того, серьезность уязвимости не соответствует срочности для каждого узла. Уязвимость в критически важных данных, "Средняя", приводила к отключению узлов с Windows, macOS или BSD до тех пор, пока они не обновятся, в то время как уязвимость в файлах отката, "Низкая", является единственной, которая остается открытой даже после обновления.
В дилемме между эмбарго и скоростью, команда Core выбрала прозрачность и отдала приоритет скорости. Это решение защитило тех, кто обновился, но оставило два "окна уязвимости": период времени, когда система уязвима, и компьютеры с техническими ограничениями, которые не устраняются этим исправлением.
Подробнее
Инвестиции в криптовалюты
Новости о Bitcoin
Торговая платформа
Обмен валюты
Консультации по криптовалютам
Оплата картами
Анализ рынков
Через две недели после выхода версии 32.1, команда опубликует информацию о трех других уязвимостях "Средней" или "Высокой" степени серьезности, которые были исправлены в версии 30.0, согласно примечаниям к версии 32.1. Это станет первым тестом для определения того, насколько политика различает уязвимости в зависимости от их простоты обнаружения.