Привет, это Майкл,

В течение последних нескольких недель Мэтт Миллер (Matt Miller), Мэтт Томлинсон (Matt Thomlinson), Джон Лэмберт (John Lambert) и я работали над статьей, посвященной защите от атак, связанных с переполнением буфера, в операционных системах начиная с Windows Vista и Windows Server 2008. Хочу представить нашего нового блоггера, Мэтта Миллера, участника нашей команды исследователей в области информационной безопасности и разработки методов защиты от компьютерных атак (Security Research and Defense), написавшего отличную заметку, материалы которой легли в основу нашей совместной статьи.

Пожалуйста, Мэтт…

В блоге группы исследователей в области информационной безопасности и разработки методов защиты от компьютерных атак мы уже писали о преимуществах применения таких технологий снижения рисков, связанных с информационной безопасностью, как предотвращения выполнения команд из раздела данных (Data Execution Prevention – DEP) и использование случайным образом организованного адресного пространства (Address Space Layout Randomization – ASLR) [1,2]. Данные технологии наряду с такими как SEHOP, GS и т.д. созданы для того чтобы затруднить использование уязвимостей программного обеспечения. Популярность этих технологий привела к повышенному интересу сообщества исследователей в области информационной безопасности относительно разработки новых методов обхода защитных технологий [3]. Отслеживая новые результаты в этом направлении, мы продолжаем работу над повышением эффективности технологий снижения рисков информационной безопасности. Тем временем, независимые разработчики (Independent Software Vendors – ISV) могут быть уверены, что данные технологии максимально эффективны в текущей ситуации.

На практике, эффективность таких технологий снижения рисков информационной безопасности как DEP и ASLR в значительной мере зависит от того, насколько эта технология внедрена в процесс создания приложения. Неспособность полностью реализовать технологию снижения рисков в приложении делает его легкой добычей при осуществлении атаки с помощью эксплойта. В июне 2010 года Secunia распространила результаты исследования, в которых приводилась оценка применения независимыми разработчиками DEP и ASLR [4]. Исследование показало, что большинство из вошедших в исследование приложений не в полной мере используют преимущества этих технологий, что формирует почву для новых атак с помощью незакрытых уязвимостей.

В качестве примера можно рассмотреть эксплойт, который был написан для Adobe Reader’а (CVE-2010-2883), где основной уязвимостью была подключаемая библиотека DLL, в которой использование ASLR не было включено по умолчанию. Компания Adobe выполнила огромную работу по внедрению таких технологий, как ASLR, в большинстве используемых компонентов, но фактически наличие всего одной DLL с отключенным механизмом ASLR достаточно для появления серьезной уязвимости. Это справедливо и для других приложений, например, плагинов для Internet Explorer (Browser Helper Object – BHO) и объектов управления ActiveX с отключенным по умолчанию ASLR, которые в совокупности с какой-нибудь другой уязвимостью обозревателя Интернет могут позволить обойти систему защиты, основанную на ASLR. Эти примеры показывают, что внедрять технологии снижения рисков информационной безопасности нужно на 100%.

Как проверить настройки ASLR в приложении

Существует два основных способа проверить установки ASLR в приложении. Первый из них заключается в проверке того, что во всех запущенных в настоящий момент модулях EXE и DLL подключено использование ASLR. Посмотреть это можно с помощью утилиты Process Explorer с подключенной панелью для просмотра используемых библиотек DLL, где добавлен столбец «ASLR enabled» (ASLR подключен). На рисунке показан пример использования Process Explorer’а для обнаружения библиотеки jp2ssv.dll, в которой по умолчанию не используется ASLR, подключенной к Internet Explorer (значение столбца ASLR в соответствующей строчке пустое).

Process Explorer очень удобно использовать для получении информации о загруженных в текущий момент библиотеках DLL, но он не помогает определить библиотеки без ASLR, которые загружаются приложением в другое время. Эту информацию можно получить с помощью двоичного анализатора Microsoft BinScope. BinScope проверяет DLL и EXE файлы на диске на наличие специального флага (DYNAMICBASE), который должен быть установлен для использования ASLR. Далее приведен пример отчета создаваемого BinScope для библиотеки DLL с отключенным ASLR (nondynamicbase.dll) и библиотеки DLL, использующей эту технологию (dynamicbase.dll).

Советы независимым разработчикам

Для того чтобы помочь независимым разработчикам полностью использовать преимущества технологий обеспечения информационной безопасности, поддерживаемых Windows, мы опубликовали обновленный вариант руководства, которое объясняет как подключить такие технологии как DEP, ASLR и GS. Ознакомиться с руководством можно здесь:

https://msdn.microsoft.com/en-us/library/bb430720.aspx

Мы рекомендуем независимым разработчикам следовать руководству и, вообще говоря, мы включили его в Security Development Lifecycle (SDL). Также советуем обращаться по вопросам, связанным с внедрением технологий снижения рисков информационной безопасности, по адресу switech@microsoft.com.

Мэтт Миллер, MSEC Security Science

Оригинал статьи

На конкурс принимаются русскоязычные технические статьи и вебкасты, рассматривающие вопросы безопасности в продуктах Microsoft.

Три главных приза, ноутбуки IdeaPad S10-3-2R-B, будут присуждены победителям в следующих номинациях:

- Microsoft Forefront и TMG;

- Безопасность в продуктах Microsoft глазами пользователя – рекомендации пользователям для безопасной работы, самостоятельной настройке собственных компьютеров;

- Безопасность в продуктах Microsoft глазами IT-специалиста – рекомендации для технических специалистов, нацеленные на обеспечение безопасности серверных продуктов или рабочей среды пользователя.

Срок проведения конкурса с 5 апреля по 1 июля 2010 года. Итоги конкурса будут подведены до 15 июля.

Для участия в конкурсе необходимо отправить оформленную статью на адрес security2010@securitylab.ru

Подробности на securitylab и itband.

1. Новая документация: Упрощенное внедрение Microsoft SDL

2. Новая программа: SDL Pro Network, категория «Инструменты» и новые участники

3. Новый инструмент: MSF for Agile Software Development + SDL Process Template for VSTS 2008

Упрощенная документация SDL

Начнем с выпуска документации по упрощенному внедрению Microsoft SDL. Одно из самых распространенных заблуждений насчет SDL: чтобы внедрить цикл безопасной разработки, необходимо иметь организацию, сопоставимую по размерам с Microsoft. Другое заблуждение: SDL применимо только для языков и платформ Microsoft, и вам придется использовать другую методологию, если вы пишете код на Ruby под ОС X. Упрощенная документация SDL поможет устранить эти заблуждения и объяснит, как процесс SDL может быть применен при ограниченных ресурсах и на любой платформе. Эта документация обозначает минимальный набор требований, при которых верны главные атрибуты SDL, и тем самым предоставляет эффективную модель построения эффективного цикла безопасной разработки в любой организации.

SDL Pro Network: категория «Инструменты безопасности» и новые участники

Наш второй анонс – расширение сети SDL Pro Network и включение в нее новой категории членства – «Инструменты», которая дополнит существующие категории «Консультанты» и «Обучение». Организации, представляющие категорию «Инструменты», могут производить инструменты безопасности, такие как утилиты статистического анализа, фаззеры, утилиты динамического или бинарного анализа. Инструменты безопасности являются особо важной частью цикла SDL, и мы очень рады, что теперь есть новая категория Pro Network, которая поможет организациям использовать свои инструменты и время более эффективно.

Также мы объявляем, что сеть Pro Network расширяется, и в ее состав входят семь новых участников:

· Fortify (Член группы «Инструменты»)

· Veracode (Член группы «Инструменты»)

· Codenomicon (Член группы «Инструменты»)

· Booz-Allen Hamilton (Член группы «Консультанты»)

· Casaba Security (Член группы «Консультанты»)

· Consult2Comply (Член группы «Консультанты»)

· Safelight Security Advisors (Член группы «Обучение»)

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

MSF for Agile Software Development + SDL Process Template

Последний, но не менее важный анонс – выпуск первой публичной бета-версии новой MSF for Agile Software Development plus SDL Process Template for VSTS 2008 (MFS для методологии разработки Agile плюс шаблон процессов SDL для VSTS 2008), или, сокращенно, «MSF-A+SDL».Так же как и шаблон процессов SDL, который мы выпустили в прошлом году, этот шаблон помогает командам интегрировать безопасную методологию разработки непосредственно в среду разработки Visual Studio Team System. Тем не менее, MSF-A+SDL основан на новом процессе SDL-Agile. MSF-A+SDL снабжен также некоторыми совершенно новыми функциями из предложений к предыдущему шаблону процессов SDL:

· Автоматическая генерация рабочих элементов задач SDL при новых итерациях.

Если мы имеем дело с проектами Agile, которые могут существовать бесконечно долго (допустим, веб-приложение или облачный сервис без установленной «даты окончания»), то для проекта необходимо периодически заново выполнять требования SDL, как это и обозначено в SDL-Agile процессе. Шаблон MSF-A+SDL выполняет это и создает новые задачи безопасности для проекта всякий раз, когда пользователь добавляет новую итерацию.

· Автоматическая генерация рабочих элементов задач SDL для нового кода. В любой момент, когда новые проекты или веб-сайты Visual Studio подключены к репозитарию управления исходным кодом проектов MSF-A+SDL, шаблон сгенерирует новые требования SDL, соответствующие этому проекту. Например, если пользователь создает новый сайт на C#, то шаблон добавит такие требования, как отключение трассировки ASP.NET и подключение библиотеки AntiXss.

· Многое другое, о чем здесь будет скоро рассказано.

Если вы посетите конференцию Black Hat на этой неделе и захотите увидеть MSF-A+SDL своими глазами, то зайдите на выступление Брайана Салливана на тему «Безопасность в Agile, или как защитить приложения с использованием пятидневного цикла выпуска» в пятницу, 3 февраля в 1:45.

Вот несколько полезных ссылок на случай, если вы пропустили их в тексте:

Страница SDL Pro Network

Документация: упрощенное внедрение Microsoft SDL

MSF for Agile Software Development plus SDL Process Template for VSTS 2008 скачать бесплатно

Рады вам сообщить, появились обновленный технический центр для ИТ-специалистов на TechNet, новый технический центр для разработчиков на MSDN, обновленное «лицо Microsoft по безопасности» сайт Microsoft.com/rus/security.

Центр Безопасности для Разработчиков

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

Что нового

• Локализованная информация о Методологии Безопасной Разработки SDL
• Новый контент по Безопасности технологий
• Форум по вопросам Безопасности
• Блог на тему Разработки Безопасного ПО
• Новые доклады на TechDays.ru

Центр по Безопасности для ИТ-профессионалов

Что нового 

• Уведомления по безопасности
• Советы по безопасности
• Вопросы и ответы на форумах и в блогах безопасности
• Инструменты безопасности
• Видео на TechDays.ru

Обновленное «лицо Microsoft по безопасности»

Что нового

• Разделы посвященные обновлениям безопасности
• Рекомендации о защите от червей, вирусов и шпионского ПО
• Советы по выбору брандмауэра

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

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

Недавно на конференции в Берлине, Германия, Microsoft анонсировал два новых документа SDL

Рассмотрение вопросов безопасности для клиентских и облачных приложений (EN). Загрузите доклад команды SDL, в котором обсуждаются вопросы, касающиеся клиентских и облачных приложений, а также шаги, предпринимаемые компанией Microsoft для развития SDL при решении вопросов безопасности.

SDL 4.1a, расширенная версия, включающая процесс быстрой разработки (EN). Загрузите последнее руководство по SDL, включающее главу SDL для быстрой разработки, четкий подход, объединяющий быстрые методы и безопасность. Полное и, кроме того, гибкое руководство SDL для быстрой разработки включает в себя все требования SDL, предоставляя дополнительно руководство по их применению для очень коротких реализ циклов.

Давайте коротко остановимся на каждом из них.

Рассмотрение вопросов безопасности для клиентских и облачных приложений

В то время как производители вычислительной техники обсуждают облако как вычислительную среду, клиенты обеспокоены тем, каким образом будет обеспечена безопасность информации. По итогам проведенного в сентябре 2009 года онлайн опроса IT Pro’s около 51% опрошенных поставили безопасность и сохранность информации в качестве основной преграды для принятии решения об использовании облака.

При рассмотрение вопросов безопасности для клиентских и облачных приложений (EN) Microsoft рассматривает безопасность с точки зрения организации, которая может рассматировать размещение своих приложений в облаке.

Если вы собираетесь хранить ваше приложение в облаке, на высоком уровне, вы должны задаваться вопросами, касающимися двух основных вопросов безопасности:

· Требования и соответствия безопасности. Если у вас имеются требования, что должен сделать провайдер для того, чтобы обеспечить требуемый уровень безопасности вашего ПО при хранении в облаке? Что он сделал для обеспечения этих требований?

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

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

SDL для быстрой разработки

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

Внимание: Если вы ещё не знакомы с быстрой разработкой и хотели бы узнать больше, вы можете прочитать о ней на https://www.agilemanifesto.org. Wikipedia определяет её как:

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

Также примечательно, ранние методы Быстрой Разработки включают: Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, и Dynamic Systems Development Method (DSDM) (1995). После опубликования в 2001 году Agile Manifesto они стали относиться к Быстрым Методологиям.

В своем блоге по SDL Брайен Салливан даёт прекрасное описание подхода команды к задаче применения SDL требований и процессов, преобразовывая руководство в пригодную для быстрой разработки структуру, которая может быть гибко применена как к длительным, так и коротким проектам быстрой разработки. Вот короткий обзор его поста.

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

· Методы быстрой разработки не имеют четких фаз

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

Ввиду данных различий, SDL для быстрой разработки делит SDL (по требованиям) на три категории: требование для каждого быстрого шага, требования настолько важны, что они должны быть завершены при каждом повторении; единовременные требования, требования, которые должны быть завершены один раз за время всего проекта независимо от длительности проекта; и bucket требования, требования, которые необходимо регулярно завершать, но они не настолько важны, чтобы делать это при каждом повторении.

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

Для получения полного руководства по SDL для быстрой разработки загрузите SDL 4.1a, расширенная версия, включающая процесс Быстрой Разработки (EN) и прочтите новые разделы, касающиеся быстрой разработки.

Заключительные замечания

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

Эксперты Microsoft прокомментировали результаты этого исследования:

1.      Информация по вопросам уязвимости.

Как обстоят дела с уязвимостями в  IE8?

«Специалистам всегда было известно, что браузер Firefox имеет значительно больше уязвимостей чем IE. Для этого достаточно регулярно заходить на популярный сайт secunia.com, на котором публикуются подробные списки всех уязвимостей продуктов мировых производителей. Например, на конец 2008 года Firefox 2.0. имел 154 уязвимости, а IE 7. – 70. На конец июня 2009 Firefox 3. имел 81 уязвимость, а IE 8. – всего 8. А на 10 ноября 2009 Firefox 3. имеет 133 уязвимости, а IE 8. – всего 16! Так что «открытие» Cenzic никого из специалистов не удивляет», - комментирует Владимир Мамыкин, директор по информационной безопасности ООО "Майкрософт Рус".

Насколько быстро предоставляются решения для обеспечения безопасности Internet Explorer?

https://technet.microsoft.com/ru-ru/security/dd452420.aspx

Как обстоят дела с уязвимостями в целом в отрасли?

Согласно отчету Cenzic, в первом полугодии 2009 году общее количество уникальных уязвимостей, выявленных в отрасли, резко сократилось на 28,4% по сравнению со вторым полугодием 2008, однако 46% по-прежнему имеют достаточно высокую степень опасности.

В последнем Security Intelligence Report (отчет по информационной безопасности) отмечено продолжение тренда, указанного в предыдущей версии отчета, который заключается в росте обеспечения безопасности продуктов Microsoft. Это стало возможным благодаря концентрации усилий на данной теме на протяжении всего процесса разработки, развитию антивирусных программ и постоянной работе по обновлению продуктов. Так, в первом полугодии 2009 г. программное обеспечение Microsoft явилось источником 6 из 10 основных уязвимостей браузеров на компьютерах под управлением Windows XP, в то время как для Windows Vista аналогичный показатель равен 1. Многие атаки стали возможными только по причине своевременно неустановленных обновлений. Например, большинство атак на пакет офисных программ Microsoft Office в первом полугодии 2009 г. (55,5%) нанесли ущерб приложениям Office, которые в последний раз обновлялись между июлем 2003 г. и июнем 2004 г. Больше всех пострадали пользователи Office 2003, которые не установили ни одного пакета обновления или обновления для системы безопасности со времени выхода первоначальной версии Office 2003 в октябре 2003 года.

В России в первой половине 2009 года индекс проникновения вредоносного ПО (количество очищенных компьютеров на 1000) составил 15,5, что на 35% ниже по сравнению со вторым полугодием 2008 г., однако значительно превышает среднее значение по миру равное 8,7.

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

Согласно независимому исследованию эксперта по безопасности NSS Labs Internet Explorer 8 является самым безопасным браузером в плане защиты от воровства паролей (например, когда у пользователя воруют аккаунт на Вконтакте и дальше требуют деньги для возврата его назад) и загрузки шпионских программ (например, когда компьютер от вашего имени начинает рассылать порно спам) –

Подробно: https://www.microsoft.com/rus/news/issues/2009/08/ie8.mspx и  https://www.microsoft.com/rus/windows/internet-explorer/get-the-facts/mythbusting.aspx  (Миф № 2)

3.       О встроенных инструментах безопасности

В Internet Explorer 8 встроен умный SmartScreen Filter, защищающий пользователя от шпионских атак и фишинга. О результатах работы фильтра рассказывает Натан Маннинг, руководитель департамента Windows для потребителей Microsoft в России:  "Я рад сообщить, что SmartScreen фильтр в IE8 заблокировал более 70 миллионов угроз за первые 4 месяца с момента официального выхода Internet Explorer 8. Эти данные – яркий показатель ценности защиты, которую предоставляет SmartScreen фильтр, а также свидетельство того, насколько широко распространены атаки программ-шпионов в сети сегодня».

Информация о Microsoft

Основанная в 1975 году корпорация Microsoft является мировым лидером в производстве программного обеспечения, решений для управления бизнесом, предоставлении услуг и разработке Интернет - технологий для персональных компьютеров и серверов. Компания предлагает широкий спектр программных продуктов для делового и личного применения, призванных расширить возможности человека или компании за счет использования современного программного обеспечения в любое время, в любом месте и на любом устройстве.

С ноября 1992 года в России действует представительство Microsoft (с июля 2004 года – ООО «Майкрософт Рус»), в задачи которого входит продажа и продвижение программного обеспечения, развитие рынка информационных технологий, а также внедрение и локализация новейших технологий на территории России.

Дополнительную информацию о компании и продуктах Microsoft можно найти на веб-серверax Microsoft: https://www.microsoft.com/rus (рус. язык) и https://www.microsoft.com (англ. язык).

Microsoft, Internet Explorer, Windows, Windows 7 являются охраняемыми товарными знаками Microsoft Corporation в США и/или других странах. Другие названия продуктов и компаний, упоминаемые в данном документе, могут являться товарными знаками соответствующих владельцев.

Контактная информация:

Microsoft, 125252, Москва, а/я 70

Тел.: 7 (495) 967-85-85

Факс: 7 (495) 967-85-00

E-mail: russia@microsoft.com

Узнать и обсудить последние новости Microsoft представители прессы могут в официальном блоге компании – ms4press.ru.

Представители СМИ могут также получить дополнительную информацию в PRP Group - a Weber Shandwick Affiliate Company по адресу microsoft@prp.ru или по телефону (495) 937 3170.

Мы получили единичные отчеты, что некоторые пользователи сталкиваются с проблемами при попытке запуска утилиты MiniFuzz на платформах Windows Server2003 или Windows XP. Это известная ошибка, которая возникает из-за отсутствия нескольких ключей в системном реестре в Windows Server2003 и Windows XP, которые по умолчанию присутствуют в Vista и Server 2008. Мы опубликовали эту проблему на сайте загрузки, но я хочу дополнительно упомянуть про нее здесь.

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

Ошибка:

Ручное исправление ошибки:

Запустите командную строку и выполните следующий скрипт:

   1: REG add "HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting" 

   2: /f

   3: REG add "HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error 

   4: Reporting" /v DontShowUI /t REG_DWORD /d 1 

   5: REG add 

   6: "HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting" /v 

   7: ExcludedApplications /t REG_MULTI_SZ

Что мы предпринимаем?

Мы исправим данную ошибку и в будущем выпустим обновленную версию MiniFuzz.

Спасибо вам за использование MiniFuzz. Мы приносим свои извинения за это неудобство и надеемся, что после исправления данной ошибки вы начнете всегда тестировать свои программы при помощи MiniFuzz File Fuzzer!

Оригинал: https://blogs.msdn.com/sdl/archive/2009/09/25/known-issue-using-minifuzz-on-windows-xp-or-server2003.aspx

Перевод: Антон Зайцев

Microsoft Security Response Center (MSRC) выпустил два новых бюллетеня безопасности для передачи управляющей информации отдельно от передачи данных - MS09-034 и MS09-035, а также набор советов по информационной безопасности Security Advisory(973882) для устранения уязвимостей в библиотеке Microsoft Active Template Library (ATL). Я хотел бы объяснить, почему невозможно обнаружить эти ошибки с помощью схемы SDL.

Я всегда повторяю, что любая ошибка - это возможность узнать что-то новое и при необходимости применить это далее на практике. В этой статье будет рассказано в общих чертах об уязвимостях в ATL. О механизме глубоко эшалонированной защиты (defense-in-depth) , добавленном в Internet Explorer вместе с обновлением MS09-034 можно прочесть в статье Дэйва Росса на блоге Security Research & Defense.

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

Active Template Library - набор облегченных классов C++ , изначально созданный для более простой работы с COM-объектами. ATL с легкостью контролирует подсчет ссылок на объекты и справляется со стандартными задачами COM. Но библиотека ATL не ограничена COM-технологией, в ней есть классы для работы с интеллектуальными указателями(smart pointers), изображениями(images), системным реестром(registry), списками контроля доступа(ACLs) и много других возможностей.

Когда разработчик создает новый проект в Visual Studio, он может выбрать создание проекта ATL. В этом случае основные заголовки будут подключены автоматически.

Еще один ключевой момент состоит в том, что исходный код библиотеки ATL доступен для просмотра. В случае использования Visual Studio 2008 он находится в папке %ProgramFiles%\Microsoft Visual Studio 9.0\vc\atlmfc.

Теперь давайте перейдем к рассмотрению уязвимостей.

Уязвимость #1: Опечатка.

Это главная проблема элемента управления ActiveX MSVidCtl. Ошибка является модификацией уязвимости более старой версии ATL и встречается не в публичной версии кода ATL, а в версии с индивидуальным обновлением.

Справка. В чем отличия ActiveX и COM ?

Этот абзац вы можете пропустить, я добавил его лишь потому, что часто отвечаю на этот вопрос. Объектная модель компонентов COM - это бинарная спецификация, определяющая взаимодействие объектов. Объект ActiveX является объектом COM. Главное свойство объекта ActiveX - это возможность его использования в скриптовых языках. Эту функцию часто называют "автоматизацией". Объекты ActiveX используют интерфейс COM IDispatch, который позволяет машине сценариев принимать решения и вызывать методы объектов во время исполнения программы. Это называется динамическим связыванием.

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

   1:  

   2: __int64 cbSize;

   3: hr = pStream->Read((void*) &cbSize, sizeof(cbSize), NULL);

   4: BYTE *pbArray;

   5: HRESULT hr = SafeArrayAccessData(psa, reinterpret_cast<LPVOID 

   6: *>(&pbArray));

   7: hr = pStream->Read((void*)&pbArray, (ULONG)cbSize, NULL);

   8: Даю вам еще одну подсказку - это ошибка всего в одном символе.

   9: Сдаетесь? Посмотрите на последнюю строчку. Первый аргумент функции неверен, 

  10: должно быть:

  11: hr = pStream->Read((void*)pbArray, (ULONG)cbSize, NULL);

Лишний символ "&" в уязвимом коде дает возможность записать потенциально опасную информацию объема cbSize по адресу указателя на массив pbArray, вместо того чтобы поместить информацию в массив. А указатель находится в стеке. Таким образом, это уязвимость переполнения стека.

Это крайне сложно заметить это при обзоре кода, и это не отслеживается компилятором C/C++ из-за приведения типов (void*). Если же приведения типов убрать, то компилятор выдаст ошибку наподобие такой:

   1: C2664: '<function>' : cannot convert parameter 1 from 'BYTE **' to 'BYTE *'

Я крайне не люблю приведение типов в стиле C, т.к. оно совершенно небезопасно. Приведение типов С++ куда более безопасно несмотря на то, что оператор reinterpret_cast так же плох, как и приведение в стиле C.

Почему мы упустили данную уязвимость?

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

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

Устранение запрещенных API (Banned API Removal) не видит эту ошибку, так как в данном случае нет запрещенных API.

Некоторые средства защиты, такие как ASLR или DEP в Windows могут подействовать. Такой ответ покажется неопределенным, но я употребил слово "могут", так как ATL - это библиотека шаблонов исходного кода, которая используется при построении программ, и разработчики сами выбирают, применять эти средства защиты или нет. Владельцы Internet Explorer 8 на Windows Vista SP1 и выше защищены лучше, потому что ASLR и DEP у них активны по умолчанию.

Можно даже откомпилировать код с флагом /GS, но это не поможет. Так как в этой уязвимости нет локальных переменных для защиты, и соответственно, нет и подходящего stack cookie для отслеживания такой функции.

Уязвимость #2: Использование карт свойств ATL для создания экземпляра COM-объекта.

ATL дает объектам возможность очень просто сохранять свои свойства в поток байтов. В дальнейшем объект может перезаписать этот байтовый поток. ATL реализует эту функцию при помощи "карты свойств". Поток может быть составлен из серии кортежей. При использовании кортежей первые байты обозначают тип данных, и, основываясь на типе, размер данных (к примеру, n-байтовая строка [VT_BSTR]), а далее идут сами данные.

Если тип данных - VT_DISPATCH или VT_UNKNOWN, то элемент управления может быть уязвимым.

Уязвимый код есть в исходных данных библиотеки ATL, а именно в методе

   1: CComVariant::ReadFromStream()

Как мы это пропустили? Схема SDL не дает никаких указаний или рекомендаций по поводу использования карт свойств ATL, по сути, SDL дает мало инструкций по поводу COM-контейнеров, прежде всего из-за того, что их немного. Самый широко известный COM-контейнер - это Internet Explorer. Тем не менее мы призываем команды разработчиков использовать утилиты, чтобы определять свои безопасные для скриптинга(Safe-for-Scripting) и безопасные для создания экземпляра(Safe-for-Instantiation) управляющие элементы.

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

Какие меры мы предпринимаем?

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

Прежде всего, мы обновляем наши fuzz-утилиты для нахождения потоковых уязвимостей COM, и далее обновим схему SDL, чтобы разработчики проверяли fuzz-тестами все COM-объекты, написанные с использованием небезопасных интерфейсов (таких как IPersistStream*, IPersistStorage и др.)

Во вторых , мы предупредим разработчиков, чтобы они использовали только новые версии библиотеки ATL. Сейчас у нас существует требование "минимальный набор инструментов компилятора и компоновщика", но оно те указывает разработчикам, какую библиотеку ATL необходимо использовать. Это будет исправлено.

В заключение, я хотел бы заняться подробнее проблемами приведения типов. Поэтому в ближайшие несколько месяцев я просмотрю базы данных ошибок на предмет похожих проблем. Также я переговорю с различными специалистами статистического анализа и языка С/С++ в Майкрософт и за пределами для выяснения их догадок и соображений. Если у вас есть профессиональные соображения по поводу проблем приведения типов, можете высказывать их через этот блог!

Оригинал: https://blogs.msdn.com/sdl/archive/2009/07/28/atl-ms09-035-and-the-sdl.aspx

Перевод: Антон Зайцев]]> https://docs.microsoft.com/archive/blogs/security_ru/connected-information-security-framework-cisf-risk-tracker-version-1-0 Mon, 02 Nov 2009 22:08:11 GMT https://blogs.msdn.microsoft.com/security_ru/2009/11/02/connected-information-security-framework-cisf-risk-tracker-version-1-0/ Команда Microsoft Information Security Tools (IST) выпустила Connected Information Security Framework (CISF) , платформу разработки программного обеспечения, состоящую из прикладных программных интерфейсов (API) и многократно используемых компонентов, которые разработаны для "создания заказных решений информационной безопасности и управления рисками".В дополнение к данному релизу команда ITS выпустила первое пользовательское приложение, использующее CIFS - Risk Tracker version 1.0 , которое контролирует и отслеживает риски информационной безопасности. Узнайте больше о CIFS и приложении Risk Tracker - прочитайте статью "Announcing the Connected Information Security Framework (CISF) and Risk Tracker" в блоге старшего управляющего Microsoft Information Security Тодда Кутцке.

Диана Тальво -

Менеджер по повышению квалификации специалистов в области информационной безопасности

Microsoft Information Security

Перевод: Антон Зайцев

Оригинал: https://blogs.msdn.com/ace_team/archive/2009/09/16/introducing-the-connected-information-security-framework-cisf-and-risk-tracker-version-1-0.aspx

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

• MS09-050 - устраняет уязвимость в Microsoft Windows (KB 975517)
• MS09-051 - устраняет уязвимость в Windows Media (KB 975682)
• MS09-052 - устраняет уязвимость в Windows Media (KB 974112)
• MS09-053 - устраняет уязвимость в Internet Information Services (IIS) (KB 975254)
• MS09-054 - устраняет уязвимость в Internet Explorer (KB 974455)
• MS09-055 - устраняет уязвимость в Microsoft Windows (KB 973525)
• MS09-056 - устраняет уязвимость в Microsoft Windows (KB 974571)
• MS09-057 - устраняет уязвимость в Indexing Service (KB 969059)
• MS09-058 - устраняет уязвимость в Microsoft Windows (KB 971486)
• MS09-059 - устраняет уязвимость в Microsoft Windows (KB 975467)
• MS09-060 - устраняет уязвимость в Microsoft Office (KB 973965)
• MS09-061 - устраняет уязвимость в Microsoft .NET (KB 974378)
• MS09-062 - устраняет уязвимость в Microsoft Windows (KB 957488)

Как получить обновления

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

Если у вас не включена функция автоматического обновления, или же вы хотите проверить установлены обновления или нет, посмотрите в Microsoft Update.

Обновления системы безопасности также доступны на Microsoft Download Center. Вы можете найти их наиболее легко, делая поиск по ключевому слову “обновления безопасности”  и месяцу, когда было выпущено обновление.