Доверие, бэкдоры, цензура

BDFINFO1.9
Оффлайн
Регистрация
12.05.16
Сообщения
1.927
Реакции
523
Репутация
0
Нам нужно задаться вопросом: «Насколько мы можем доверять операционным сис-темам и приложениям, которые мы используем?» Что ж, мы знаем со стопроцентной уверенностью, что все они содержат уязвимости в безопасности и баги.

Один из способов избежать багов – это создание несложных систем . Но это недостижимо. На деле системы становится все более сложными и это одна из причин , по которой безопасность пытается оставаться на должном уровне. Сложность – это враг безопасности.
Другой способ попытаться защитить нас от этих известных уязвимостей и багов, это использование так называемых «формальных методов» в разработке програм-много обеспечения.
Программное обеспечение в целом – это математическая система, следовательно, вы можете убедиться в корректности системы при помощи тестирования и доказательства свойств этой системы. Таким образом вы сможете обеспечить завершающее доказательство корректности, что означает , неважно, какие вводные система получает, она всегда будет производить правильные расчеты.
Эта концепция не нова, этот формальный процесс изначально выполнялся специалистами по математике, так как в прошлом это невозможно было сделать при помощи программ в 50 строк кода или типа того.
Но современные системы содержат миллионы строк кода, человек не может проверить их все. Совсем недавно и алгоритмы для доказательства, и компьютерные мощности усовершенствовались настолько, что компьютеры теперь могут выполнять доказательства за человека.
К сожалению, в настоящее время только наиболее критичное программное обеспечение проходит через формальные методы, например, ПО в сфере авиаперевозок, или системы управления технологическими процессами. Формальный процесс по прежнему занимает много времени и требует больших расходов для большинства из систем.
Так что большая часть тестирования программного обеспечения в наше время не обеспечивает полного доказательства корректности , доказанного математически. Нам приходится принимать риск наличия уязвимостей в безопасности и багов и стараться минимизировать последствия в этой связи, потому что мы знаем: уязвимости в безопасности и баги будут существовать всегда. Они будут существовать в операционных системах, приложениях, аппаратном обеспечении и инструментах, которые мы используем.
Чтобы минимизировать риски, нам нужно распределить доверие, нужно уменьшить поверхность атаки, создать изоляцию и разграничение, выстроить слои защиты. Это защитит нас от наполненного багами кода. Все эти способы минимизации рисков мы рассматриваем в деталях на протяжении этого курса.
Давайте теперь поговорим об отношении бэкдоров к вашему доверию. Бэкдор – это весьма глубокое понятие. Будем считать, что бэкдор – это слабое место в системе. Здесь мы видим примеры бэкдоров. Но вам, возможно, следует относиться к этому списку скептически, потому что некоторые из примеров, на мой взгляд, не совсем точны. Вот полный список с ними, в том числе из проекта GNU, потенциальные бэкдоры в телефонах и приложениях, операционных системах, и так далее, и тому подобное, в маршрутизаторах.

Бэкдоры могут быть добавлены случайно в результате человеческой ошибки, либо преднамеренно в результате действий злоумышленника. Если что-либо имеет закрытый исходный код, единственным способом обнаружить бэкдоры является процесс под названием обратная разработка или реверс-инжиниринг. Для большинства людей это за гранью понимания и вряд ли им удастся найти что-либо хорошо скрытое. При закрытом исходном коде вам приходится доверять разработчику, что далеко от совершенства.
Системы с открытым исходным кодом потенциально имеют меньше риска по наличию в них бэкдоров, поскольку код открыт для пристального внимания общественности. Однако использование опенсорсных продуктов не защищает вас автоматически от бэкдоров, как это считают многие люди. И оно совершенно точно не предотвращает наличие уязвимостей в безопасности, которые могут использоваться в качестве бэкдоров.
В случае с открытым программным обеспечением, если мы загружаем и устанавливаем предварительно скомпилированные двоичные файлы, ничто не подтверждает, что опубликованный чистый исходный код использовался для создания бинарного файла, который вы используете. Те бинарники, которые вы компилируете, распространяете или хостите, могут содержать бэкдоры. Бинарные файлы и сигнатуры могут быть заменены злоумышленником.
Даже если вы создадите ваши собственные бинарные файлы из исходного кода, нет гарантии, что там не будет бэкдора. Вам придется персонально проанализировать исходный код перед тем, как его скомпилировать , что зачастую невозможно осуществить. Или вам придется произвести валидацию сигнатуры чистого исходного кода перед его компиляцией.
Но как нам узнать, что исходный код чист от бэкдоров? Что ж, это трудная задача. Компиляторы, используемые разработчиками, могут содержать в себе бэкдоры для создания бэкдоров в приложениях, которые они компилируют, и разработчики не будут об этом знать.
Это произошло с пиратской версией Xcode, что привело к заражению вредоносным кодом приложений в Apple Store. Разработчики приложений не заметили, что добавляют вредоносный код во время компиляции при помощи той пиратской версии Xcode.
Существуют и бэкдоры, принудительно встроенные против вас по законодательству национальных государств, и это неизбежная проблема.
Бэкдоры могут быть очень, очень хитроумными и трудными для обнаружения. Всего лишь малейшее преднамеренное или случайное изменение кода может создать уязвимость и это может создать бэкдор.
Здесь у меня пример для вас, это маршрутизаторы Juniper со встроенными бэкдорами, и я зачитаю краткий отчет Марка Грина, который являлся участником расследования касаемо этого конкретно хитрожопого бэкдора.
«Выяснилось, что на протяжении последних нескольких лет в устройства Juniper NetScreen был внедрен генератор случайных чисел с потенциальным бэкдором, основанный на алгоритме АНБ Dual_EC_DRBG. На определенном этапе в 2012 году код в NetScreen был изменен неизвестной стороной, этот бэкдор мог использоваться для перехвата соединений NetScreen. Поскольку эта модификация кода не была утверждена компанией Juniper, важно отметить, что злоумышленники не изменили основной код механизма шифрования, они изменили лишь параметры. Это означает, что системы были заранее потенциально уязвимы для третьих сторон. Более того, характер этой уязвимости крайне хитер и в целом запутан».
Весьма трудноуловимый бэкдор. Определенно, работа государства или хакерской группы экспертного уровня. Интересно также то, что он основан на алгоритме АНБ Dual_EC_DRBG, именно поэтому люди не доверяют стандартам, продвигаемым АНБ в список стандартов Национального института стандартов и технологий США. Не доверяют, потому что верят в то , что эти стандарты были преднамеренно определены таким образом, что некоторые из них сделаны намеренно слабыми.
Лично мое мнение, я считаю, что бэкдоры – это серьезная проблема для любого человека, который заботится о безопасности, приватности и анонимности. Любые инструменты, которые вы используете в перспективе, будут становиться мишенью для ослабления и внедрения в них бэкдоров. Это будет происходить при помощи легальных методов, что чрезвычайно тревожит, либо при помощи хакерства.
Целью будет все – операционные системы , шифрование, сервисы безопасности, приложения и даже аппаратное обеспечение и встроенное программное обеспечение, то есть прошивка устройств. Любой сервис для анонимизации, который вы знаете, может попасть под атаку хакеров, корпораций или государства с целью внедрения в него бэкдора. И нельзя создать бэкдор, который будет доступен лишь для хороших парней, как только система ослабляется, она ослабляется для всех.
Итак, как нам с вами минимизировать риски, связанные с бэкдорами? Что ж, у нас есть детерминированные и воспроизводимые сборки, они могут помочь обнаружить бэкдоры.
Воспроизводимая сборка. Воспроизводимые сборки – это набор практик по разработке программного обеспечения, при котором создается верифицируемый путь от исходного кода в читабельном для человека виде до бинарного кода, используемого компьютерами.
Это означает, что если говорится о том , что бинарный код был скомпилирован из определенного исходного кода, то так оно и есть доподлинно. В случае с воспроизводимыми сборками, различные стороны производят повторную сборку независимо друг от друга и убеждаются, что у них у всех получается совершенно одинаковый результат. Однако, об этом легче говорить, чем выполнить в реальности.
Система сборки должна быть сделана полностью детерминированной, а среда сборки должна быть либо зафиксирована, либо предопределена. Пользователи также дол-жны иметь возможность валидировать результаты. Им должен быть предоставлен способ воссоздания схожей среды сборки, возможность производить процесс сборки и верифицировать тот факт, что выходной результат совпадает с оригинальной сборкой.
По-настоящему полные детерминированные и воспроизводимые сборки нуждаются в огромных усилиях и трудны для настройки. Насколько я знаю, пока что не существует операционных систем, которые были бы полностью детерминированно собраны.
Проводится хорошая работа в проекте Debian, вот почему я бы порекомендовал именно эту операционную систему тем людям, которые заботятся о безопасности, приватности и анонимности.
Если в вашей операционной системе есть бэкдоры, все ваши усилия напрасны, так что жизненно необходимо, чтобы ваша операционная система была надежна. Debian делает успехи в этом направлении.
Давайте посмотрим на этот список, мы обсудим все это позже, все эти дистрибутивы делают большие шаги на пути к детерминированным и воспроизводимым сборкам.
Если вы заинтересованы углубиться в этот вопрос, допустим , вы разработчик, то вот хороший материал от джентльмена по имени Майк Перри по Это интересный материал.
Можете также посмотреть это видео на тему ».

Цензура

Цензурирование Интернета осуществляется не только в странах типа Китая или Ирана, оно существует в разных формах и на Западе. Например, Верховный суд Канады принял временное предписание с требованием выпилить из поисковой выдачи результаты по одной из двух конкурирующих компаний не только в канадском сегменте Google.ca, но и из сегментов Google в других странах.
Европейские суды вынесли решение в пользу гражданина Испании по делу против Google, связанному с поисковой выдачей, содержащей деликатную финансовую информацию, случай получил широкую огласку как "Право на забвение". Суд постановил, что Google и другие поисковые системы должны удалить результаты поисковой выдачи, которые являются неверными, иррелевантными или более не релевантными, или избыточными в отношении цели, с которой они обрабатывались, ввиду истекшего периода времени.
Аргентинская модель вызвала в суд Google и Yahoo с требованием от поисковых гигантов удалить изображения, перенаправляющие ее на сайты с порнографическим контентом.
Пользователям Интернета в Великобритании запрещен доступ на ряд веб-сайтов по умолчанию. Доступ фильтруется на уровне интернет-провайдеров. Чтобы получить доступ до блокируемого контента, пользователям необходимо обратиться к провайдеру и отказаться от данной фильтрации.
В США предпринимались ряд санкционированных правительством попыток регулирования контента, которые отменялись на основании Первой поправки к Конституции США, зачастую после продолжительных судебных тяжб. Правительство оказывает непрямое давление там, где не может цензурировать напрямую.

Ограничения контента в большинстве случаев производятся при помощи удаления контента, а не его блокировки. Чаще всего регуляторы полагаются на привлечение частных лиц при поддержке государства или угрозы судебного разбирательства.

По сравнению с большинством стран мира, где интернет-провайдеры вынуждены подчиняться государству, в США большая часть действий по регулированию контента происходит на частном или добровольном уровне.

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