The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Команда из Университета Миннесоты раскрыла детали об отправленных вредоносных изменениях"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Подсказка: Второй уровень иерархии тем в форуме реализован через вкладку "Показ ключевых тем".
. "Команда из Университета Миннесоты раскрыла детали об отправл..." +/
Сообщение от Ordu (ok), 01-Май-21, 20:06 
> А если гипотезы нет?

Рыть данные и искать гипотезу. Мозгами шевелить, применять свою способность к распознаванию паттернов.

То есть, начать стоит с какой-нибудь теории "кухонного" уровня, можно даже уровня "теории заговора". А потом из этой теории делать предсказания-гипотезы и проверять их данными. Если этот способ срезать угол не сработает, тогда смотреть в данные и надеятся на свои способности высматривать паттерны. Если они не сработают, то мерять по каждому багу сотню параметров, и скармливать в факторный анализ, или ещё какие-нибудь интересные статистики считать. Продолжать до тех, пока не случится прихода. Лучше делать это не в одиночку, а группой из 3-5 человек: каждый ищет вроде и сам по себе, но раз в пару недель встречаетесь и делитесь мыслями.

И да, я бы предположил, что сходу найти не удастся, и если подумать недельку то тоже не удастся. Потому что разработчики и мейнейнеры подсистем постоянно эти данные наблюдают год за годом, и всё что там можно было высмотреть простого они уже высмотрели скорее всего.

> Задача поиска уязвимостей в ядре - другая.

А я не говорил про поиск уязвимостей. В смысле тебе придётся искать баги, чтобы оценивать как их туда пропихивали. Но искать эти баги проще в инете -- найти какую-нибудь базу данных багов в ядре, или может список рассылки перерыть на предмет багфиксов, и таким образом найти баги, а потом git blame подскажет бажный коммит, а потом по коммиту можно найти тред в списке рассылке. Возможно тебе придётся классифицировать эти баги, чтобы не сравнить нечаянно "вероятность пропихнуть через ревью баг класса A методом X" с "вероятностью пропихнуть через ревью баг класса B методом Y". Тебе же хочется сравнивать методы, а значит по классу надо контролировать, в том смысле, что сравнивать надо "класс A с методом X" с "класс A с методом Y". А это значит, что надо уметь измерять класс бага. Но это всё сопутствующие задачи, не умея решать которые ты просто не сможешь провести ни одного полезного исследования методов пропихивания багов.

Я говорил про то, что все эти поисковые запросы по базе данных багов или по списку рассылки неплохо было бы автоматизировать. Пускай даже и отчасти: перебор данных -- это надолго, сокращение время затрачиваемого на анализ бага даже на 10% -- это очень полезно. Если же удастся автоматизировать вообще полностью, чтобы сказать "SELECT patch, bugfix, thread WHERE bugclass="double-free" AND contains(method, "аппеляция к гомофобии") и скрипт бы так попыхтел-попыхтел, перерыл архивы списка рассылки, и выдал бы результат -- дык это вообще будет огонь. Парочку-тройку гипотез проверить, опубликовать пару-тройку статей, и ещё одну статью про этот скрипт. И потом сидеть и собирать ссылки на себя из других работ десятками. Или даже оформить в виде платной программы, и грести деньги лопатой.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Команда из Университета Миннесоты раскрыла детали об отправленных вредоносных изменениях, opennews, 28-Апр-21, 22:24  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру