forum.opennet.ru - "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." (67)

"Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
Сообщение от opennews (??) on 19-Июн-17, 21:52
Компания Qualys раскрыла (https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt) результаты исследования, в рамках которого была изучена возможность эксплуатации уязвимостей, приводящих к пересечению содержимого стека и кучи. В частности, когда стек и куча размещаются смежно и прилегают друг к другу (область стека следует сразу за памятью, выделенную под кучу), то в условиях того, что куча растёт в сторону увеличения, а стек в сторону уменьшения не исключено возникновение ситуаций, когда содержимое переполненной кучи может оказаться в области стека или, наоборот, стек переписать область кучи. Исследователи Qualys попытались выявить практические методы возникновения подобных столкновений, что им блестяще удалось - выявлено 20 уязвимостей, связанных с недоработками выделения памяти в стеке/куче ядра, libc и компонентов пространства пользователя, и позволяющих обойти средства защиты от выхода за границы стека (stack stack guard-page). Для демонстрации практических атак создано 15 рабочих прототипов эксплоитов, позволяющих повысить свои привилегии через манипуляции с различными приложениями в различных операционных системах. Предложенные методы атаки разделены на три базовые категории: - Столкновение стека с другой областью памяти: выделение памяти производится до тех пор, пока стек не достигнет другой области памяти или пока другая область памяти не достигнет стека; - Проброс мимо страницы защиты стека (stack guard-page): указатель стека перемещается из стека в другую область памяти, без доступа к странице защиты стека, которая генерирует page-fault; - Разбиение стека или другой области памяти: осуществляется перезапись стека содержимым другой области памяти или перезапись другой области памяти содержимым стека. В качестве другой области памяти может выступать куча, анонимный mmap(), доступный на запись/чтение сегмент ld.so или PIE (Position-Independent Executable). Среди опубликованных прототипов эксплоитов: - Локальная root-уязвимость в Exim, манипулирующая недоработкой (CVE-2017-1000369 (https://security-tracker.debian.org/tracker/CVE-2017-1000369)), из-за которой при обработке некоторых аргументов командой строки не выполняется корректное освобождение памяти. Воспользовавшись данной проблемой локальный атакующий может в сочетании с уязвимостью CVE-2017-1000376 (https://security-tracker.debian.org/tracker/CVE-2017-1000376) в glibc организовать выполнение своего кода с правами root. Эксплоит протестирован в Debian GNU/Linux (i386); - Поднятие привилегий в системе через утилиту sudo. Для атаки используется сочетание уязвимостей в sudo (CVE-2017-1000367 (https://security-tracker.debian.org/tracker/CVE-2017-1000367)) и в Glibc (CCVE-2017-1000366 (https://security-tracker.debian.org/tracker/CVE-2017-1000366)). Проблема в Glibc вызвана некорректной обработкой памяти, выделенной для переменных окружения в suid-программах. Работа эксплоита продемонстрирована в Debian, Ubuntu и CentOS (i386); - Ещё один эксплоит, позволяющий получить привилегии root через манипуляцию с утилитой sudo. Эксплоит примечателен работой в дистрибутивах с включенным SELinux; - Локальный root-эксплоит через манипуляцию с ld.so и большинством SUID-root программ (используются уязвимости в glibc CVE-2017-1000366 (https://security-tracker.debian.org/tracker/CVE-2017-1000366) и ядре Linux CVE-2017-1000370 (https://security-tracker.debian.org/tracker/CVE-2017-1000370)). Работа эксплоита продемонстрирована в Debian, Fedora и CentOS (i386); - Локальный root-эксплоит через манипуляцию с ld.so и большинством SUID-root программ, собранных в режиме PIE (используется уязвимость в glibc CVE-2017-1000366 (https://security-tracker.debian.org/tracker/CVE-2017-1000366) и другая уязвимость в ядре Linux CVE-2017-1000371 (https://security-tracker.debian.org/tracker/CVE-2017-1000371)). Работа эксплоита продемонстрирована в Debian, Fedora и Ubuntu (i386); - Локальный root-эксплоит против утилиты /bin/su (используется уязвимость в glibc CVE-2017-1000366 (https://security-tracker.debian.org/tracker/CVE-2017-1000366) и уязвимость в ядре Linux CVE-2017-1000365 (https://security-tracker.debian.org/tracker/CVE-2017-1000365)). Работа эксплоита продемонстрирована в Debian (i386); - Концептуальный эксплоит для получения контроля за регистром eip через sudo на системах i386 с патчами grsecurity/PaX (CVE-2017-1000367 (https://security-tracker.debian.org/tracker/CVE-2017-1000367), CVE-2017-1000366 (https://security-tracker.debian.org/tracker/CVE-2017-1000366), CVE-2017-1000377 (https://security-tracker.debian.org/tracker/CVE-2017-1000377)); - Концептуальный эксплоит для получения контроля за указателем адреса возврата (rip) через манипуляции с Exim (CVE-2017-1000369 (https://security-tracker.debian.org/tracker/CVE-2017-1000369)) в окружении Debian (amd64); - Локальный root-эксплоит против ld.so и большинство SUID-root приложений (CVE-2017-1000366 (https://security-tracker.debian.org/tracker/CVE-2017-1000366), CVE-2017-1000379 (https://security-tracker.debian.org/tracker/CVE-2017-1000379)). Работа эксплоита продемонстрирована в Debian, Ubuntu, Fedora и CentOS (amd64); - Концептуальный эксплоит для обхода защиты stack guard-page в OpenBSD через манипуляции с утилитой /usr/bin/at. Для атаки используются уязвимости в реализации stack guard-page (CVE-2017-1000372 (https://security-tracker.debian.org/tracker/CVE-2017-1000372)) и libc функции qsort (CVE-2017-1000373 (https://security-tracker.debian.org/tracker/CVE-2017-1000373)); - Концептуальный эксплоит для обхода защиты stack guard-page в NetBSD (CVE-2017-1000374 (https://security-tracker.debian.org/tracker/CVE-2017-1000374), CVE-2017-1000375 (https://security-tracker.debian.org/tracker/CVE-2017-1000375)); - Концептуальный эксплоит для атаки в окружении FreeBSD для обхода защиты RLIMIT_STACK в setrlimit (CVE-2017-1000385 (https://security-tracker.debian.org/tracker/CVE-2017-1000385)); - Для концептуальных эксплоита для обхода защиты stack guard-page во FreeBSD (CVE-2017-1083 (https://security-tracker.debian.org/tracker/CVE-2017-1000383), CVE-2017-1084 (https://security-tracker.debian.org/tracker/CVE-2017-1000384)); - Локальный root-эксплоит против /usr/bin/rsh в окружении Solaris 11 (CVE-2017-3630 (https://security-tracker.debian.org/tracker/CVE-2017-3630), CVE-2017-3629 (https://security-tracker.debian.org/tracker/CVE-2017-3629), CVE-2017-3631 CVE-2017-3631 (https://security-tracker.debian.org/tracker/)). Для большинства вышеотмеченных уязвимостей уже доступны обновления от дистрибутивов (разработчики дистрибутивов были в закрытом порядке извещены о проблемах в середине мая и сегодня скоординировано выпустили обновления). В качестве общей меры для противодействия выявленным уязвимостям предлагается пересобрать все приложения и библиотеки в пространстве пользователя с использованием опции-fstack-check" в GCC, которая добавляет защиту от перемещения указателя стека в другую область памяти минуя stack guard-page. Для защиты в краткосрочной перспективе можно увеличить размер stack guard-page как минимум до 1 Мб и предоставить средства для произвольного изменения данного размера администратором (например, grsecurity/PaX предоставляет /proc/sys/vm/heap_stack_gap). URL: http://openwall.com/lists/oss-security/2017/06/19/1 Новость: http://www.opennet.me/opennews/art.shtml?num=46724
Ответить \| Правка \| Cообщить модератору

Оглавление

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 21:54 , 19-Июн-17, (3)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 21:56 , 19-Июн-17, (5) +15
Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 21:56 , 19-Июн-17, (6) –15

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Michael Shigorin, 22:31 , 19-Июн-17, (10) +5

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Soos, 11:06 , 20-Июн-17, (44) +1

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., pripolz, 18:35 , 10-Июл-17, (76) –1

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 22:36 , 19-Июн-17, (11) +2

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 23:43 , 19-Июн-17, (24) +1

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Crazy Alex, 02:31 , 20-Июн-17, (28)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 13:01 , 20-Июн-17, (50) +1

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., 123, 22:41 , 19-Июн-17, (14)
Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 06:34 , 20-Июн-17, (30)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 11:51 , 20-Июн-17, (47)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., pripolz, 18:34 , 10-Июл-17, (75) –1

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Michael Shigorin, 22:28 , 19-Июн-17, (9)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Wladmis, 22:59 , 19-Июн-17, (18)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., boyarsh, 10:24 , 20-Июн-17, (42) +5
Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Michael Shigorin, 11:27 , 20-Июн-17, (45)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 23:09 , 19-Июн-17, (21)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., пох, 14:25 , 20-Июн-17, (53) +1

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., добрый, 14:42 , 20-Июн-17, (55)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., пох, 15:23 , 20-Июн-17, (57)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Black_Angel_by, 15:50 , 20-Июн-17, (60) +1
Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Michael Shigorin, 16:06 , 20-Июн-17, (62)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., пох, 16:36 , 20-Июн-17, (64)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., добрый, 17:16 , 20-Июн-17, (66)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., пох, 17:42 , 20-Июн-17, (67)
Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., пох, 17:50 , 20-Июн-17, (68)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 22:38 , 19-Июн-17, (12) +4
Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., key, 22:41 , 19-Июн-17, (13)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., key, 22:43 , 19-Июн-17, (15)
Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., 123, 22:48 , 19-Июн-17, (16)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним84701, 22:52 , 19-Июн-17, (17)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., 123, 23:08 , 19-Июн-17, (20)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним84701, 23:14 , 19-Июн-17, (22)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним84701, 23:00 , 19-Июн-17, (19)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 06:58 , 20-Июн-17, (32) +2

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Ordu, 11:43 , 20-Июн-17, (46) +2

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Олег, 12:03 , 20-Июн-17, (48) +2

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Ordu, 12:22 , 20-Июн-17, (49) +1

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 23:40 , 19-Июн-17, (23)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 23:53 , 19-Июн-17, (25) +1

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 00:15 , 20-Июн-17, (26)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., A.Stahl, 01:55 , 20-Июн-17, (27)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Crazy Alex, 02:34 , 20-Июн-17, (29) +4
Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 06:37 , 20-Июн-17, (31)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., PF, 09:09 , 20-Июн-17, (35)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 09:32 , 20-Июн-17, (36) +1

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., angra, 07:46 , 20-Июн-17, (33) +2
Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Elhana, 08:36 , 20-Июн-17, (34) +2

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 09:32 , 20-Июн-17, (37) +1
Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Tim, 09:33 , 20-Июн-17, (38) +2

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., yet another anonymous, 11:00 , 20-Июн-17, (43) +1

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Tim, 13:53 , 20-Июн-17, (51) +3

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Crazy Alex, 14:18 , 20-Июн-17, (52) +1

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Tim, 15:38 , 20-Июн-17, (59)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., добрый, 14:38 , 20-Июн-17, (54)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Tim, 16:03 , 20-Июн-17, (61) +1

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., добрый, 16:48 , 20-Июн-17, (65)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., J.L., 18:48 , 20-Июн-17, (70)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., добрый, 21:21 , 20-Июн-17, (72)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., J.L., 13:32 , 22-Июн-17, (74)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 14:47 , 20-Июн-17, (56)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., пох, 15:28 , 20-Июн-17, (58)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 16:18 , 20-Июн-17, (63)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., пох, 17:52 , 20-Июн-17, (69)

Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..., Аноним, 13:12 , 22-Июн-17, (73)

Сообщения по теме [Сортировка по времени | RSS]

3. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Аноним (??) on 19-Июн-17, 21:54

А разве нельзя на уровне ОС выделять страницы памяти так, чтобы между соседними выделенными участками всегда находилась страница, при обращении к которой на чтение или запись, программа завершала бы работу?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +15 +/–

Сообщение от Аноним (??) on 19-Июн-17, 21:56

Это и есть stack guard-page  про обход которой говориться в новости.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." –15 +/–

Сообщение от Аноним (??) on 19-Июн-17, 21:56

> А разве нельзя на уровне ОС выделять страницы памяти так, чтобы между
> соседними выделенными участками всегда находилась страница, при обращении к которой на
> чтение или запись, программа завершала бы работу?
В мире управляемых языков таких проблем нет.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

10. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +5 +/–

Сообщение от Michael Shigorin (ok) on 19-Июн-17, 22:31

> В мире управляемых языков таких проблем нет.
Rust is 'memory safe' but has this same stack exhaustion issue.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

44. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +1 +/–

Сообщение от Soos on 20-Июн-17, 11:06

Rust не управляемый язык. Речь идёт о C#.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

76. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." –1 +/–

Сообщение от pripolz on 10-Июл-17, 18:35

> Rust не управляемый язык. Речь идёт о C#.
http://cdn3.meme.am/cache/images/folder526/600x600/16784526/...

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

11. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +2 +/–

Сообщение от Аноним (??) on 19-Июн-17, 22:36

Вот только ОСей на этих управляемых языках нету.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

24. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +1 +/–

Сообщение от Аноним (??) on 19-Июн-17, 23:43

И в ближайшем будущем не будет, ибо ядро должно быть производительным. Может быть появятся, если придумают соответствующую аппаратную поддержку со стороны процессоров.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

28. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Crazy Alex (ok) on 20-Июн-17, 02:31

Уже пытались... Толку нет

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

50. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +1 +/–

Сообщение от Аноним (??) on 20-Июн-17, 13:01

Неудачники, не хватает гения.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

14. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от 123 (??) on 19-Июн-17, 22:41

Стэка в упр коде вроде как по определению быть не может. Расплата в производительности.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

30. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Аноним (??) on 20-Июн-17, 06:34

Зато в виртуальных машинах таких языков ещё как есть.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

47. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Аноним (??) on 20-Июн-17, 11:51

Легче исправить в одной виртуальной машине, чем в миллионах проектов.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

75. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." –1 +/–

Сообщение от pripolz on 10-Июл-17, 18:34

http://cdn3.meme.am/cache/images/folder526/600x600/16784526/...

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Michael Shigorin (ok) on 19-Июн-17, 22:28

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Wladmis (ok) on 19-Июн-17, 22:59

А что за механизм защиты?

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

42. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +5 +/–

Сообщение от boyarsh (ok) on 20-Июн-17, 10:24

> А что за механизм защиты?
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.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

45. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Michael Shigorin (ok) on 20-Июн-17, 11:27

> А что за механизм защиты?
В дополнение к уже сказанному 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=comm...
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
---

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

21. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Аноним (??) on 19-Июн-17, 23:09

> Предложил мелкую правку новости с учётом https://cve.basealt.ru/informatsiia-ob-uiazvimosti-cve-2017-...
> ;-)
Как-то слишком голословно, что именно за защита?

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

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

53. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +1 +/–

Сообщение от пох on 20-Июн-17, 14:25

> Главное то не упомянули, что основная дыра CVE-2017-100036 в ALT присутствует
это _не_ дыра.
Дыра - ошибка в коде программы, позволяющая, подсунув ей то, о чем не подумал автор, выполнить что-то непредусмотренное.
А этот CVE - просто доработка и без того крайне сомнительного и неэффективного механизма, который _иногда_, если погода летная, позволяет пользователям творения, написанного рукожопым программистом, не слишком дорого заплатить за эту рукожопость.
(интересно, я правильно угадываю, что ценой +1 мегабайт к VSS _каждого_ запущенного в системе процесса? )
Вероятно, env sanitizing гораздо более разумная подстраховка на этот случай. Поскольку это именно то, что должнен был сделать, и не сделал, автор программы.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

55. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от добрый on 20-Июн-17, 14:42

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

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

57. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от пох on 20-Июн-17, 15:23

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

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

60. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +1 +/–

Сообщение от Black_Angel_by on 20-Июн-17, 15:50

Уже давно пилят без Дреппера.

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

62. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Michael Shigorin (ok) on 20-Июн-17, 16:06

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

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

64. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от пох on 20-Июн-17, 16:36

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

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

66. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от добрый on 20-Июн-17, 17:16

> тут я не уверен, что оно a) вообще нужно в libc (любое
> добавление кода ломает совместимость) b) все чисто с лицензией. Проблема явно
> может быть решена вне libc, отдельной libopenbsdgoodfeature.so
Если не в libc, то никак не в библиотеке, которая будет подгружаться уже после обработки части переменных окружения в раннем коде ld.so, где уже были уязвимости: http://seclists.org/fulldisclosure/2010/Oct/257
> btw, интересно, сложно ли сделать в ядре для suid-files аналог "link if
> owner match" - позволило бы перекрыть класс эксплойтов а-ля sudo (в
fs.protected_hardlinks?

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

67. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от пох on 20-Июн-17, 17:42

> fs.protected_hardlinks?
эта фича, в том виде в котором была обнаружена в rhel, не проверяет su/gid биты (зато, зачем-то, write access) - и в таком виде, очевидно, небезвредная. В результате именно на системе с многими локальными пользователями рано или поздно тебе ее придется отключить.
с симлинками она вообще нечто непонятное делает (в смысле, непонятно, зачем такое нужно), совершенно не мешая сделать симлинк на sudo.
ненене, не надо нам такой уличной магии.

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

68. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от пох on 20-Июн-17, 17:50

> Если не в libc, то никак не в библиотеке, которая будет подгружаться
> уже после обработки части переменных окружения в раннем коде ld.so, где
это мы уже о другой фиче, ld.so она перпендикулярна, просто новая функциональность в libc, с тем же успехом могущая жить в любой другой (и статически слинкованной в том числе).
А если ее воткнуть в libc - первая же использующая эту фичу программа станет несовместима со всеми старыми системами.

> уже были уязвимости: http://seclists.org/fulldisclosure/2010/Oct/257
вот почему его до сих пор не переписали руками нормально - загадка, подумаешь, динамический линкер...

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

12. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +4 +/–

Сообщение от Аноним (??) on 19-Июн-17, 22:38

Это просто ужас какой-то

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от key (??) on 19-Июн-17, 22:41

Я правильно понимаю что, стек можно определить двумя адресами - начало и конец.
Также и с кучей(наверное можно обойдись только началом?).
Почему нельзя просто проверять границы?
if((operation == new and Addr < HeapStartAddr) or
(operation == stack and StackStartAddr < Addr < StackEndAddr)
) cout << "Error";
Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
Объясните, а то для моих скудных познаний stack guard-page выглядит слишком костыльно.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от key (??) on 19-Июн-17, 22:43

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

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

16. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от 123 (??) on 19-Июн-17, 22:48

>>Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
Этим вроде как менеджер памяти ОС должен заниматься. Поэтому меньше должно быть.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

17. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Аноним84701 (ok) on 19-Июн-17, 22:52

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

20. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от 123 (??) on 19-Июн-17, 23:08

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

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

22. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Аноним84701 (ok) on 19-Июн-17, 23:14

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

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

19. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Аноним84701 (ok) on 19-Июн-17, 23:00

> Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
> Объясните, а то для моих скудных познаний stack guard-page выглядит слишком костыльно.
http://wiki.osdev.org/Paging
Если вкратце, то проверки страниц проводятся так или иначе (причем, при каждом обращении программы к памяти -- взять ту же NX-фичу, которой уже лет эдак пятнадцать. Т.е. скорость проверки соответсвует потребностям)  и "guard" - это просто-напросто страница памяти без каких либо разрешений.

     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

И кончено, оно наамного быстрее костылей с проверками при каждой операции.
Единственно, памяти "тратится" минимум PAGE_SIZE

getconf PAGE_SIZE
4096

и поэтому лепить для защиты стековых переменных/фрейма выходит вроде как все еще несколько накладно.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

32. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +2 +/–

Сообщение от Аноним (??) on 20-Июн-17, 06:58

>[оверквотинг удален]
>      PROT_EXEC
> The pages can be executed
> И кончено, оно наамного быстрее костылей с проверками при каждой операции.
> Единственно, памяти "тратится" минимум PAGE_SIZE
>

> getconf PAGE_SIZE
> 4096
>

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

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

46. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +2 +/–

Сообщение от Ordu (ok) on 20-Июн-17, 11:43

> Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
Stack guard страница фактически не требует никаких накладных расходов, она один раз ядром помечается как недоступная для приложения, а потом процессор генерит исключение когда к ней происходит обращение. Процессор постоянно проверяет эти права, не только для охранной страницы, а для всех.
А вот указатель стека проверять -- это реально накладные расходы, потому что стек реально реализован через регистр rbp, который указывает на вершину стека, и приложение с ним может играть как угодно. Выделить память под новый стек из кучи и нацелить rbp туда, например. Есть даже готовые функции в libc для подобной игры с rbp: о них можно почитать в info libc 'Non-Local exits'.
Большая часть софта не делает этого, оставляя всю работу со стеком компилятору. Но даже там проверки указателя стека могут оказаться накладным удовольствием. Указатель стека меняется при каждом вызове функции, при каждой инструкции push/pop, при каждом объявлении локальной переменной в C... И при этом компилятор, в общем-то, не знает границ стека, об этом наверное только компоновщик узнаёт, тот которые объектные файлы в готовый бинарь собирает. А может быть даже и он не знает, а уже динамический компоновщик устанавливает эти границы, когда грузит бинарь в память процесса. Но с этими тонкостями я не разбирался.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

48. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +2 +/–

Сообщение от Олег (??) on 20-Июн-17, 12:03

rbp указывает на начало фрейма функции, на вершину стека указывает rsp

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

49. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +1 +/–

Сообщение от Ordu (ok) on 20-Июн-17, 12:22

> rbp указывает на начало фрейма функции, на вершину стека указывает rsp
Да, спасибо за поправку.

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

23. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Аноним (??) on 19-Июн-17, 23:40

У меня с -fstack-check localedef в glibc падает в сегфолт. Проверьте, так же у вас?
2.24

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

25. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +1 +/–

Сообщение от Аноним (??) on 19-Июн-17, 23:53

Известный баг
https://bugs.gentoo.org/show_bug.cgi?id=608788
https://sourceware.org/bugzilla/show_bug.cgi?id=21253

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

26. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Аноним (??) on 20-Июн-17, 00:15

Благодарю, патчик самое то.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

27. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от A.Stahl (ok) on 20-Июн-17, 01:55

И эти же анонимы ржут по поводу Hurd. Ну ржите...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

29. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +4 +/–

Сообщение от Crazy Alex (ok) on 20-Июн-17, 02:34

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

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

31. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Аноним (??) on 20-Июн-17, 06:37

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

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

35. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от PF (ok) on 20-Июн-17, 09:09

Hurd не нужен корпорациям

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

36. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +1 +/–

Сообщение от Аноним (??) on 20-Июн-17, 09:32

А почему ?

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

33. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +2 +/–

Сообщение от angra (ok) on 20-Июн-17, 07:46

А чем бы помог Hurd в большинстве указанных случаев? Ну кроме того, что он на той стадии развития, когда о защитах вроде stack guard-page еще не думают, а значит подобные эксплоиты это оверкилл.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

34. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +2 +/–

Сообщение от Elhana (ok) on 20-Июн-17, 08:36

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

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

37. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +1 +/–

Сообщение от Аноним (??) on 20-Июн-17, 09:32

Там же микроядро ! Они магическим образом решает все проблемы.

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

38. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +2 +/–

Сообщение от Tim (??) on 20-Июн-17, 09:33

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

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

43. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +1 +/–

Сообщение от yet another anonymous on 20-Июн-17, 11:00

> В Linux, по историческим причинам, используется плоская модель памяти, ...
> В системах с сегментной организацией памяти таких проблем нет.
Не назовет ли автор действующие операционки с прогрессивной сегментной организацией? ;)

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

51. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +3 +/–

Сообщение от Tim (??) on 20-Июн-17, 13:53

Последняя была в 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).

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

52. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +1 +/–

Сообщение от Crazy Alex (ok) on 20-Июн-17, 14:18

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

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

59. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Tim (??) on 20-Июн-17, 15:38

Правильно. Никакой магии, простой компромис.

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

54. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от добрый on 20-Июн-17, 14:38

Вот только в AMD64 от сегментации избавились, поспешно и неосмотрительно.

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

61. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +1 +/–

Сообщение от Tim (??) on 20-Июн-17, 16:03

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

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

65. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от добрый on 20-Июн-17, 16:48

> При переключении контекста задач, требуется подгрузить таблицу трансляции адресов для
> каждого сегмента.
Нет, не требуется. Страничные таблицы никогда не подгружаются в кэш заранее целиком.
> Это вызывает шоковую нагрузку на кэш процессора.
Нет, не вызывает. Единственная "шоковая" нагрузка - это сброс TLB, который при переключении контекста (не режима) происходит в любом случае, будь там хоть один сегмент, хоть несколько.
> В AMD64 шина адреса 48 бит, при этом, мнимальный размер страницы 4kB,
> т.е. отбрасываем 12 бит и получаем 2^36 записей в таблице трансляции.
> Это много, даже для иерархического представления MMU x86.
Это всё к делу совершенно не относится.
> Избавились поспешно, но осмотрительно. ;)
По совершенно другим причинам. Осмотрительно или не - спорить не вижу смысла.

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

70. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от J.L. on 20-Июн-17, 18:48

>> Избавились поспешно, но осмотрительно. ;)
>По совершенно другим причинам.
можно узнать по каким ? мне сильно не понятен этот вопрос и почему вообще отказались от сегментной модели памяти типа 486х ?

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

72. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от добрый on 20-Июн-17, 21:21

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

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

74. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от J.L. on 22-Июн-17, 13:32

>> можно узнать по каким ? мне сильно не понятен этот вопрос и
>> почему вообще отказались от сегментной модели памяти типа 486х ?
> Моральное устаревание. На тот момент сегменты кода, данных и стека с разными
> адресами базы нигде как самостоятельные не использовались и считались, как и
> сейчас, пережитком прошлого.
и сейчас нет в современном процессоре механизма на запрет чтение/запись/исполнение в зависимости от сегмента кода/аналога ?

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

56. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Аноним (??) on 20-Июн-17, 14:47

rhel5 x64 подвержен ?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

58. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от пох on 20-Июн-17, 15:28

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

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

63. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Аноним (??) on 20-Июн-17, 16:18

интересно, а сентос обновит или забьет ?

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

69. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от пох on 20-Июн-17, 17:52

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

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

73. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..." +/–

Сообщение от Аноним (??) on 22-Июн-17, 13:12

Нужно реализовать аппаратную поддержку маркировки страниц как стек и куча с проверкой процессором, что адресации относительно rsp идут на страницу со стеком, а остальные - на страницы с кучей.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

3. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
Сообщение от Аноним (??) on 19-Июн-17, 21:54
А разве нельзя на уровне ОС выделять страницы памяти так, чтобы между соседними выделенными участками всегда находилась страница, при обращении к которой на чтение или запись, программа завершала бы работу?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	5. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+15 +/–
	Сообщение от Аноним (??) on 19-Июн-17, 21:56
	Это и есть stack guard-page про обход которой говориться в новости.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	6. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	–15 +/–
	Сообщение от Аноним (??) on 19-Июн-17, 21:56
	> А разве нельзя на уровне ОС выделять страницы памяти так, чтобы между > соседними выделенными участками всегда находилась страница, при обращении к которой на > чтение или запись, программа завершала бы работу? В мире управляемых языков таких проблем нет.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	10. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+5 +/–
	Сообщение от Michael Shigorin (ok) on 19-Июн-17, 22:31
	> В мире управляемых языков таких проблем нет. Rust is 'memory safe' but has this same stack exhaustion issue.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	44. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+1 +/–
	Сообщение от Soos on 20-Июн-17, 11:06
	Rust не управляемый язык. Речь идёт о C#.
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	76. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	–1 +/–
	Сообщение от pripolz on 10-Июл-17, 18:35
	> Rust не управляемый язык. Речь идёт о C#. http://cdn3.meme.am/cache/images/folder526/600x600/16784526/...
	Ответить \| Правка \| ^ к родителю #44 \| Наверх \| Cообщить модератору


	11. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+2 +/–
	Сообщение от Аноним (??) on 19-Июн-17, 22:36
	Вот только ОСей на этих управляемых языках нету.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	24. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+1 +/–
	Сообщение от Аноним (??) on 19-Июн-17, 23:43
	И в ближайшем будущем не будет, ибо ядро должно быть производительным. Может быть появятся, если придумают соответствующую аппаратную поддержку со стороны процессоров.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	28. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
	Сообщение от Crazy Alex (ok) on 20-Июн-17, 02:31
	Уже пытались... Толку нет
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	50. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+1 +/–
	Сообщение от Аноним (??) on 20-Июн-17, 13:01
	Неудачники, не хватает гения.
	Ответить \| Правка \| ^ к родителю #28 \| Наверх \| Cообщить модератору


	14. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
	Сообщение от 123 (??) on 19-Июн-17, 22:41
	Стэка в упр коде вроде как по определению быть не может. Расплата в производительности.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	30. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
	Сообщение от Аноним (??) on 20-Июн-17, 06:34
	Зато в виртуальных машинах таких языков ещё как есть.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	47. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
	Сообщение от Аноним (??) on 20-Июн-17, 11:51
	Легче исправить в одной виртуальной машине, чем в миллионах проектов.
	Ответить \| Правка \| ^ к родителю #30 \| Наверх \| Cообщить модератору


	75. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	–1 +/–
	Сообщение от pripolz on 10-Июл-17, 18:34
	http://cdn3.meme.am/cache/images/folder526/600x600/16784526/...
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору

9. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
Сообщение от Michael Shigorin (ok) on 19-Июн-17, 22:28
> CCVE-2017-1000366 Предложил мелкую правку новости с учётом https://cve.basealt.ru/informatsiia-ob-uiazvimosti-cve-2017-... ;-)
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	18. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
	Сообщение от Wladmis (ok) on 19-Июн-17, 22:59
	А что за механизм защиты?
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	42. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+5 +/–
	Сообщение от boyarsh (ok) on 20-Июн-17, 10:24
	> А что за механизм защиты? 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.
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	45. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
	Сообщение от Michael Shigorin (ok) on 20-Июн-17, 11:27
	> А что за механизм защиты? В дополнение к уже сказанному 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=comm... 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 ---
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	21. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
	Сообщение от Аноним (??) on 19-Июн-17, 23:09
	> Предложил мелкую правку новости с учётом https://cve.basealt.ru/informatsiia-ob-uiazvimosti-cve-2017-... > ;-) Как-то слишком голословно, что именно за защита? PS. Главное то не упомянули, что основная дыра CVE-2017-100036 в ALT присутствует и ещё не исправлена https://cve.basealt.ru/informatsiia-ob-uiazvimosti-cve-2017-...
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	53. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+1 +/–
	Сообщение от пох on 20-Июн-17, 14:25
	> Главное то не упомянули, что основная дыра CVE-2017-100036 в ALT присутствует это _не_ дыра. Дыра - ошибка в коде программы, позволяющая, подсунув ей то, о чем не подумал автор, выполнить что-то непредусмотренное. А этот CVE - просто доработка и без того крайне сомнительного и неэффективного механизма, который _иногда_, если погода летная, позволяет пользователям творения, написанного рукожопым программистом, не слишком дорого заплатить за эту рукожопость. (интересно, я правильно угадываю, что ценой +1 мегабайт к VSS _каждого_ запущенного в системе процесса? ) Вероятно, env sanitizing гораздо более разумная подстраховка на этот случай. Поскольку это именно то, что должнен был сделать, и не сделал, автор программы.
	Ответить \| Правка \| ^ к родителю #21 \| Наверх \| Cообщить модератору


	55. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
	Сообщение от добрый on 20-Июн-17, 14:42
	> Вероятно, env sanitizing гораздо более разумная подстраховка на этот случай. Поскольку > это именно то, что должнен был сделать, и не сделал, автор > программы. Если по уму, то это должны делать авторы libc, поскольку ld.so тоже использует переменные окружения, и в его коде уже находили и публиковали уязвимости. Лет 7 прошло, а воз и ныне там.
	Ответить \| Правка \| ^ к родителю #53 \| Наверх \| Cообщить модератору


	57. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
	Сообщение от пох on 20-Июн-17, 15:23
	> Если по уму, то это должны делать авторы libc автор либси - некто Ульрих Дрепер, известный своим клиническим вывихом мозгов. Очень смешно ожидать от него и его наследников интеграции этого патча десятилетней давности. А libc5, к сожалению, немного не стильно, модно и молодежно. Кстати, и что мешает нормально написать ld.so (далеко не архисложная программа) я тоже не знаю.
	Ответить \| Правка \| ^ к родителю #55 \| Наверх \| Cообщить модератору


	60. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+1 +/–
	Сообщение от Black_Angel_by on 20-Июн-17, 15:50
	Уже давно пилят без Дреппера.
	Ответить \| Правка \| ^ к родителю #57 \| Наверх \| Cообщить модератору


	62. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
	Сообщение от Michael Shigorin (ok) on 20-Июн-17, 16:06
	> Очень смешно ожидать от него и его наследников интеграции этого патча десятилетней > давности. Там сейчас сильно другая ситуация, но добиться консенсуса по чему-нить вроде http://sisyphus.ru/ru/srpm/Branch4/glibc/patches/31 (glibc-2.5-obsd-alt-strlcpy-strlcat.patch по состоянию на четвёртый альт, сейчас это где-то в гите) пока не получилось.
	Ответить \| Правка \| ^ к родителю #57 \| Наверх \| Cообщить модератору


	64. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
	Сообщение от пох on 20-Июн-17, 16:36
	тут я не уверен, что оно a) вообще нужно в libc (любое добавление кода ломает совместимость) b) все чисто с лицензией. Проблема явно может быть решена вне libc, отдельной libopenbsdgoodfeature.so btw, интересно, сложно ли сделать в ядре для suid-files аналог "link if owner match" - позволило бы перекрыть класс эксплойтов а-ля sudo (в которой и аналогичных бинарниках, по-моему, вообще имело бы смысл проверять собственное имячко, и сегфолтиться при любом его отличии от %PREFIX/sudo) - я вот не могу представить себе ситуации, когда легитимному пользователю понадобился бы линк на сетуиденый бинарь, хоть символический, хоть хард. (разьве что где-нибудь в треш-окрестностях user namespaces, но там пусть у их изобретателей голова болит)
	Ответить \| Правка \| ^ к родителю #62 \| Наверх \| Cообщить модератору


	66. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
	Сообщение от добрый on 20-Июн-17, 17:16
	> тут я не уверен, что оно a) вообще нужно в libc (любое > добавление кода ломает совместимость) b) все чисто с лицензией. Проблема явно > может быть решена вне libc, отдельной libopenbsdgoodfeature.so Если не в libc, то никак не в библиотеке, которая будет подгружаться уже после обработки части переменных окружения в раннем коде ld.so, где уже были уязвимости: http://seclists.org/fulldisclosure/2010/Oct/257 > btw, интересно, сложно ли сделать в ядре для suid-files аналог "link if > owner match" - позволило бы перекрыть класс эксплойтов а-ля sudo (в fs.protected_hardlinks?
	Ответить \| Правка \| ^ к родителю #64 \| Наверх \| Cообщить модератору


	67. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
	Сообщение от пох on 20-Июн-17, 17:42
	> fs.protected_hardlinks? эта фича, в том виде в котором была обнаружена в rhel, не проверяет su/gid биты (зато, зачем-то, write access) - и в таком виде, очевидно, небезвредная. В результате именно на системе с многими локальными пользователями рано или поздно тебе ее придется отключить. с симлинками она вообще нечто непонятное делает (в смысле, непонятно, зачем такое нужно), совершенно не мешая сделать симлинк на sudo. ненене, не надо нам такой уличной магии.
	Ответить \| Правка \| ^ к родителю #66 \| Наверх \| Cообщить модератору


	68. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
	Сообщение от пох on 20-Июн-17, 17:50
	> Если не в libc, то никак не в библиотеке, которая будет подгружаться > уже после обработки части переменных окружения в раннем коде ld.so, где это мы уже о другой фиче, ld.so она перпендикулярна, просто новая функциональность в libc, с тем же успехом могущая жить в любой другой (и статически слинкованной в том числе). А если ее воткнуть в libc - первая же использующая эту фичу программа станет несовместима со всеми старыми системами. > уже были уязвимости: http://seclists.org/fulldisclosure/2010/Oct/257 вот почему его до сих пор не переписали руками нормально - загадка, подумаешь, динамический линкер...
	Ответить \| Правка \| ^ к родителю #66 \| Наверх \| Cообщить модератору

12. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+4 +/–
Сообщение от Аноним (??) on 19-Июн-17, 22:38
Это просто ужас какой-то
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору

13. "Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для р..."	+/–
Сообщение от key (??) on 19-Июн-17, 22:41
Я правильно понимаю что, стек можно определить двумя адресами - начало и конец. Также и с кучей(наверное можно обойдись только началом?). Почему нельзя просто проверять границы? if((operation == new and Addr < HeapStartAddr) or (operation == stack and StackStartAddr < Addr < StackEndAddr) ) cout << "Error"; Там же неверняка накладные расходы на реализацию защищенной страницы не меньше? Объясните, а то для моих скудных познаний stack guard-page выглядит слишком костыльно.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору