Проверка того, что программное обеспечение с открытым исходным кодом не было подделано

Question

Я собираюсь загрузить некоторое программное обеспечение OSS, и я хотел бы убедиться (с достаточной степенью уверенности), что оно не было подделано для вставки вредоносного ПО. В частности, это менеджер паролей (KeePassX), который кажется чрезвычайно сочной целью для взлома, поэтому я чувствую себя особенно параноиком.

Я могу придумать два вектора для вставки вредоносного кода:

• Вредоносные программы пробиваются в официальный исходный код.
• Вредоносная вилка или сборка заменяет официальную на сайте.

Страница загрузки предоставляет контрольные суммы; однако, это, кажется, не защитит от вышеупомянутых двух взломов.

У меня нет опыта или времени, чтобы провести аудит исходного кода.

Каковы лучшие практики для проверки программного обеспечения с открытым исходным кодом чувствительного характера на наличие вредоносных программ?

Answer 1

Насколько параноиком ты хочешь быть? Вы доверяете своему компилятору? Есть интересная история (прочитайте раздел « Размышления о доверии») от Кена Томпсона, одного из первых создателей Unix. Он описывает систему, в которой программа входа в систему имеет бэкдор, позволяющий ему получить доступ к любой машине. Компилятор изменен, так что когда кто-то компилирует чистый исходный код программы входа в систему, компилятор замечает и вставляет код бэкдора.

Компилятор также замечает, что кто-то компилирует чистый исходный код компилятора, и также вставляет туда соответствующий код. В те дни все было доступно в качестве исходного кода, но для начала вам понадобится двоичная версия компилятора. Таким образом, вредоносный код никогда не обнаруживается в исходном коде, а распространяется как перекомпилированные биты системы. Это было бы невероятно трудно понять, в основном требуя аудита работающего кода.

Возвращаясь к первоначальному вопросу, вы должны кому-то доверять. Вопрос в том, как далеко вам нужно пройти по цепочке? С хорошо известным проектом шансы, что кто-то заметит, возникнет ли проблема довольно быстро.

Answer 2

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

Решение состоит в том, чтобы перестать бояться источника.

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

Вы также можете сосредоточиться на логике проблемы: из-за большого количества глаз, просматривающих каждый фрагмент кода, и крайне низкой вероятности, что достаточное количество этих глаз будет куплено создателями вредоносного ПО, чтобы заставить вредоносный код чтобы быть включенным, вероятность того, что плохой код превратил его в такой инструмент, также равна нулю.

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

Answer 3

Если вы найдете зеркало пакетов, вы можете сравнить их контрольные суммы.

Это защитит от второго вектора, при условии, что пакеты были отражены до того, как они были заменены.

Для защиты от первого вектора вам, вероятно, придется взглянуть на изменения в исходном коде.

Answer 4

Вредоносные программы пробиваются в официальный исходный код.

Если вы не имеете дело с ежедневными сборками, это вряд ли произойдет.

Вредоносная вилка или сборка заменяет официальную на сайте.

Это потребовало бы доступа к веб-сайту, что вряд ли произойдет, если кто-то не заметит, вы должны быть гораздо более обеспокоены тем, что веб-сайт MySQL будет скомпрометирован.

Страница загрузки предоставляет контрольные суммы; однако, это, кажется, не защитит от вышеупомянутых двух взломов.

Конечно, это делает ... Кто-то должен был опубликовать те значения, которые они не генерировали автоматически.