Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для разных ОС

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для разных ОС

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для разных ОС

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

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

Для защиты от подобных пересечений в ядре Linux и других ОС применяют технику "stack guard-page", суть которой в подстановке граничных страниц памяти, обращение к которым приводит к генерации исключения (page-fault). Защита была разработана в ответ на выявление в 2010 году уязвимости CVE-2010-2240 и основана на том, что обычно стек заполняется постепенно и при его переполнении будет осуществлён доступ к "stack guard-page", пишет opennet.ru.

Исследователи Qualys попытались выявить практические методы инициирования подобных столкновений и обхода защиты "stack guard-page", что им блестяще удалось - выявлено 20 уязвимостей, связанных с недоработками выделения памяти в стеке/куче ядра, libc и компонентов пространства пользователя, позволяющих обойти средства защиты от выхода за границы стека. Суть предложенного Qualys метода обхода "stack guard-page" заключается в том, что некоторые приложения позволяют заполнять стек не последовательно и поддерживают конструкции, дающие возможность пробросить указатель стека с большим смещением, что позволяет избежать попадания в "stack guard-page".

Предложенные методы атаки разделены на три базовые категории:

  • Столкновение стека с другой областью памяти: выделение памяти производится до тех пор, пока стек не достигнет другой области памяти или пока другая область памяти не достигнет стека;
  • Проброс минуя страницу защиты стека (stack guard-page): указатель стека перемещается из стека в другую область памяти, не касаясь страницы защиты стека;
  • Разбиение стека или другой области памяти: осуществляется перезапись стека содержимым другой области памяти или перезапись другой области памяти содержимым стека. В качестве другой области памяти может выступать куча, анонимный mmap(), доступный на запись/чтение сегмент ld.so или PIE (Position-Independent Executable).

Для демонстрации практических атак создано 15 рабочих прототипов эксплоитов, позволяющих повысить свои привилегии через манипуляции с различными приложениями в различных операционных системах (Debian, CenOS, Fedora, Ubuntu, OpenBSD, NetBSD, FreeBSD, Solaris). Среди опубликованных прототипов эксплоитов:

  • Локальная root-уязвимость в Exim, манипулирующая недоработкой (CVE-2017-1000369), из-за которой при обработке некоторых аргументов командой строки не выполняется корректное освобождение памяти. Воспользовавшись данной проблемой локальный атакующий может в сочетании с уязвимостью CVE-2017-1000376 в glibc организовать выполнение своего кода с правами root. Эксплоит протестирован в Debian GNU/Linux (i386);
  • Поднятие привилегий в системе через утилиту sudo. Для атаки используется сочетание уязвимостей в sudo (CVE-2017-1000367) и в Glibc (CVE-2017-1000366). Проблема в Glibc вызвана некорректной обработкой памяти, выделенной для переменных окружения в suid-программах. Работа эксплоита продемонстрирована в Debian, Ubuntu и CentOS (i386);
  • Ещё один эксплоит, позволяющий получить привилегии root через манипуляцию с утилитой sudo. Эксплоит примечателен работой в дистрибутивах с включенным SELinux;
  • Локальный root-эксплоит через манипуляцию с ld.so и большинством SUID-root программ (используются уязвимости в glibc CVE-2017-1000366 и ядре Linux CVE-2017-1000370). Работа эксплоита продемонстрирована в Debian, Fedora и CentOS (i386);
  • Локальный root-эксплоит через манипуляцию с ld.so и большинством SUID-root программ, собранных в режиме PIE (используется уязвимость в glibc CVE-2017-1000366 и другая уязвимость в ядре Linux CVE-2017-1000371). Работа эксплоита продемонстрирована в Debian, Fedora и Ubuntu (i386);
  • Локальный root-эксплоит против утилиты /bin/su (используется уязвимость в glibc CVE-2017-1000366 и уязвимость в ядре Linux CVE-2017-1000365). Работа эксплоита продемонстрирована в Debian (i386);
  • Концептуальный эксплоит для получения контроля за регистром eip через sudo на системах i386 с патчами grsecurity/PaX (CVE-2017-1000367, CVE-2017-1000366, CVE-2017-1000377);
  • Концептуальный эксплоит для получения контроля за указателем адреса возврата (rip) через манипуляции с Exim (CVE-2017-1000369) в окружении Debian (amd64);
  • Локальный root-эксплоит против ld.so и большинство SUID-root приложений (CVE-2017-1000366, CVE-2017-1000379). Работа эксплоита продемонстрирована в Debian, Ubuntu, Fedora и CentOS (amd64);
  • Концептуальный эксплоит для обхода защиты stack guard-page в OpenBSD через манипуляции с утилитой /usr/bin/at. Для атаки используются уязвимости в реализации stack guard-page (CVE-2017-1000372) и libc функции qsort (CVE-2017-1000373);
  • Концептуальный эксплоит для обхода защиты stack guard-page в NetBSD (CVE-2017-1000374, CVE-2017-1000375);
  • Концептуальный эксплоит для атаки в окружении FreeBSD и обхода защиты RLIMIT_STACK в setrlimit (CVE-2017-1000385);
  • Два концептуальных эксплоита для обхода защиты stack guard-page во FreeBSD (CVE-2017-1083, CVE-2017-1084);
  • Локальный root-эксплоит против /usr/bin/rsh в окружении Solaris 11 (CVE-2017-3630, CVE-2017-3629, CVE-2017-3631 CVE-2017-3631).

Для большинства вышеотмеченных уязвимостей уже доступны обновления от дистрибутивов (разработчики дистрибутивов были в закрытом порядке извещены о проблемах в середине мая и сегодня скоординировано выпустили обновления). В качестве общей меры для противодействия выявленным уязвимостям предлагается пересобрать все приложения и библиотеки в пространстве пользователя с использованием опции "-fstack-check" в GCC, которая добавляет защиту от перемещения указателя стека в другую область памяти, минуя stack guard-page. Но так как "-fstack-check" пока не всегда работает корректно, для защиты в краткосрочной перспективе предложено увеличить размер stack guard-page с применяемых ныне нескольких килобайт до как минимум 1 Мб, что существенно затруднит эксплуатацию. Также рекомендовано предоставить средства для произвольного изменения размера stack guard-page администратором (например, grsecurity/PaX предоставляет /proc/sys/vm/heap_stack_gap). 

Подарочная карта Apple обернулась блокировкой аккаунта на годы работы

Известный разработчик и автор технических книг, посвящённых Apple, Пэрис Баттфилд-Эддисон неожиданно оказался заблокирован в собственном Apple-аккаунте. Это произошло после попытки активировать подарочную карту Apple на $500, которую он купил у крупного и вполне легального ретейлера и собирался использовать для оплаты подписки iCloud+ с хранилищем на 6 ТБ.

Вместо этого — полный цифровой стоп. По словам Баттфилд-Эддисона, он лишился доступа ко всей своей личной и рабочей экосистеме Apple без объяснений и понятного механизма восстановления.

Ситуация выглядит особенно болезненно на фоне его почти 30-летних отношений с компанией: он писал книги по Objective-C и Swift, организовывал конференции и потратил на продукты и сервисы Apple десятки тысяч долларов.

История быстро разошлась по профильным медиа — от AppleInsider до The Register. Казалось бы, при таком внимании проблема должна была решиться оперативно. Представитель Apple действительно связался с разработчиком 14 декабря и пообещал перезвонить на следующий день. Но с тех пор прошло уже несколько дней — и тишина.

Судя по опубликованным деталям, Баттфилд-Эддисон не нарушал правил. Скорее всего, он столкнулся с типичной проблемой: подарочная карта могла быть скомпрометирована ещё до покупки. Apple сама признаёт, что Gift Card часто используются в мошеннических схемах, и рекомендует в таких случаях обращаться в поддержку. Именно это он и сделал — безрезультатно.

Сам кейс вызвал тревогу в сообществе. Если подобное может произойти с известным разработчиком, у которого есть медийная поддержка и контакты внутри Apple, то что говорить об обычных пользователях, у которых нет ни публичности, ни рычагов давления? Автоматические антифрод-системы есть у всех крупных техкомпаний — Apple, Google, Amazon — и они регулярно ошибаются, оставляя людей без доступа к критически важным аккаунтам.

На фоне этой истории в сообществе всё громче звучит простой совет: по возможности избегать Apple Gift Card. Даже если большая часть карт безопасна, риск нарваться на «токсичный» код слишком высок. Подарок может обернуться цифровой катастрофой — как для вас, так и для того, кому вы его вручили.

Чем закончится история Баттфилд-Эддисона, пока неизвестно.

RSS: Новости на портале Anti-Malware.ru