The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

19.06.2017 20:23

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

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

Исследователи 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).

  1. Главная ссылка к новости (http://openwall.com/lists/oss-...)
  2. OpenNews: Обнаружена локальная root-уязвимость, затрагивающая все Linux-ядра 2.6.x
  3. OpenNews: В sudo устранена уязвимость, позволяющая переписать файл на системах с SELinux
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/46724-stack
Ключевые слова: stack, heap, security
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (67) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, Аноним (-), 21:54, 19/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А разве нельзя на уровне ОС выделять страницы памяти так, чтобы между соседними выделенными участками всегда находилась страница, при обращении к которой на чтение или запись, программа завершала бы работу?
     
     
  • 2.5, Аноним (-), 21:56, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • +15 +/
    Это и есть stack guard-page  про обход которой говориться в новости.
     
  • 2.6, Аноним (-), 21:56, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • –15 +/
    > А разве нельзя на уровне ОС выделять страницы памяти так, чтобы между
    > соседними выделенными участками всегда находилась страница, при обращении к которой на
    > чтение или запись, программа завершала бы работу?

    В мире управляемых языков таких проблем нет.

     
     
  • 3.10, Michael Shigorin (ok), 22:31, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > В мире управляемых языков таких проблем нет.

    Rust is 'memory safe' but has this same stack exhaustion issue.

     
     
  • 4.44, Soos (?), 11:06, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Rust не управляемый язык. Речь идёт о C#.
     
     
  • 5.76, pripolz (?), 18:35, 10/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Rust не управляемый язык. Речь идёт о C#.

    http://cdn3.meme.am/cache/images/folder526/600x600/16784526/you-cant-if-you-d

     
  • 3.11, Аноним (-), 22:36, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вот только ОСей на этих управляемых языках нету.
     
     
  • 4.24, Аноним (-), 23:43, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И в ближайшем будущем не будет, ибо ядро должно быть производительным. Может быть появятся, если придумают соответствующую аппаратную поддержку со стороны процессоров.
     
     
  • 5.28, Crazy Alex (ok), 02:31, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Уже пытались... Толку нет
     
     
  • 6.50, Аноним (-), 13:01, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Неудачники, не хватает гения.
     
  • 3.14, 123 (??), 22:41, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Стэка в упр коде вроде как по определению быть не может. Расплата в производительности.
     
  • 3.30, Аноним (-), 06:34, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Зато в виртуальных машинах таких языков ещё как есть.
     
     
  • 4.47, Аноним (-), 11:51, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Легче исправить в одной виртуальной машине, чем в миллионах проектов.
     
  • 3.75, pripolz (?), 18:34, 10/07/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    http://cdn3.meme.am/cache/images/folder526/600x600/16784526/you-cant-if-you-d
     

  • 1.9, Michael Shigorin (ok), 22:28, 19/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > CCVE-2017-1000366

    Предложил мелкую правку новости с учётом https://cve.basealt.ru/informatsiia-ob-uiazvimosti-cve-2017-1000366.html ;-)

     
     
  • 2.18, Wladmis (ok), 22:59, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А что за механизм защиты?
     
     
  • 3.42, boyarsh (ok), 10:24, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > А что за механизм защиты?

    commit b7a528c6ce72ee0350c5f51f76d0986aba7706b2
    Author: Dmitry V. Levin <ldv@altlinux.org>
    Date:   Mon Oct 20 11:06:36 2008 +0000

        owl-alt-sanitize-env
        
        Sanitize the environment in a paranoid way.

    Этот код, существующий в alt-овской glibc с 2001 года (и несколько меняющийся со временем), спасал ALT от множества CVE, которые реализовывались через передачу SUID-ным программам какой-нибудь дряни через окружение. Вот и в этот раз -- у атакующего нет возможности напихать в ENV достаточно мусора, чтоб перепрыгнуть stack guard page.


     
  • 3.45, Michael Shigorin (ok), 11:27, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > А что за механизм защиты?

    В дополнение к уже сказанному boyarsh@ цитирую ответ ldv@:

    ---
    Наша официальная позиция была следующей:
    "glibc: being maintainers and happy users of owl-alt-sanitize-env
    hardening patch
    http://git.altlinux.org/gears/g/glibc.git?p=glibc.git;a=commitdiff;h=496059f2
    that, in particular, makes LD_* and OUTPUT_CHARSET environment variables
    unavailable in case of __libc_enable_secure, we don't see any necessity
    to release a glibc update this time."

    См. тж. http://openwall.com/lists/oss-security/2017/06/19/8
    ---

     
  • 2.21, Аноним (-), 23:09, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Предложил мелкую правку новости с учётом https://cve.basealt.ru/informatsiia-ob-uiazvimosti-cve-2017-1000366.html
    > ;-)

    Как-то слишком голословно, что именно за защита?


    PS. Главное то не упомянули, что основная дыра CVE-2017-100036 в ALT присутствует и ещё не исправлена https://cve.basealt.ru/informatsiia-ob-uiazvimosti-cve-2017-1000364.html

     
     
  • 3.53, пох (?), 14:25, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Главное то не упомянули, что основная дыра CVE-2017-100036 в ALT присутствует

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

    (интересно, я правильно угадываю, что ценой +1 мегабайт к VSS _каждого_ запущенного в системе процесса? )

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

     
     
  • 4.55, добрый (?), 14:42, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Вероятно, env sanitizing гораздо более разумная подстраховка на этот случай. Поскольку
    > это именно то, что должнен был сделать, и не сделал, автор
    > программы.

    Если по уму, то это должны делать авторы libc, поскольку ld.so тоже использует переменные окружения, и в его коде уже находили и публиковали уязвимости. Лет 7 прошло, а воз и ныне там.

     
     
  • 5.57, пох (?), 15:23, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Если по уму, то это должны делать авторы libc

    автор либси - некто Ульрих Дрепер, известный своим клиническим вывихом мозгов. Очень смешно ожидать от него и его наследников интеграции этого патча десятилетней давности. А libc5, к сожалению, немного не стильно, модно и молодежно.

    Кстати, и что мешает нормально написать ld.so (далеко не архисложная программа) я тоже не знаю.

     
     
  • 6.60, Black_Angel_by (?), 15:50, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Уже давно пилят без Дреппера.
     
  • 6.62, Michael Shigorin (ok), 16:06, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Очень смешно ожидать от него и его наследников интеграции этого патча десятилетней
    > давности.

    Там сейчас сильно другая ситуация, но добиться консенсуса по чему-нить вроде http://sisyphus.ru/ru/srpm/Branch4/glibc/patches/31 (glibc-2.5-obsd-alt-strlcpy-strlcat.patch по состоянию на четвёртый альт, сейчас это где-то в гите) пока не получилось.

     
     
  • 7.64, пох (?), 16:36, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    тут я не уверен, что оно a) вообще нужно в libc (любое добавление кода ломает совместимость) b) все чисто с лицензией. Проблема явно может быть решена вне libc, отдельной libopenbsdgoodfeature.so

    btw, интересно, сложно ли сделать в ядре для suid-files аналог "link if owner match" - позволило бы перекрыть класс эксплойтов а-ля sudo (в которой и аналогичных бинарниках, по-моему, вообще имело бы смысл проверять собственное имячко, и сегфолтиться при любом его отличии от %PREFIX/sudo) - я вот не могу представить себе ситуации, когда легитимному пользователю понадобился бы линк на сетуиденый бинарь, хоть символический, хоть хард. (разьве что где-нибудь в треш-окрестностях user namespaces, но там пусть у их изобретателей голова болит)

     
     
  • 8.66, добрый (?), 17:16, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Если не в libc, то никак не в библиотеке, которая будет подгружаться уже после о... текст свёрнут, показать
     
     
  • 9.67, пох (?), 17:42, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    эта фича, в том виде в котором была обнаружена в rhel, не проверяет su gid биты ... текст свёрнут, показать
     
  • 9.68, пох (?), 17:50, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    это мы уже о другой фиче, ld so она перпендикулярна, просто новая функциональнос... текст свёрнут, показать
     

  • 1.12, Аноним (-), 22:38, 19/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Это просто ужас какой-то
     
  • 1.13, key (??), 22:41, 19/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я правильно понимаю что, стек можно определить двумя адресами - начало и конец.
    Также и с кучей(наверное можно обойдись только началом?).
    Почему нельзя просто проверять границы?
    if((operation == new and Addr < HeapStartAddr) or
    (operation == stack and StackStartAddr < Addr < StackEndAddr)
    ) cout << "Error";

    Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
    Объясните, а то для моих скудных познаний stack guard-page выглядит слишком костыльно.

     
     
  • 2.15, key (??), 22:43, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно же код неправильный - границы стека и кучи меняются. При выделении памяти надо проверять, что не заходим за чужой диапазон. Но суть вопроса остается.
     
  • 2.16, 123 (??), 22:48, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >>Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?

    Этим вроде как менеджер памяти ОС должен заниматься. Поэтому меньше должно быть.

     
     
  • 3.17, Аноним84701 (ok), 22:52, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >>>Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
    > Этим вроде как менеджер памяти ОС должен заниматься. Поэтому меньше должно быть.

    Оно по-любому меньше будет, потому как в первом случае проверка при каждой операции, а вот при использовании guard-page - только непосредственно при обращении к данному региону.


     
     
  • 4.20, 123 (??), 23:08, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >>только непосредственно при обращении к данному региону.

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

     
     
  • 5.22, Аноним84701 (ok), 23:14, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > "Обращение к региону" это выход push за пределы страницы?

    Ну да, а что?
    Я толком правда уже не помню, но вроде как прилетает pagefault-эксепшн со стороны железа (x86) при попытке чтения, записи и т.д. без соответсвующего флажка страницы.

     
  • 2.19, Аноним84701 (ok), 23:00, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
    > Объясните, а то для моих скудных познаний stack guard-page выглядит слишком костыльно.

    http://wiki.osdev.org/Paging
    Если вкратце, то проверки страниц проводятся так или иначе (причем, при каждом обращении программы к памяти -- взять ту же NX-фичу, которой уже лет эдак пятнадцать. Т.е. скорость проверки соответсвует потребностям)  и "guard" - это просто-напросто страница памяти без каких либо разрешений.
    [code]
         PROT_NONE       No permissions at all.
         PROT_READ       The pages can be read.
         PROT_WRITE      The pages can be written.
         PROT_EXEC       The pages can be executed[/code]
    И кончено, оно наамного быстрее костылей с проверками при каждой операции.
    Единственно, памяти "тратится" минимум PAGE_SIZE
    [code]
    getconf PAGE_SIZE                                                            
    4096
    [/code]
    и поэтому лепить для защиты стековых переменных/фрейма выходит вроде как все еще несколько накладно.


     
     
  • 3.32, Аноним (-), 06:58, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >[оверквотинг удален]
    >      PROT_EXEC      
    > The pages can be executed[/code]
    > И кончено, оно наамного быстрее костылей с проверками при каждой операции.
    > Единственно, памяти "тратится" минимум PAGE_SIZE
    > [code]
    > getconf PAGE_SIZE
    > 4096
    > [/code]
    > и поэтому лепить для защиты стековых переменных/фрейма выходит вроде как все еще
    > несколько накладно.

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

     
  • 2.46, Ordu (ok), 11:43, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?

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

    А вот указатель стека проверять -- это реально накладные расходы, потому что стек реально реализован через регистр rbp, который указывает на вершину стека, и приложение с ним может играть как угодно. Выделить память под новый стек из кучи и нацелить rbp туда, например. Есть даже готовые функции в libc для подобной игры с rbp: о них можно почитать в info libc 'Non-Local exits'.

    Большая часть софта не делает этого, оставляя всю работу со стеком компилятору. Но даже там проверки указателя стека могут оказаться накладным удовольствием. Указатель стека меняется при каждом вызове функции, при каждой инструкции push/pop, при каждом объявлении локальной переменной в C... И при этом компилятор, в общем-то, не знает границ стека, об этом наверное только компоновщик узнаёт, тот которые объектные файлы в готовый бинарь собирает. А может быть даже и он не знает, а уже динамический компоновщик устанавливает эти границы, когда грузит бинарь в память процесса. Но с этими тонкостями я не разбирался.

     
     
  • 3.48, Олег (??), 12:03, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    rbp указывает на начало фрейма функции, на вершину стека указывает rsp
     
     
  • 4.49, Ordu (ok), 12:22, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > rbp указывает на начало фрейма функции, на вершину стека указывает rsp

    Да, спасибо за поправку.

     

  • 1.23, Аноним (-), 23:40, 19/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня с -fstack-check localedef в glibc падает в сегфолт. Проверьте, так же у вас?
    2.24
     
     
  • 2.25, Аноним (-), 23:53, 19/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Известный баг
    https://bugs.gentoo.org/show_bug.cgi?id=608788
    https://sourceware.org/bugzilla/show_bug.cgi?id=21253
     
     
  • 3.26, Аноним (-), 00:15, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Благодарю, патчик самое то.
     

  • 1.27, A.Stahl (ok), 01:55, 20/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И эти же анонимы ржут по поводу Hurd. Ну ржите...
     
     
  • 2.29, Crazy Alex (ok), 02:34, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ну, подход "давайте смиримся с кривым кодом и просто распихаем по песочницам" нравится не всем. Так как создаёт больно уж много тормозов и неудобств.
     
  • 2.31, Аноним (-), 06:37, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > И эти же анонимы ржут по поводу Hurd. Ну ржите...

    И где твой Hurd? Почему, если он такой безопасный, его до сих пор не внедрили, а взяли почему-то Linux.

     
     
  • 3.35, PF (ok), 09:09, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Hurd не нужен корпорациям
     
     
  • 4.36, Аноним (-), 09:32, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А почему ?
     
  • 2.33, angra (ok), 07:46, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А чем бы помог Hurd в большинстве указанных случаев? Ну кроме того, что он на той стадии развития, когда о защитах вроде stack guard-page еще не думают, а значит подобные эксплоиты это оверкилл.
     
  • 2.34, Elhana (ok), 08:36, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Можно подумать, что с Hurd все эти проблемы в статье магическим образом решаются.
     
     
  • 3.37, Аноним (-), 09:32, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Там же микроядро ! Они магическим образом решает все проблемы.
     
  • 3.38, Tim (??), 09:33, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В Linux, по историческим причинам, используется плоская модель памяти, т.е. код, данные, куча и стек находятся в едином адресном пространстве. Вся защита строится на ограничении доступа записи к отдельным страницам и рандомизации размещения.

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

    Достаточно установить стековый регистр или регистр начала фрейма на валидный адрес и  "stack guard-page" ничем не поможет.

    В системах с сегментной организацией памяти таких проблем нет.

     
     
  • 4.43, yet another anonymous (?), 11:00, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В Linux, по историческим причинам, используется плоская модель памяти, ...
    > В системах с сегментной организацией памяти таких проблем нет.

    Не назовет ли автор действующие операционки с прогрессивной сегментной организацией? ;)

     
     
  • 5.51, Tim (??), 13:53, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Последняя была в IBM z series.

    Но общую тенденцию озвучил главный:

    Security people are often the black-and-white kind of people that I can't stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them.
    Torvalds, Linus (2008-07-15).

     
     
  • 6.52, Crazy Alex (ok), 14:18, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну так главный знает, что говорит. Потребности в безопасности - они у всех разные, начиная с полного отсутствия и заканчивая высями небесными. Поэтому первичным должно быть решение задач, а безопасность (с сопутствующими накладными расходами) - добавляться/убавляться по необходимости.
     
     
  • 7.59, Tim (??), 15:38, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Правильно. Никакой магии, простой компромис.
     
  • 4.54, добрый (?), 14:38, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Вот только в AMD64 от сегментации избавились, поспешно и неосмотрительно.
     
     
  • 5.61, Tim (??), 16:03, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    При переключении контекста задач, требуется подгрузить таблицу трансляции адресов для каждого сегмента. Это вызывает шоковую нагрузку на кэш процессора.

    В AMD64 шина адреса 48 бит, при этом, мнимальный размер страницы 4kB, т.е. отбрасываем 12 бит и получаем 2^36 записей в таблице трансляции. Это много, даже для иерархического представления MMU x86.

    Избавились поспешно, но осмотрительно. ;)

     
     
  • 6.65, добрый (?), 16:48, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > При переключении контекста задач, требуется подгрузить таблицу трансляции адресов для
    > каждого сегмента.

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

    > Это вызывает шоковую нагрузку на кэш процессора.

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

    > В AMD64 шина адреса 48 бит, при этом, мнимальный размер страницы 4kB,
    > т.е. отбрасываем 12 бит и получаем 2^36 записей в таблице трансляции.
    > Это много, даже для иерархического представления MMU x86.

    Это всё к делу совершенно не относится.

    > Избавились поспешно, но осмотрительно. ;)

    По совершенно другим причинам. Осмотрительно или не - спорить не вижу смысла.

     
     
  • 7.70, J.L. (?), 18:48, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> Избавились поспешно, но осмотрительно. ;)
    >По совершенно другим причинам.

    можно узнать по каким ? мне сильно не понятен этот вопрос и почему вообще отказались от сегментной модели памяти типа 486х ?

     
     
  • 8.72, добрый (?), 21:21, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Моральное устаревание На тот момент сегменты кода, данных и стека с разными адр... текст свёрнут, показать
     
     
  • 9.74, J.L. (?), 13:32, 22/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    и сейчас нет в современном процессоре механизма на запрет чтение запись исполнен... текст свёрнут, показать
     

  • 1.56, Аноним (-), 14:47, 20/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    rhel5 x64 подвержен ?
     
     
  • 2.58, пох (?), 15:28, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > rhel5 x64 подвержен ?

    судя по приехавшему сегодня патчу ведра - да.
    Патчей sudo, ld.so и всего прочего - вероятно, не дождетесь. А патч ведра защищает только от poc-эксплойтов квалиса, и то если повезло, а не от любых других.


     
     
  • 3.63, Аноним (-), 16:18, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    интересно, а сентос обновит или забьет ?
     
     
  • 4.69, пох (?), 17:52, 20/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > интересно, а сентос обновит или забьет ?

    а они разьве поддерживают пятую версию?

     

  • 1.73, Аноним (-), 13:12, 22/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Нужно реализовать аппаратную поддержку маркировки страниц как стек и куча с проверкой процессором, что адресации относительно rsp идут на страницу со стеком, а остальные - на страницы с кучей.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру