What is cve? common vulnerabilities and exposures explained

— CVSS Scores & Vulnerability Types

EXPLOIT

1. Удаленное выполнение кода. Бажный код содержится в файле /www/editor/tiny_mce/plugins/save_template/save_template.php (строки 8–18):

   Данные пользователя, передаваемые в функцию file_put_contents() через параметры $_POST и $_POST, никак не фильтруются. Таким образом, атакующий, который имеет аккаунт в системе, может записать произвольный код в файл с расширением php, если включена директива magic_quotes_gpc. Запрос, эксплутирующий эту уязвимость, выглядит так:

2. Загрузка произвольных файлов. Уязвимый код содержится в функции checkFile(), которая находится в файле /libraries/filesystem.class.php, строки 3143–3154 представлены на соответствующем рисунке. Метод FileSystemTree::uploadFile(), отвечающий за загрузку всех файлов, использует checkFile() для проверки расширения загружаемого файла. Она, в свою очередь, сравнивает расширение с элементами черного списка file_black_list, в число которых по умолчанию входят php, php3, jsp, asp, cgi, pl, exe, com, bat. Благодаря этому атакующий может запросто загрузить аватар с расширением php.

3. SQL-инъекция через оператор UPDATE. Рассмотрим код функции getUserTimeTarget(), которая находится в /libraries/tools.php: он представлен на соответствующей картинке. Эта функция парсит переданную ей ссылку и, если находит параметр package_ID, использует её значение как индекс в массиве $entity. Чтобы понять суть проблемы, заглянем в код /www/periodic_updater.php:

   Данные, содержащиеся в $_GET, передаются в функцию getUserTimeTarget(), а возвращаемое значение используется при последующем вызове функции eF_executeNew(). Таким образом, для внедрения произвольного SQL-выражения атакующий может запросить URL следующего вида:

   В последних версиях продукта данные берутся из переменной $_SERVER, что, в общем-то, никак не влияет на баг. Для успешной реализации атаки необходимо иметь аккаунт в системе.

4. Обход аутентификации и повышение привилегий. Уязвимый код находится в /www/index.php:

   Данные в $_COOKIE, используемые для создания нового объекта с помощью метода EfrontUserFactory::factory(), не фильтруются, благодаря чему можно обойти аутентификацию и повысить привилегии:

5. Внедрение произвольного PHP-кода. Уязвимый кусок кода находится в /www/student.php:

   Данные, находящиеся в $_GET или $_GET, не фильтруются перед созданием нового объекта EfrontCourse, что позволяет выполнить код, так как в процессе создания объекта вызывается функция eval():

Переполнение стека fprintf в WRT120N

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

Загружаем файл со списком доступных файлов в WRT120NПолный список доступных файлов в WRT120N

Как пишет автор уязвимости, часть файлов в этом списке не представляла ничего впечатляющего. Тем не менее был найден интересный файл , в котором обрабатывались данные от пользователя (код обработки представлен на скриншоте).

Код обработки в скрипте tmUnBlock.cgi

Нас интересует строка

Хоть уязвимым параметром и является POST-переменная , но ошибка находится в реализации функции fprintf. И если ты посмотришь на ее код, то очень удивишься :).

Реализация функции fprintf

Эта функция использует только 256 байт. Это означает, что полученный от пользователя параметр TMBLOCKURL переполнит буфер, если его размер будет больше, чем 246 () байт.

Отправим тестовый запрос и посмотрим значения регистров на скриншоте:

Значения регистров после переполнения буфера в WRT120N

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

Адрес, по которому находится пароль администратора устройства WRT120N

Пароль представлен как обычная строка, оканчивающаяся NULL-байтом, поэтому если мы запишем нулевой байт в начало этого адреса, то сможем авторизоваться на устройстве с пустым паролем. Нужно лишь сделать так, чтобы после всех наших действий система продолжила работать :).

Рассмотрим конец функции fprintf. Оба регистра $ra и $s0 восстанавливаются из стека — это означает, что мы можем их контролировать, когда переполним стек.

Конец функции fprintf

Далее был найден интересный участок кода по адресу 0x8031F634, что сохраняет четыре нулевых байта из регистра $zero в адрес, который хранится в регистре $s0:

Первая ROP-цепочка для эксплойта в WRT120N

Если мы используем переполнения fpritnf, чтобы вернуться к  и переписать $s0 с адресом пароля администратора (), тогда алгоритм работы кода получится таким:

• обнуляем пароль администратора;
• возвращаем адрес возврата, сохраненный в стеке (мы контролируем стек);
• добавляем 16 в указатель стека.

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

Если присмотреться к адресу в cgi_tmUnblock, куда fprintf должна вернуться, ты сможешь увидеть, что все делается для восстановления $ra, $s1 и $s0 из стека, затем возвращается, и к указателю стека добавляется 0x60:

Конец функции cgi_tmUnblock

Мы уже добавили 0x10 к указателю стека, поэтому можем найти вторую ROP-цепочку для восстановления соответствующих сохраненных значений для $ra, $s1 и $s0 из стека и добавить 0x50 к указателю стека, то есть такую, которая эффективно заменит концовку функции cgi_tmUnblock.

Был найден не совсем точно подходящий под наши нужды участок кода по адресу 0x803471B8.

Вторая ROP-цепочка для эксплойта в WRT120N

Эта цепочка добавляет только 0x10 к указателю стека, но это не проблема. Мы создаем несколько дополнительных кадров стека, который возвращается на себя пять раз. На пятой итерации оригинальные значения нужных регистров будут закинуты в стек и наша ROP-цепочка вернется к вызову из cgi_tmUnblock.

На сайте автора есть небольшой GIF-ролик, в котором он нарисовал весь процесс переполнения буфера, описанный выше.

EXPLOIT

В качестве эксплойта опять будем использовать Python-скрип, который отправит POST-запрос со следующим содержимым:

Исходник эксплойта ты также сможешь найти на сайте автора по указанной ссылке.

CVE in Use (Archived)

As the international industry standard for cybersecurity vulnerability identifiers, CVE Entries are included in numerous products and services and are the foundation of others.

NOTICE: This page has been archived and is no longer being maintained. While much of the information below remains valid, please use your preferred search engine to search for the most current examples of products, projects, etc., that incorporate CVE.

CVE Numbering Authorities (CNAs)

Community members such as OS and software vendors and projects, vulnerability researchers, national and industry CERTs, and bug bounty programs authorized to assign CVE IDs to new issues.

CVE Compatibility

Products and services can be made «CVE Compatible» by following the CVE Compatibility Guidelines. Numerous organizations from around the world already include CVE IDs in their capabilities, processes, products, services, etc.

Recommendation ITU-T X.1520 Common Vulnerabilities and Exposures (CVE)

CVE was adopted by the International Telecommunication Union’s (ITU-T) Cybersecurity Rapporteur Group’s as a part of its «Global Cybersecurity Information Exchange techniques (X.CYBEX)» by issuing the X.CVE recommendation above that is based upon CVE’s current Compatibility Requirements document, and any future changes to those will be reflected in subsequent updates to X.CVE

Common
Weakness Enumeration (CWE)

Open Vulnerability and Assessment Language (OVAL)

A standard for determining vulnerability and configuration issues on computer systems,
CVE IDs are the primary references for «OVAL Vulnerability Definitions,» which test systems for the presence of CVEs.

GOVERNMENT

U.S. National Vulnerability Database (NVD)

Launched by the
National Institute of Standards and Technology (NIST) in 2005, NVD provides a vulnerability database of enhanced CVE content that is fully synchronized with the CVE List, so any updates to CVE appear immediately in NVD.

NVD also provides advanced searching, a CVSS calculator for CVE IDs, and fix information for CVE IDs.

DISA Information Assurance Vulnerability Alerts

CVE Entries are mapped to the U.S. Defense Information System Agency’s (DISA) Information Assurance Vulnerability Alerts (IAVAs). DoD PKI Certificates are required to access the information. For details, contact DISA.

Security Content Automation Protocol (SCAP)

CVE is one of the existing standards the U.S. National
Institute of Standards and Technology’s (NIST) SCAP to enable automated
vulnerability management, measurement, and policy compliance evaluation.

U.S. Government Agencies

National Institute of Standards and Technology (NIST)
recommends use of CVE by U.S. agencies in two Special Publications: «800-51:
Use of the Common Vulnerabilities and Exposures (CVE) Vulnerability
Naming Scheme» in 2002 & «800-40: Procedures for Handling Security
Patches,&» which was initially released in 2002 and updated 2011.

DoD
Contracts

U.S. Defense Information Systems Agency (DISA) issued
Task Order 232 in June 2004 for information assurance applications for
the Department of Defense (DoD) that requires the use of products that
use CVE IDs.

Повышение привилегий в ядре linux / Уязвимость в эмуляции 32-х системных вызовов в 64-х битных версиях ядра linux

Эта замечательная уязвимость берет свое начало в недалеком 2007-м году, и под нее составлен документ CVE-2007-4573. Обнаружил баг польский хакер под псевдонимом cliph, он же Wojciech Purczynski (интересно как это произносится?). Уязвимость примечательна тем, что ей подвержены исключительно 64-е версии ядра linux, так как ошибка закралась в механизм совместимости 32-х системных вызовов. Рассмотрим кусок кода (из arch/x86_64/ia32/ia32entry.S), отвечающий за трансляцию 32-х битных системных вызовов в 64-е:

Как видно из листинга, сначала значение в регистре eax сравнивается с длиной таблицы системных вызовов, и если значение попадает в диапазон, вызывается IA32_ARG_FIXUP макрос. Этот макрос используется для выравнивания аргументов 64-битной платформы к регистрам 32-битной. Но если присмотреться повнимательнее к коду sysenter_do_call, видно, что для проверки сначала используется регистр eax, а для системного вызова уже rax! Тем самым, загружая в верхние 32 бита значения, отличные от нулевого, инструкция call передаст управление далеко за пределами системной таблицы!

Запатчили данную уязвимость путем добавления нового макроса LOAD_ARGS:

Однако в коммите за 24-е апреля 2008 года самую главную строчку удалили, тем самым заново внедрив уязвимость :).

В 2010-м году известный хакер Ben Hawkes, просматривая исходники ядра, к своему удивлению, обнаружил отсутствие валидации регистра eax. Забавный эксплоит со встроенным трояном опубликовали блекхеты из некой андеграунд команды под названием Ac1dB1tch3z. Они передали теплые слова поздравлений Ben Hawkes’у ;).

Удаленное выполнение кода в IBM Jazz Team Server

Один из компонентов IBM Jazz Team Server / Rational, который также доступен в Rational Focal Point и Rational CLM, подвержен атаке, которая позволяет злоумышленнику удаленно выполнить произвольный код. Уязвимы системы, включающие компонент, поддерживающий OSGi-контейнер, — к нему можно получить доступ без аутентификации через веб-сервер.

Атакующий, у которого будет доступ хотя бы на уровне HTTP-запросов к серверу с запущенным Rational Focal Point или Rational Requirements Manager, может исполнить произвольный Java-код на сервере с теми же правами, что и сама Java. Уязвимый компонент также используется в других различных программных решениях, описанных в официальномдокументе от IBM.

EXPLOIT

Архитектура, содержащая уязвимый компонент, реализует часть административных возможностей для комплекта Rational. Этот набор представляет собой несколько веб-доступных servlet endpoints, до одного из которых () можно добраться через HTTP по следующему пути:

Этот сервлет отвечает за подтверждение загрузки OSGi-набора и развертывание его внутри Equinox OSGi контейнера запущенного приложения.

OSGi-наборы содержат произвольный Java-код. Эта особенность открывает замечательные возможности для атакующего, нужно лишь создать правильный интерфейс (OSGi), предоставить соответствующие метаданные и загрузить их через HTTP POST запрос. В итоге мы сможем выполнить произвольный код на сервере с запущенным уязвимым продуктом!

Компонент  (весь представленный код декомпилировался из файла) выполняет набор операций Activator, который регистрирует Servlet endpoints.

Регистрирование сервлетов в `com.ibm.team.repository.provision.Activator`

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

Сервис по обработке HTTP-запросов

Функция  обрабатывает полученные ZIP-файлы: разархивирует их и, если метаданные правильные для данного OSGi-набора, устанавливает и запускает код.

Обработка полученных ZIP-файлов

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

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

Пример работы эксплойта для уязвимости в IBM Jazz Team Server

Эксплойт протестирован на Rational Focal Point в Apache Tomcat container под Linux (но он также успешно работает для Rational Requirements Manager и Focal Point на WebSphere). Выполнение команд производится с помощью

java.lang.Runtime.getRuntime().exec()

А сами команды отсылаются по HTTP-протоколу.

SOLUTION

Есть исправление от производителя. Также можно сделать фильтр с регулярным выражением для детектирования HTTP-запросов от других возможных эксплойтов для InstallServlet, ProvisionRestServlet и других компонентов.

Повышение привилегий в ядре Windows

Эта уязвимость наделала много шума в январе! Я даже помню, что новость об этой уязвимости проскакивала на mail.ru с заглавием «Обнаружена уязвимость в Windows 17-летней давности!». Атаке подвержены все 32-битные системы Windows, начиная от NT 4.0 и заканчивая «семеркой»! Ошибка заложена в специальном костыле ядра Windows, для поддержки старых 16-битных приложений, — эта подсистема называется NTVDM (NT Virtual DOS Mode). Обнаружил и опубликовал эксплоит небезызвестный хакер Tavis Ormandy из компании Google. Примечательно, что невозможность использования уязвимости лежала на нескольких предположениях/аксиомах, вот они:

1. Для установки VDM контекста требуется SeTcbPrivilege привилегия.
2. Код в пользовательском адресном пространстве (Ring 3 код) не может устанавливать произвольные значения в регистр селектора сегмента кода.
3. Код в пользовательском адресном пространстве не может сформировать trap frame.

И Tavis Ormandy с хакерской смекалкой обошел все эти предположения!

Первое предположение.Tavis реализовал следующую комбинацию. Для начала посылается запрос NTVMD-подсистеме, затем создается удаленный поток (посредством стандартной API функции CreateRemoteThread) в процессе csrss, который по умолчанию имеет данную привилегию.

Второе предположение.Регистр CPL (Current Privilege Level) обычно равен двум младшим байтам сегментных регистров cs и ss, однако есть исключение из этого правила, если процессор находится в режиме Virtual-8086. Реальный режим процессоров x86 использует сегментную схему адресации памяти, чтобы, используя 16 бит, иметь доступ к 20-му адресному пространству. Это достигается путем нехитрой формулы: (cs << 4) + (eip & 0xffff). Такая же формула используется для проецирования сегментированного адресного пространства в защищенное линейное адресное пространство в режиме Virtual-8086. Это развязывает руки атакующему, ведь так можно выставлять cs в любое значение!

Третье предположение.Возврат из режима ядра в пользовательский режим посредством инструкции iret — достаточно сложная операция. Достаточно взглянуть на данную инструкцию в документации от Intel — это 6 страниц микрокода, нагруженных IF-конструкциями. Возврат состоит из двух частей: Pre-commit и Post-commit. Одна исполняется с ядерными значениями сегментных селекторов, другая — со значением уже для ring 3. Используя контекст VDM, с помощью недокументированной функции NtVdmControl атакующий может создать фейковый контекст, что приведет к ошибке на pre-commit стадии и сформирует trap-frame.

Что же делать?

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

Например, отключить поддержку IPv6 там, где она не нужна (код поддержки IPv6 во всех сервисах относительно новый и еще недостаточно протестирован). Также неплохая идея пересобрать ядро только с нужными опциями (драйверами, протоколами, etc).

Во-вторых, нужно оперативно получать информацию о новых уязвимостях в используемом ПО: здесь отлично подойдут mailлисты используемого дистрибутива, RSS с багтраков (например, с securityfocus.com) и так далее.

В-третьих, получать обновления безопасности тоже хочется максимально быстро. Стоит рассмотреть возможность автоматической установки обновлений безопасности (на некритичном сервере, думаю, это оправданно, а вот на highload production-сервере я бы не рискнул).

В Debian (и его производных) автоматическая установка обновлений безопасности настраивается с помощью пакета unattended-upgrades.

В Fedora/CentOS — с помощью yum-updatesd или yum-cron. И, наконец, надо постараться максимально увеличить защиту своей ОС.

Тут все сильно зависит от области применения, но в большинстве случаев не помешает установка/настройка SELinux или AppArmor — они хоть и неэффективны при эксплуатации дыр в ядре или низкоуровневых системных компонентах, но достаточно полезны при компрометации какого-нибудь демона или пользовательского приложения. Повысить безопасность ядра и его «окружения» тоже можно: например, с помощью специальных патчей, самый известный из которых — grsecurity. Основной компонент grsecurity — PaX, специальный патч, ограничивающий доступ приложений к страницам памяти: сегмент данных программ в памяти помечается как недоступный для исполнения, а сегмент кода — как readonly. В придачу используется рандомизация памяти — при каждом запросе память выделяется из произвольных мест. Кроме PaX, grsecurity может предложить следующие основные дополнения:

• ролевой контроль доступа (RBAC);
• улучшение безопасности chroot путем наложения дополнительных ограничений — например, невозможность просмотреть процессы, запущенные извне chroot;
• опция, запрещающая непривилегированным пользователям запускать бинарники, не принадлежащие пользователю root или доступные на запись для всех;
• запрет на чтение некоторых файлов в /proc и запрет на выполнение dmesg и netstat от обычного пользователя;
• ограничение использования ссылок: запрет на создание жесткой ссылки на файл и на использование симлинка, если пользователь не является владельцем файла.

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

• внедрить PaX (или его часть);
• реализовать защитный механизм, запрещающий выполнение кода и операций записи для определенных частей модулей;
• ограничение доступа к элементам из /proc, позволяющим получить важную для атаки информацию (возможно, часть кода будет взята из grsecurity);
• контроль автозагрузки модулей;
• специальная метка, помечающая процесс как только 32- или 64-битный.

И многое другое. Весь список можно посмотреть в разделе «Roadmap — KernelHardening» на сайте https://wiki.ubuntu.com. Надеюсь, хотя бы часть из этого списка мы скоро сможем увидеть в ванильном ядре.