Security Issues, Models and Analysis

Мы почти закончили статью о классификации и анализе уязвимостей

Nightstalker — Mon, 27 Aug 2007 19:04:00 GMT

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

Оригинал:

Damian Hasse, Greg Wroblewski, Scott Lambert, Adel Abouchaev

Analyzing Exploitability of Crashes

Goal: after reading the article reader should be able to triage program crashes against possible security implications.

Introduction (~500 words)

How can you tell when a program crash is exploitable? The short answer is simple: treat every crash as exploitable and fix it! At the very least, it is a quality issue and it is often more expensive to perform the analysis necessary to determine exploitability than it is to fix the issue in the first place. Another thing to consider is that it is often cheaper to fix the issue before the product is released than after it has been shipped to customers. This article offers guidance on how to triage (analyze) program crashes against possible security implications with a focus on memory corruption to achieve arbitrary code execution or at the very least deny service. We will enumerate the common hardware and software exceptions you might encounter when looking at these types of issues.

Analyzing program failures of this sort in an effort to understand the security ramifications can be a complex and error-prone task. Several factors must be considered including the location of the buffer in memory, the possible targets for overwrite, the size of the overwrite, restrictions on the data that can be used during the overwrite, state of the runtime execution environment, and the ability to bypass any mitigation mechanisms in place. In a nutshell, you must understand the root cause of the failure in order to answer these questions thoroughly. To aid in your effort, this article attempts to offer some general guidelines you can use during such an investigation. It is important to keep in mind that these are just guidelines and that only a full root cause analysis can ensure that you have correctly diagnosed the crash as not being exploitable.[1]

[1] Remember that new or variations of existing attack techniques are being discovered all the time.

Перевод:

Дамиан Хассе, Грег Вроблевски, Скотт Ламберт, Адель Абушаев

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

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

Введение

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

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

About me & about us/ О себе и о нас

Nightstalker — Thu, 05 Jul 2007 18:27:00 GMT

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

Основным документом, регламентирующий процесс прохождения программным продуктом проверки на уязвимости, является Software Development Lifecycle (SDL). В нём указаны параметры без которых программному продукту будет указано на невозможность поступить в реализацию.

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

Детали о процессах и методах - в будущих статьях.

О чём будет идти речь в этом разделе?

Nightstalker — Wed, 04 Jul 2007 02:03:53 GMT

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