Bitcoin Core додав захист від підроблених рядків у журналах вузла
Публікація джерела: 2026-09-30 · Редакційний аналіз опубліковано: 2026-10-01
Журнал тепер екранує вбудовані переноси рядка з недовірених даних, тому відхилені RPC-методи або рядки гаманця не можуть виглядати як справжні повідомлення вузла. Патч у master, але ще не у фінальному релізі.
Аналіз і практичні висновки
У цьому розділі — наш аналіз та умовні розрахунки, окремо від повідомлення джерела.
Введення користувача може призвести до появи фальшивого повідомлення в debug.log
Супроводжувачі Bitcoin Core об’єднали запит на отримання 35833 30 вересня 2026 року. Проблема стосувалась контрольованого користувачем тексту, який досягав повідомлень журналу з вбудованим символом нового рядка. Обмежений користувач RPC може вказати ім’я відхиленого методу або пов’язане з гаманцем введення може ввести попередження, а новий рядок дозволяє наступному тексту починатися з нового рядка. Цей другий рядок може бути відформатований так, щоб він нагадував справжню помилку Bitcoin Core, навіть якщо вузол не викликав події.
Атака вплинула на інтерпретацію журналу, а не на консенсус
Продемонстрованою проблемою було впровадження журналу. Це може ввести в оману оператора, інструмент моніторингу або службу реагування на інциденти, які читають debug.log. Запит на отримання не описує спосіб зміни блоків, викрадення винагород за майнінг, обходу підтвердження роботи або зміни стану консенсусу. Це також не представлено як неавтентифіковане віддалене виконання коду. Для продемонстрованих випадків потрібен був обмежений доступ RPC або інший шлях, який розміщує контрольовані дані в зареєстрованому повідомленні.
Вбудовані символи нового рядка тепер екрановані
Об’єднана реалізація змінює реєстратор, тому вбудовані символи нового рядка представлені у вигляді екранованої послідовності байтів, наприклад \x0a. Звичайний завершальний символ нового рядка видаляється перед екрануванням, а реєстратор додає кінцевий символ кінця рядка централізовано. У результаті один виклик журналу займає один фізичний рядок, а контрольований текст не може створити додаткове повідомлення з власною міткою часу чи префіксом серйозності. Друковані символи та UTF-8 залишаються доступними для діагностики.
Відхилені методи RPC були частиною відтворювача
Демонстрація запиту на отримання запустила вузол перевірки регулярних процедур із білим списком RPC і викликала заборонений метод, ім’я якого містило символ нового рядка, за яким ішов текст, схожий на помилку ConnectTip. Перед виправленням кована частина з’явилася в окремому рядку. Після виправлення новий рядок відображався як екрановані дані в попередженні. Авторизація все одно відхилила метод; проблема полягала у візуальній автентичності додаткового рядка журналу, а не в доступі до забороненої команди RPC.
Шляхи гаманця та попередження про запуск отримали регресію
Фінальні тести охоплюють відхилені назви методів RPC, вхідні дані для створення гаманця та попередження про запуск для постійного шляху гаманця, який зник. Рецензенти виявили, що проміжний підхід SplitLines може відтворити частину проблеми, тому цей підхід було видалено перед злиттям. Останній патч використовує центральне екранування та перевіряє, чи підроблений текст не відображається як окреме попередження чи помилка. Ця історія переглядів показує, чому оператори повинні оцінювати об’єднану різницю, а не попередню версію.
Оператори пулів часто автоматизують обробку журналів
Пули майнінгу та шлюзи соло-майнінгу зазвичай запускають Bitcoin Core поряд із серверами шаблонів, системами виплат і агентами моніторингу. Їхнє сповіщення може аналізувати debug.log на наявність збоїв у ланцюжку підказок, mempool, гаманця чи мережі. Фальшива лінія може спровокувати помилковий інцидент, забруднити контрольний слід або відвернути увагу служб реагування. Після розгортання версії, що містить виправлення, вбудовані символи нового рядка відображаються екранованими, тому будь-який синтаксичний аналізатор, який очікує багаторядкових повідомлень, слід перевірити та налаштувати.
Патч пройшов перевірку та автоматизовані перевірки
Остаточна зміна була об’єднана в головну гілку як commit d4b0e1e після перегляду, і GitHub повідомляє про 27 перевірок. Запит на отримання містить два коміти: тести, що характеризують уражені вхідні дані, і зміну журналу, яка виходить із вбудованих символів нового рядка. Попередні проблеми CI належали до проміжних версій і були очищені перед злиттям. На основній сторінці не вказано, що виправлення включено в підписаний остаточний випуск Bitcoin Core.
Об’єднаний код – це не те саме, що випущений двійковий файл
Оператори не повинні описувати це як встановлене виправлення на кожному вузлі. Патч присутній у основній версії Bitcoin Core, тоді як у робочих розгортаннях зазвичай використовуються випуски з тегами та підписами. Команди, які будують з джерела, потребують власного відтворюваного процесу збирання та перевірки. Усі інші мають переглянути офіційні примітки до випуску, перевірити підписи та провести оновлення перед зміною інфраструктури пулу. У статті уникають призначення номера версії, який не встановлює сам запит на отримання.
Практичні кроки для команд інфраструктури майнінгу
Оператори можуть обмежити облікові дані RPC, зберегти надійне походження журналу та уникнути розгляду лише тексту журналу як доказу збою консенсусу. Сповіщення про серйозні події мають співвідносити журнали зі станом RPC, одноранговими даними та незалежними вузлами. Перед оновленням пошукайте в приватних парсерах припущення щодо багаторядкових повідомлень; після оновлення перевірте, чи вбудовані керуючі символи залишаються в одному рядку, а важливі сповіщення все ще запускаються. Підтвердженим результатом є покращення цілісності журналу, а не зміна швидкості видобутку чи блокової конструкції.
Джерело: Bitcoin Core ↗
Калькулятор майнінгу ↗
