В последние два дня я разбирал анализ безопасности AEGIS для @Dusk и сначала запомнил только «39 исправлений, 7 critical», но после изучения деталей понял, что большой размер числа — не главное. В итоге 7 серьёзных проблем свелись к 4 категориям первопричин: проблема с псевдонимами в VM-песочнице, небезопасная десериализация на стороне хоста, отсутствие полной связки между комиссиями Phoenix и возвратами, а также путь подделки BLS-подписей.
Почему смотреть на первопричины, а не только на число уязвимостей? Потому что если граница доверия спроектирована неправильно, проблемы будут снова и снова возникать в разных модулях. Например, если данные десериализуются до проверки ввода, на поверхности это выглядит как обычная ошибка разбора, но на деле может затронуть безопасность памяти хоста; группа проблем Phoenix тоже была не просто про «чуть неверный расчёт комиссии», а про то, что доказательства, подписи и выполнение возврата не говорили на одном и том же языке семантики, и в худшем случае это могло затронуть целостность поставок и безопасность средств.
Официально говорится, что на данный момент не обнаружено, чтобы эти critical были использованы до исправления; я готов воспринимать это как вывод расследования, но не буду превращать это в утверждение «абсолютно точно ничего не происходило». Для $DUSK положительный сигнал AEGIS в том, что команда открыто опубликовала внутренние находки вплоть до первопричин и логики исправлений; отрицательный сигнал столь же ясен: в основном стеке после запуска основной сети действительно возникали серьёзные пробелы, способные повлиять на исполнение, подтверждение консенсуса и доступность цепочки.
Поэтому я не стал бы просто ставить на #dusk «печать безопасности» только потому, что аудитов было много. Более полезное наблюдение такое: будет ли в следующем раунде продолжено раскрытие информации, будут ли тесты на регрессию по тем же типам границ, сможет ли внешний аудит охватить код после AEGIS. Что для вас важнее: чтобы у проекта вообще никогда не всплывали крупные проблемы, или чтобы после их обнаружения он мог чётко объяснить первопричину, влияние и цепочку исправлений?
$USELESS $BOME
Почему смотреть на первопричины, а не только на число уязвимостей? Потому что если граница доверия спроектирована неправильно, проблемы будут снова и снова возникать в разных модулях. Например, если данные десериализуются до проверки ввода, на поверхности это выглядит как обычная ошибка разбора, но на деле может затронуть безопасность памяти хоста; группа проблем Phoenix тоже была не просто про «чуть неверный расчёт комиссии», а про то, что доказательства, подписи и выполнение возврата не говорили на одном и том же языке семантики, и в худшем случае это могло затронуть целостность поставок и безопасность средств.
Официально говорится, что на данный момент не обнаружено, чтобы эти critical были использованы до исправления; я готов воспринимать это как вывод расследования, но не буду превращать это в утверждение «абсолютно точно ничего не происходило». Для $DUSK положительный сигнал AEGIS в том, что команда открыто опубликовала внутренние находки вплоть до первопричин и логики исправлений; отрицательный сигнал столь же ясен: в основном стеке после запуска основной сети действительно возникали серьёзные пробелы, способные повлиять на исполнение, подтверждение консенсуса и доступность цепочки.
Поэтому я не стал бы просто ставить на #dusk «печать безопасности» только потому, что аудитов было много. Более полезное наблюдение такое: будет ли в следующем раунде продолжено раскрытие информации, будут ли тесты на регрессию по тем же типам границ, сможет ли внешний аудит охватить код после AEGIS. Что для вас важнее: чтобы у проекта вообще никогда не всплывали крупные проблемы, или чтобы после их обнаружения он мог чётко объяснить первопричину, влияние и цепочку исправлений?
$USELESS $BOME
