Типы уязвимостей системы обеспечения безопасности

Уязвимости системы обеспечения безопасности программного обеспечения Most попадают в один из маленького набора категорий:

В этой главе описываются природу каждого типа уязвимости.

Переполнение буфера

Когда приложение пытается записать данные мимо конца (или, иногда, мимо начала) буфера, переполнение буфера происходит.

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

Книги по безопасности программного обеспечения неизменно упоминают переполнение буфера как основной источник уязвимостей. Точные числа тверды прибыть, но как индикация, приблизительно 20% опубликованного использования, о котором сообщает Компьютерная Команда Готовности Чрезвычайной ситуации США (США-CERT) на 2004, включили переполнение буфера.

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

Атаки переполнения буфера обычно происходят путем заключения компромисса или штабеля, «кучи» или обоих. Для получения дополнительной информации читайте Переполнение буфера Предотвращения и Потери значимости

Непроверенный ввод

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

Например, графический файл может обоснованно содержать изображение, которое является 200 на 300 пикселей, но не может обоснованно содержать изображение, которое является 200 на-1 пиксель. Ничто не препятствует тому, чтобы файл утверждал, что содержал такое изображение, однако (кроме соглашения и здравого смысла). Наивная программа, пытающаяся считать такой файл, попыталась бы выделить буфер неправильного размера, приведя к потенциалу для атаки переполнения «кучи» или другой проблемы. Поэтому необходимо проверить входные данные тщательно. Этот процесс обычно известен как проверка здравомыслия или контроль ввода.

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

Хакеры смотрят на каждый источник ввода к программе и попытки передать в некорректных данных каждого типа, который они могут вообразить. Если программа отказывает или иначе неправильно себя ведет, хакер тогда пытается найти способ использовать проблему. Непроверенный - входное использование использовалось, чтобы взять под свой контроль операционные системы, данные кражи, повредить диски пользователей и т.д., Одно такое использование даже привыкло к “iPhone” повреждения тюрьмы.

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

Условия состязания

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

Для получения дополнительной информации об условиях состязания и как предотвратить их, считайте Условия состязания и Защитите Операции Файла.

Межпроцессное взаимодействие

Отдельные процессы — или в единственной программе или в двух различных программах — иногда должны делиться информацией. Общие методы включают общую память использования или использование некоторого обменивающегося сообщениями протокола, такого как Сокеты, предоставленные операционной системой. Эти протоколы обмена сообщениями, используемые для межпроцессного взаимодействия, часто уязвимы для атаки; таким образом, при записи приложения, необходимо всегда предполагать, что процесс в другом конце канала передачи мог быть враждебным.

Для получения дополнительной информации о том, как выполнить безопасное межпроцессное взаимодействие, считайте Ввод Проверки и Межпроцессное взаимодействие.

Небезопасные операции файла

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

Примеры небезопасных операций файла включают:

Эти и другие небезопасные операции файла обсуждены более подробно в Обеспечении Операций Файла.

Проблемы управления доступом

Управление доступом является процессом управления, кому разрешают сделать что. Это колеблется от управления физическим доступом к компьютеру — хранения Ваших серверов в заблокированной комнате, например — к указанию, у кого есть доступ к ресурсу (файл, например) и что им позволяют сделать с тем ресурсом (такой как только для чтения). Некоторые механизмы управления доступом осуществляются операционной системой, некоторыми отдельным приложением или сервером, некоторыми службой (такой как сетевой протокол) в использовании. Много уязвимостей системы обеспечения безопасности создаются небрежным или неправильным использованием средств управления доступом, или отказом использовать их вообще.

Большая часть обсуждения уязвимостей системы обеспечения безопасности в литературе безопасности программного обеспечения с точки зрения полномочий, и много использования вовлекают атакующего, так или иначе получающего больше полномочий, чем они должны иметь. Полномочия, также названные полномочиями, являются правами доступа, предоставленными операционной системой, управляя, кому разрешают считать и записать файлы, каталоги и атрибуты файлов и каталогов (таких как полномочия для файла), кто может выполнить программу, и кто может выполнить другие ограниченные операции, такие как доступ к устройствам и внесение изменений в конфигурацию сети. Полномочия файла и управление доступом в OS X обсуждены в Руководстве по программированию Файловой системы.

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

Много управления доступом осуществляется приложениями, которые могут потребовать, чтобы пользователь аутентифицировал прежде, чем предоставить авторизации выполнить работу. Аутентификация может включить запрос имени пользователя и пароля, использования смарт-карты, биометрического сканирования или некоторого другого метода. Если приложение вызывает интерфейс приложения OS X Authorization Services для аутентификации пользователя, это может автоматически использовать в своих интересах, какой бы ни метод аутентификации доступен в системе пользователя. Запись Вашего собственного кода аутентификации является менее безопасной альтернативой, поскольку это могло бы предоставить атакующему возможность использовать в своих интересах ошибки в Вашем коде для обхода механизма аутентификации, или это могло бы предложить меньше метода безопасной аутентификации, чем стандартный, используемый в системе. Авторизация и аутентификация описаны далее в Обзоре безопасности.

Цифровые сертификаты обычно используются — особенно по Интернету и с электронной почтой — чтобы аутентифицировать пользователей и серверы, зашифровать связь и снабдить цифровой подписью данные, чтобы гарантировать, что это не было повреждено и действительно создавалось объектом, которому пользователь верит для создания его. Неправильное или небрежное использование цифровых сертификатов может привести к уязвимостям системы обеспечения безопасности. Например, программа администрирования сервера, поставленная со стандартом, самоподписала сертификат с намерением, что системный администратор заменит его уникальным сертификатом. Однако многим системным администраторам не удалось предпринять этот шаг, так что в итоге атакующий мог дешифровать связь с сервером. [CVE-2004-0927]

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

Использование средств управления доступом в Вашей программе обсуждено более подробно в Подъемных Полномочиях Безопасно.

Безопасное хранение и шифрование

Когда данные хранятся, шифрование может использоваться для защиты секретов пользователя от других, или во время передачи данных или. (Проблема того, как защитить данные поставщика от того, чтобы быть скопированным или используемый без разрешения, не решена здесь.) OS X обеспечивает множество основанных на шифровании параметров безопасности, такой как

Список параметров безопасности в iOS включает

Каждая служба имеет надлежащее использование, и у каждого есть ограничения. Например, FileVault, шифрующий содержание корневого объема пользователя (в OS X v10.7 и позже) или корневой каталог (в более ранних версиях), является очень важным средством защиты для совместно используемых компьютеров или компьютеров, к которым атакующие могли бы получить физический доступ, такой как ноутбуки. Однако это не очень полезно для компьютеров, которые физически безопасны, но это могло бы подвергнуться нападению по сети, в то время как в использовании, потому что в этом случае корневой каталог находится в незашифрованном состоянии и угрозе, от незащищенных сетей или совместно используемых файлов. Кроме того, FileVault только так же безопасен как пароль, выбранный пользователем — если пользователь выбирает легко предполагаемый пароль или записывает его в легко найденном расположении, шифрование бесполезно.

Это - серьезная ошибка попытаться создать Ваш собственный метод шифрования или реализовать опубликованный алгоритм шифрования самостоятельно, если Вы уже не эксперт в поле. Чрезвычайно трудно записать безопасный, устойчивый код шифрования, генерирующий небьющийся шифрованный текст, и это - почти всегда уязвимость системы обеспечения безопасности для попытки. Для OS X при необходимости в криптографических службах вне предоставленных пользовательским интерфейсом OS X и интерфейсами высокоуровневого программирования можно использовать менеджера по Криптографическим службам CSSM с открытым исходным кодом. См. документацию, предоставленную код в системе защиты С открытым исходным кодом, в котором можно загрузить http://developer .apple.com/darwin/projects/security/. Для iOS разработка APIs должен предоставить все услуги, в которых Вы нуждаетесь.

Для получения дополнительной информации о OS X и средствах защиты iOS, считайте Аутентификацию, Авторизацию и Руководство по Полномочиям.

Социальная разработка

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

Например, в феврале 2005, крупная фирма, поддерживающая кредитную информацию, Номера социального страхования и другие персональные данные о фактически всех гражданах США, показала, что они обнародовали информацию о по крайней мере 150 000 человек мошенникам, изобразившим из себя законных бизнесменов. Согласно Gartner (www.gartner.com), фишинговые атаки стоят банкам США и компаниям по выпуску кредитных карт приблизительно $1,2 миллиардов в 2003, и это число увеличивается. Они оценивают, что между маем 2004 и маем 2005, приблизительно 1,2 миллиона пользователей компьютера в США понесли потери, вызванные фишингом.

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

Для большего уведомления относительно того, как разработать пользовательский интерфейс, улучшающий безопасность, посмотрите Безопасные пользовательские интерфейсы Разработки.