На этой неделе Oracle находится в горячей воде из- за сообщения в блоге, написанного их начальником службы безопасности Мэри Дэвидсон. Эта публикация, хотя и охватывает ряд тем, в основном посвящена практике сообщения о возможных уязвимостях безопасности в Oracle. В частности, почему вы не должны.
«Недавно я наблюдал резкий скачок в том, что клиенты перепроектировали наш код, чтобы попытаться найти в нем уязвимости безопасности.
Вот почему я писал много писем клиентам, которые начинаются с «привет, howzit, aloha», но заканчиваются словами «пожалуйста, соблюдайте ваше лицензионное соглашение и уже не останавливайте реверс-инжиниринг нашего кода».
Дэвидсон объясняет, что растет число клиентов, которые заботятся о безопасности, и занимаются реверс-инжинирингом программного обеспечения Oracle, которое ищет уязвимости в системе безопасности (или нанимает консультантов, чтобы сделать это для них). Дэвидсон обвиняет этих клиентов в нарушении их лицензионных соглашений, в непринятии мирских мер безопасности, в попытке выполнить за них работу Oracle и в целом в том, что они являются плохими людьми. Если заказчик обнаружил реальную уязвимость, то Oracle ее исправит.
«Я почти не хочу отвечать на этот вопрос, потому что хочу повторить, что клиенты не должны и не должны перепроектировать наш код. […] Мы не дадим клиенту, сообщившему о такой проблеме (которую он обнаружил с помощью обратного инжиниринга), специальное (одноразовое) исправление для этой проблемы. Мы также не будем предоставлять кредит в любых рекомендациях, которые мы можем выпустить. Вы не можете ожидать, что мы скажем «спасибо за нарушение лицензионного соглашения».
Это не прошло хорошо в сообществе безопасности, и пост был быстро снят, хотя не раньше, чем появился новый хэштег
Но, если вы не знакомы с миром безопасности, может быть не очевидно, почему оригинальная запись так ошибочна. Итак, сегодня мы поговорим о том, где философия безопасности Oracle отходит от мейнстрима и почему это проблема.
Объясняя спор
Итак, что же такое реверс-инжиниринг, и почему Дэвидсон так обеспокоен этим? По сути, когда Oracle выпускает часть программного обеспечения, они «компилируют» свой внутренний исходный код в исполняемые файлы, а затем доставляют эти файлы клиентам. Компиляция — это процесс, который переводит понятный человеку код (на таких языках, как C ++ ) на более плотном двоичном языке, который можно подавать непосредственно в процессор компьютера.
Исходный код Oracle не является общедоступным. Это сделано для того, чтобы другим было сложнее украсть их интеллектуальную собственность. Однако это также означает, что клиентам очень трудно проверить, что код безопасен. Это где «декомпиляция» вступает в игру. По сути, декомпиляция переводит в другом направлении, преобразуя исполняемые файлы обратно в читаемый человеком код. Это не обеспечивает точно исходный исходный код, но обеспечивает код, который функционирует одинаково — хотя его часто трудно читать из-за потери комментариев и организационной структуры.
Это «обратный инжиниринг», на который ссылается Дэвидсон. Oracle против, потому что они думают, что это ставит под угрозу их интеллектуальную собственность. Это, по крайней мере, немного глупо, потому что использование лицензионного соглашения для запрета кражи IP немного похоже на использование строгого циновки для предотвращения вторжения в дом. Виды людей, которые собираются клонировать ваши продукты, не заботятся о лицензионных соглашениях. , и часто не в тех юрисдикциях, где вы могли бы в любом случае применять эти соглашения.
Политика действительно влияет только на законных клиентов. Ситуация схожа с видеоигрой DRM , но как-то даже неэффективно.
Почему клиенты хотят декомпилировать эти исполняемые файлы? Это все о безопасности. Наличие доступа к исходному коду позволяет вам копаться в нем в поисках ошибок и потенциальных проблем. Часто это делается с помощью программного обеспечения, которое выполняет «статический анализ кода» — автоматическое считывание кода, которое выявляет известные ошибки и опасные методы работы с программным обеспечением, которые, как правило, приводят к ошибкам. Хотя существуют инструменты, которые непосредственно анализируют исполняемый файл, его декомпиляция позволяет проводить более глубокий анализ. Этот вид статического анализа является стандартным инструментом в торговле безопасностью, и большинство компаний, которые заботятся о безопасности, используют такое программное обеспечение для создания кода, который с меньшей вероятностью содержит серьезные ошибки.
Политика Oracle в отношении такого анализа просто «нет». Почему? Я позволю Дэвидсону объяснить.
«Клиент не может проанализировать код, чтобы увидеть, существует ли элемент управления, предотвращающий атаку, о которой кричит инструмент сканирования (что, скорее всего, является ложным срабатыванием) […] Теперь я должен отметить, что мы не просто принимаем Отчеты о сканировании являются «доказательством наличия там, там», отчасти потому, что если вы говорите о статическом или динамическом анализе, отчет о сканировании не является доказательством фактической уязвимости. […] О, и мы требуем, чтобы клиенты / консультанты уничтожили результаты такого реверс-инжиниринга и подтвердили, что они это сделали ».
Другими словами, инструмент, который дает результат, не является доказательством реальной ошибки — и, поскольку Oracle использует эти инструменты внутри, нет смысла в том, чтобы клиенты использовали их самостоятельно.
Большая проблема в том, что эти инструменты статического анализа кода не существуют просто для того, чтобы привлечь внимание к ошибкам. Они также должны служить целью для качества и безопасности кода. Если вы сбросите кодовую базу Oracle в стандартный инструмент статического анализа, и он выплеснет сотни страниц проблем, это действительно плохой знак.
Правильный ответ, когда инструмент статического анализа кода выявляет проблему, не должен смотреть на проблему и говорить: «О, нет, это не вызывает ошибку, потому что такой-то». Правильный ответ — войти и исправить проблему. Вещи, помеченные инструментами статического анализа кода, обычно являются плохой практикой, и ваша способность определить, действительно ли данная проблема вызывает ошибку, ошибочна. Более тысячи вопросов, вы будете пропустить вещи. Вам лучше не иметь таких вещей в своей кодовой базе в первую очередь.
Вот технический директор Oculus Джон Кармак, воспевающий эти инструменты со времени его работы в iD Software. (Серьезно, прочитайте целое эссе , это интересные вещи).
«У нас был период, когда один из проектов случайно отключил опцию статического анализа на несколько месяцев, и когда я заметил и снова включил ее, в промежутке между тем появились новые ошибки. […] Это были демонстрации того, что обычные операции разработки постоянно генерировали эти классы ошибок, и [статический анализ кода] эффективно защищал нас от многих из них ».
Короче говоря, вполне вероятно, что многие клиенты Oracle не обязательно пытались сообщать о конкретных ошибках — они спрашивали, почему практика кодирования Oracle была настолько плохой, что их кодовая база была пронизана тысячами и тысячами проблем, настолько базовых, что их можно было выбрать автоматизированным программным обеспечением.
Безопасность наклейками
Итак, что должны делать клиенты, связанные с безопасностью, вместо использования инструментов статического анализа? К счастью, сообщение Дэвидсона в блоге было очень подробно на эту тему. Помимо защиты общих базовых практик безопасности, она делает конкретные предложения для тех, кто обеспокоен безопасностью используемого ими программного обеспечения.
«[T] здесь много вещей, которые может сделать клиент, черт возьми, на самом деле говорить с поставщиками об их программах обеспечения или проверять сертификаты на продукты, для которых есть печати Good Housekeeping (или« хорошего кода »), такие как Common Criteria сертификаты или сертификаты FIPS-140. Большинство поставщиков — по крайней мере, большинство известных мне крупных компаний — имеют достаточно надежные программы обеспечения доверия (мы знаем это, потому что все мы сравниваем записи на конференциях) ».
Это ужасающий ответ от такой крупной организации, как Oracle. Компьютерная безопасность — это быстро развивающаяся область. Новые уязвимости обнаруживаются постоянно, а оформление требований безопасности в виде сертификата, который обновляется каждые несколько лет, абсурдно. Безопасность это не наклейка. Если вы уверены, что часть критически важного программного обеспечения защищена на основе печати на упаковке, вы безответственно глупы.
Черт возьми, инструменты статического анализа обновляются гораздо чаще, чем эти сертификаты — в некоторых случаях, ежедневно — и устранения всех возникающих проблем по- прежнему недостаточно для уверенности в безопасности вашего кода, поскольку большинство уязвимостей слишком сложный, чтобы быть обнаруженным этими видами автоматизированных инструментов.
Единственный способ быть уверенным в собственной безопасности — это показать свой код миру и попросить хакеров попытаться взломать его. Именно так работают большинство крупных компаний-разработчиков программного обеспечения: если вы обнаружите проблему с их кодом, они не будут снисходительно насмехаться над вами за нарушение вашего соглашения об использовании. Они заплатят тебе деньги. Они хотят, чтобы люди старались изо всех сил ломать свое программное обеспечение все время. Только так они могут быть уверены, что их код безопасен.
Эти программы называются программами «наградой за ошибки», и это лучшее, что может случиться с безопасностью корпоративного уровня за долгое время. По совпадению, у них тоже есть довольно сильные мнения о Дэвидсоне.
«Дары ошибок — это новая группа мальчиков (симпатичная аллитерация, не так ли?) Многие компании кричат, падают в обморок и бросают нижнее белье исследователям безопасности […], чтобы найти проблемы в своем коде и настаивают на том, что это путь, иди в него: если вы не делаете ошибок, ваш код не защищен.
Что ж, мы сами находим 87% уязвимостей безопасности, исследователи безопасности находят около 3%, а остальные находят клиенты. […] Я не оспариваю вознаграждение за ошибки, просто отмечаю, что на строго экономической основе, почему я выбрасываю много денег на 3% проблемы ».
Для начала, основываясь на результатах этих статических анализов кода, может оказаться, что вы заплатите намного больше 3%. Но я отвлекся. Суть в следующем: щедрость не для вас, а для нас. Можете ли вы найти ошибки более эффективно, если бы вы потратили те же деньги на экспертов по внутренней безопасности? Ну, вероятно, нет — но давайте бросим Oracle кость и предположим, что они могли. Тем не менее, они также могут взять деньги, обналичить их, а затем ничего не делать. Если полученная безопасность не соответствует требованиям, клиенты узнают об этом только через несколько лет, когда их номера социального страхования загадочным образом в глубокой сети. .
Количество ошибок существует наполовину потому, что они действительно эффективный способ выявления ошибок, и наполовину потому, что это форма безопасности, которую вы не можете подделать. Награда за ошибки достоверно говорит миру, что любые ошибки, оставленные в коде, более дороги, чем указанная награда.
Оракул не существует для вашего удобства, Oracle, они существуют потому, что мы вам не доверяем.
Мы не должны! Множество крупных компаний допускают, что безопасность падает на второй план, так как множество мегабрехов слишком ясно. Вы второй по величине производитель программного обеспечения в мире. Абсурдно просить нас поверить, что ваши продукты в безопасности.
Что Дэвидсон получает право
Справедливости ради Дэвидсон, есть элементы этого, которые являются разумными в контексте. Вероятно, многие из их клиентов предпринимают амбициозные проверки кода Oracle, не тратя время на устранение более обыденных проблем безопасности в своих системах.
«Продвинутые постоянные угрозы» — опытные хакерские организации, пытающиеся получить доступ к конкретным организациям для кражи данных, — это, конечно, страшно, но по количеству они намного менее опасны, чем миллионы оппортунистических хакеров-любителей с автоматизированными инструментами. Выполнение такого рода статического анализа коммерческого программного обеспечения, когда вы не приняли основные меры безопасности, очень похоже на установку комнаты для паники, когда у вас еще нет замка на входной двери.
Точно так же, вероятно, действительно разочаровывает и бесполезно снова и снова повторять один и тот же автоматический анализ.
Однако в целом статья раскрывает некоторые серьезно устаревшие идеи о безопасности системы и отношениях между разработчиками и клиентами. Я ценю то, что работа Дэвидсона разочаровывает, но пользователи, пытающиеся проверить безопасность используемого ими программного обеспечения, не являются проблемой. Вот президент Security Awareness Айра Винклер:
«Oracle — очень большая и богатая компания, продукты которой широко распространены и используются для критически важных приложений. Период. Они несут ответственность за то, чтобы сделать их программное обеспечение как можно более сильным […]. Может быть много ложных срабатываний и связанных с этим затрат, но это является фактором [их продажи] большого количества программного обеспечения, у которого много пользователей. Это стоимость ведения бизнеса. Я уверен, что все компании-разработчики программного обеспечения имеют одинаковые ложные положительные отзывы. Я не слышу, Microsoft и др. жалуюсь «.
Если Oracle не хочет получать тысячи проблем, обнаруженных статическими инструментами безопасности, возможно, им следует решить эти тысячи проблем. Если их раздражают люди, которые снова и снова обращаются к одним и тем же не-ошибкам, возможно, у них должна быть правильная программа за вознаграждение за ошибки, в которой есть механизмы для работы с повторными представлениями не-проблем. Клиенты Oracle требуют более высоких стандартов безопасности, и стыдить их за это не правильный ответ.
Несмотря на то, что Oracle снял и вообще дезавуировал пост, тот факт, что он был написан, обнаруживает глубоко ошибочную культуру безопасности в Oracle. Подход Oracle к безопасности отдает приоритет защите собственной интеллектуальной собственности над безопасностью и спокойствием их клиентов — и если вы доверяете программному обеспечению Oracle критически важную информацию, это должно вас напугать.
Что вы думаете? Вы обеспокоены философией безопасности Oracle? Как вы думаете, с Дэвидсоном слишком жестоко обращаются? Дайте нам знать об этом в комментариях!