The OpenNET Project / Index page

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



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

"Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от opennews (??) on 12-Янв-18, 23:39 
В стандартной библиотеке Glibc выявлена (https://www.halfdog.net/Security/2017/LibcRealpathBufferUnde.../) уязвимость (CVE-2018-1000001 (https://security-tracker.debian.org/tracker/CVE-2018-1000001)), вызванная переполнением через нижнюю границу буфера в функции realpath(), проявляющимся при возврате относительного пути системным вызовом getcwd(). Изначально  ядро Linux возвращало в getcwd() только абсолютные пути, но затем в ядре 2.6.36 поведение было изменено, но функции Glibc не были адаптированы на обработку относительных путей.


Относительные пути возвращаются при достаточно редкой ситуации, когда процесс не меняет текущую директорию после выполнения вызова chroot и путь к корню оказывается вне области текущего дерева каталогов. Начиная с ядра Linux 2.6.36 начальная часть такого пути заменяется на строку "(unreachable)". Непривилегированный пользователь  может добиться аналогичного эффекта сменив текущую директорию процесса  на путь в другом пространстве имён. Так как в Glibc не производится проверка на спецстроку "(unreachable)", то атакующий может создать каталог "(unreachable)" и использовать его как начало относительного пути. Манипулируя ссылками на предыдущие каталоги при помощи элементов пути "/..//" можно добиться смещения указателя на область до начала выделенного буфера и переписать область памяти перед буфером содержимым части пути.


Выявившие уязвимость исследователи подготовили рабочий прототип эксплоита, позволяющий поднять свои привилегии до прав root через манипуляцию с исполняемыми файлами с флагом suid root, в которых вызывается функция realpath(). В эксплоите используется утилита /sbin/unmount, которая вызывает realpath() в коде инициализации локали, выполняемом до сброса привилегий. Для инициирования появления относительного пути в эксплоите используется пространство имён идентификаторов пользователя, т.е. атака возможна только при активации поддержки "user namespaces" (sysctl kernel.unprivileged_userns_clone=1). Работа эксплоита продемонстрирована в  Debian Stretch на системе с архитектурой amd64.


Обновление пакетов с устранением уязвимости уже выпущено для SUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2018-1000001) и openSUSE (https://lists.opensuse.org/opensuse-security-announce/2018-0...). Исправление пока недоступно для Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2...), Debian (https://security-tracker.debian.org/tracker/CVE-2018-1000001), Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1533837) и RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1000001).

URL: http://seclists.org/oss-sec/2018/q1/38
Новость: http://www.opennet.ru/opennews/art.shtml?num=47894

Ответить | Правка | Cообщить модератору

Оглавление

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


1. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +13 +/
Сообщение от Аноним (??) on 12-Янв-18, 23:39 
Мне нравится этот красивый номер уязвимости.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от Багтрекер on 12-Янв-18, 23:54 
CVE-2018-1000000 топчик
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

49. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +2 +/
Сообщение от pavlinux (ok) on 13-Янв-18, 17:09 
Да что ж такое-то,  Meltdown/Spectre не работают, тут опять подстава...

# sysctl kernel.unprivileged_userns_clone
sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directory

# zcat /proc/config.gz | grep USER_NS
CONFIG_USER_NS=y

# uname -srm
Linux 4.14.1+ x86_64


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

75. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от Аноним (??) on 16-Янв-18, 23:36 
Подстава случилась тогда когда придумали относительные пути, со всякими .. и проч :). На этом столько серверов погорело. И до сих пор наивные чукотские юноши не знают что ремота может .. прислать. Кто угодно тырит /etc/passwd в результате. Да и остальное.
Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

2. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +4 +/
Сообщение от Аноним (??) on 12-Янв-18, 23:45 
> user namespaces

Ну почему каждая третья уязвимость связана с *этим*?

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

10. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +4 +/
Сообщение от ы on 13-Янв-18, 01:26 
С напряжением ждём уязвимости /dev/null
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

33. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от ХипстерСпам on 13-Янв-18, 12:32 
При обращении к /dev/null можно задудосить и без того багнутый Meltdown камень
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

13. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +4 +/
Сообщение от EHLO on 13-Янв-18, 02:29 
>> user namespaces
> Ну почему каждая третья уязвимость связана с *этим*?

Хайпонули немножечко, бывает. Отключил, если вдруг не отключено по дефолту и забыл года на три про *это*. А там либо допилят, либо прикопают.

Больше должно напрягать, что последние несколько декад каждое второе поднятие привилегий связано с

>через манипуляцию с исполняемыми файлами с флагом suid root

И почти никто не шевелится их выпиливать из дистрибутивов

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

23. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от backbone (ok) on 13-Янв-18, 08:46 
Первый раз отключил в августе '12-го года, что за уязвимость была не вспомню, но с тех пор # CONFIG_USER_NS is not set
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

53. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от Аноним (??) on 13-Янв-18, 19:04 
Ну и как, контейнеры работают?
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

55. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от backbone (ok) on 13-Янв-18, 19:15 
> Ну и как, контейнеры работают?

Нет, а должны?

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

25. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +1 +/
Сообщение от Andrey Mitrofanov on 13-Янв-18, 09:55 
>>> user namespaces
>> Ну почему каждая третья уязвимость связана с *этим*?
> Хайпонули немножечко,
> Больше должно напрягать, что последние несколько декад каждое второе
>>через манипуляцию с исполняемыми файлами с флагом suid root
> И почти никто не шевелится их выпиливать из дистрибутивов

Они шевелятся, ты не понял. Они готовят user namespaces на царствование.

Когда "каждое второе" будет через userns -- король умер, да здравствует король.

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

6. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +1 +/
Сообщение от минонА on 13-Янв-18, 00:13 
Всем срочно переходить на musl?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

31. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от Аноним (??) on 13-Янв-18, 12:23 
там пользователей из ад нету, как мы будем деньги микрософту платить?
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

54. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +1 +/
Сообщение от Аноним (??) on 13-Янв-18, 19:09 
Можно подумать, в прочих либцах совсем нет уязвимостей.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

76. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от Аноним (??) on 16-Янв-18, 23:48 
> Всем срочно переходить на musl?

В нем тоже CVE случаются. Переходить надо на другой глобус, где програмисты не ошибаются.

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

8. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +2 +/
Сообщение от ыы on 13-Янв-18, 00:47 
полный опасносте мирок стандартных библиотек :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –4 +/
Сообщение от Анонимчик on 13-Янв-18, 03:04 
Полон опасностей Си-мирок: то буфера переполнятся, то стеки слетают, то длину строк проверить забудут. В общем, тысяча и один способ накосячить трудноуловимо и критически.

Писали бы на managed-языках - таких проблем by-design бы не было бы.

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

15. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +17 +/
Сообщение от Crazy Alex (??) on 13-Янв-18, 03:36 
Правда, тупило бы непредсказуемо, память жрало и имело бы свои классы ошибок -- на managed языках как-то быстро расслабляются, с управлением ресурсами в особенности, забывая, что ресурсы - это далеко не только память.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

29. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от iZEN email(ok) on 13-Янв-18, 11:13 
Для Apple Lisa и Apple IIe большая часть программ написана на Pascal (Apple ObjectPascal уже тогда был, кажется). Недавно измеряли скорость ответной реакции системы на внешнее воздействие - 30-60 миллисекунд. Для примера ещё взяли современные смартфоны с операционными системами, написанными на C/C++,Java - скорость ответной реакции от 250 до 800 миллисекунд. Делайте выводы.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

34. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +1 +/
Сообщение от h31 (ok) on 13-Янв-18, 12:38 
Всё переврали.
Там речь шла про скорость отклика в консольке. В Apple IIe она была чуть ли не аппаратно реализована, поэтому такое маленькое время отклика.
И никаких 800 мс я не вижу. В районе 100 на нормальных компьютерах и 120-130 на смартфонах. Это нормально, с учётом того, как работает тачскрин. https://danluu.com/input-lag/
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

37. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +1 +/
Сообщение от Адекват (ok) on 13-Янв-18, 14:52 
> И никаких 800 мс я не вижу. В районе 100 на нормальных
> компьютерах и 120-130 на смартфонах. Это нормально, с учётом того, как
> работает тачскрин. https://danluu.com/input-lag/

Это все галимая теория, в реальных условиях, у пользователя на его смартфоне за 4000р запущенно несколько программок в фоне, и телефону нужно продуматься, просто при выходе из VK.

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

56. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +2 +/
Сообщение от Аноним (??) on 13-Янв-18, 19:17 
>,Java - скорость ответной реакции от 250 до 800 миллисекунд

Пчёлы (iZEN) против мёда! ;)

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

60. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –5 +/
Сообщение от iZEN (ok) on 13-Янв-18, 20:54 
>>,Java - скорость ответной реакции от 250 до 800 миллисекунд
> Пчёлы (iZEN) против мёда! ;)

В Android нет Java. Как язык высокого уровня используется, а как бинарный код - нет той JVM и среды исполнения, чтобы считать это Java.


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

73. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от _ (??) on 16-Янв-18, 17:22 
Ты Мастер разбирающийся в сортах(Tm)!
Остальным пох, жаба она и в дройдах - жаба! :-р
И она такое же Г как и на пизюках.
Не - ну очередные "склад-магазины" клепать - самое оно! Хуже жабы - лучше нет! Но системное что то на ней лепить ... надо быть iZEN-ом на всю голову :-Р
Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

74. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от iZEN (ok) on 16-Янв-18, 21:03 
> Ты Мастер разбирающийся в сортах(Tm)!
> Остальным пох, жаба она и в дройдах - жаба! :-р
> И она такое же Г как и на пизюках.
> Не - ну очередные "склад-магазины" клепать - самое оно! Хуже жабы -
> лучше нет! Но системное что то на ней лепить ... надо
> быть iZEN-ом на всю голову :-Р

А вот интересно, как вы разделяете, Oracle Access Manager системное или несистемное ПО?


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

78. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от Аноним (??) on 17-Янв-18, 18:05 
Java может и нет. А тормозное памятежручее г@вно - есть. Так какая разница?

P.S. Если что-то пишется - как жаба,тормозит - как жаба, память жрет - как жаба и глючит - как жаба, то это жаба и есть!

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

79. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от iZEN (ok) on 17-Янв-18, 18:34 
> Java может и нет. А тормозное памятежручее г@вно - есть. Так какая
> разница?
> P.S. Если что-то пишется - как жаба,тормозит - как жаба, память жрет
> - как жаба и глючит - как жаба, то это жаба
> и есть!

JVM написана на C++. Ничего уж тут не поделаешь.


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

63. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +5 +/
Сообщение от Led (ok) on 13-Янв-18, 22:51 
> Pascal
> скорость ответной реакции системы на внешнее воздействие - 30-60 миллисекунд.
> Java - скорость ответной реакции от 250 до 800 миллисекунд. Делайте выводы.

Выводы: Java - г-но.


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

35. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –2 +/
Сообщение от RobotsCantPoop on 13-Янв-18, 14:37 
Ну да, а то на C/CPP софт не тупит, не течёт, сжирая гигабайты, и не падает. Ну ваще-ваще.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

41. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –1 +/
Сообщение от RobotsCantPoop on 13-Янв-18, 15:14 
Ну да, а в C/CPP не расслабляются, прям так всё качественно контролируют, что софт на сях не тупит, не падает, не течёт сжирая гигабайты и уязвимостям ну ваще не подвержен.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

67. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –1 +/
Сообщение от RobotsCantPoop on 14-Янв-18, 13:26 
> Правда, тупило бы непредсказуемо, память жрало

Хипстота не в курсе существования нормальных языков и концептов. Неудивительно.

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

70. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +1 +/
Сообщение от щи on 15-Янв-18, 10:37 
Фантастика на уровне "АйФак 10". В вашей реальности хипстота на C пишет.
Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

17. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +3 +/
Сообщение от Аноним (??) on 13-Янв-18, 06:32 
>Писали бы на managed-языках - таких проблем by-design бы не было бы.

Ты внимательно читал описание бага? Ну допустим это был бы С++ и getcwd() возвращала бы std::string("(unreachable)"). Исправило ли бы это проблему? Нет! Просто это было идиотское архитектурное решение, ломающее обратную совместимость.

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

18. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –2 +/
Сообщение от Анонимчик on 13-Янв-18, 07:18 
Это слишком сложно для меня. Я пишу на питоне совсем не что умен, а потому что проще. Зато у меня нет проблем с переполнением буферов.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

26. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +8 +/
Сообщение от QuAzI (ok) on 13-Янв-18, 10:06 
Ты хотел сказать, что ещё не дорос до проектов, на которых нужны настолько сложные вещи, что и переполнение буфера будет вылезать?
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

32. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +1 +/
Сообщение от Hellraiser email(??) on 13-Янв-18, 12:27 
наводящий вопрос - а на чём написан интерпретатор байт-кода питона?
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

39. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –1 +/
Сообщение от iZEN (ok) on 13-Янв-18, 15:07 
> наводящий вопрос - а на чём написан интерпретатор байт-кода питона?

А причём тут питон? Да хоть на Java - jython, например - это не изменит его интерпретативной сущности.


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

61. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +1 +/
Сообщение от Вареник on 13-Янв-18, 21:34 
jython не на Java (язык программирования), а на байткоде, исполняемом JIT ядром - сишечкой, ассмеблерными вставками.
Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

77. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от Аноним (??) on 17-Янв-18, 00:43 
> А причём тут питон? Да хоть на Java - jython, например -
> это не изменит его интерпретативной сущности.

Да какая разница? Валять дурака на левых входных данных можно и на питоне и на яве. Особенно если тебе внезапно кернел отгрузит какую-то фигню а хакер воспользуется недоразумением.

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

38. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от Адекват (ok) on 13-Янв-18, 14:54 
> Это слишком сложно для меня. Я пишу на питоне совсем не что
> умен, а потому что проще. Зато у меня нет проблем с
> переполнением буферов.

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

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

40. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +2 +/
Сообщение от другой Аноним on 13-Янв-18, 15:07 
>> Это слишком сложно для меня. Я пишу на питоне совсем не что
> А как вы решаете проблему зоопарка версий его величества питона ?

Две версии это да, дичайший зоопарк!
> а о как не скачаешь что-то на пиотне, выясняется, что у меня
> версия не та, какие-то ошибки в коде не понятные,

Очевидно, тоже гадает и правит заголовок файла после написания скрипта!


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

44. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –2 +/
Сообщение от Аноним (??) on 13-Янв-18, 15:53 
Пользуюсь 3.6 и игнорирую код, несовместимый с ней. Ну примерно, как при сборке бинарников игнорируют PDP-11, например.

В тяжёлых случаях — во всех двух! — пользуюсь virtualenv. Это примерно как поставить старый CentOS в контейнер для запуска старой версии софта, несовместимой с современными дистрибутивами, только места значительно меньше занимает.

Про «ошибки в коде непонятные» посмеялись вместе в Гвидо. Ух, и юморист же ты!

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

48. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –3 +/
Сообщение от Адекват (ok) on 13-Янв-18, 16:44 
> Про «ошибки в коде непонятные» посмеялись вместе в Гвидо. Ух, и юморист
> же ты!

Поставлю вопрос по другому, вы написали платную программу, но выложили в открытый доступ бесплатную демо-версию, с ограниченным функционалом.
Как сделать так, чтобы эта программа, написанная на питоне работала У ВСЕХ (для тех, кто любит подменять понятия, я хочу сказать, что у всех, у кого компы не старее 15ти лет, у кого или винда, или линукс, или макось).
К слову сказать, написнный на СИ бинарик, особенно под винду заработает 100%, а вот в случае с питоном - то питон не той версии, то его вообще нет.
А люди, кто готов платить деньги вовсе не обязаны быть программистами, или сисадминами, им нужен конечный результат, функционал.

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

50. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +1 +/
Сообщение от Sirob on 13-Янв-18, 17:17 
Ты как раз описал SublimeText. К слову, нужная версия Питона там идёт в поставке с самой прогой.
Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

57. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –1 +/
Сообщение от Аноним (??) on 13-Янв-18, 19:27 
Так пиши на третьей версии. Про вторую забывать уже пора, поддержка скоро закончится. А то, что Питона вообще нет, ну так в Винде же. Что ж теперь опенсорсу не использовать какие-либо интерпретаторы только потому, что их по умолчанию нет в Винде?
Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

59. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +3 +/
Сообщение от другой Аноним on 13-Янв-18, 20:38 
> К слову сказать, написнный на СИ бинарик, особенно под винду заработает 100%,

Фантазер.

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

62. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +2 +/
Сообщение от Led (ok) on 13-Янв-18, 22:46 
> Я пишу на питоне совсем не что умен

Как раз именно поэтому.

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

22. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +3 +/
Сообщение от angra (ok) on 13-Янв-18, 08:13 
С++ это не memory managed язык. В нем доступна прямая адресная арфиметика и возможность выхода за границы буфера. Например в go такая ошибка не могла бы произойти, работа программы прервется как только произойдет выход за нижнюю границу буфера. А в perl вместо вылета или уязвимости было бы заворачивание к концу буфера.

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

28. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –1 +/
Сообщение от Аноним (??) on 13-Янв-18, 10:57 
> С++ это не memory managed язык. В нем доступна прямая адресная арфиметика

То, что она там доступна не означает, что ей обязательно нужно пользоваться. В C# она тоже доступна, но почти никто ей не пользуется. Проблема скорее в том, что обычно C++ код это дикая смесь Си и C++ кода, а нужно на весь Си код писать обертки.

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

30. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от angra (ok) on 13-Янв-18, 11:26 
Ну осталось глянуть как именно реализован оператор [] в std::string и что произойдет если обратится к [-1]. То описание, что мне попалось, говорит об отсутствии проверок на границы и рекомендует использовать at(), если проверка нужна. Получается, что даже в чистом C++ проблема остается.
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

43. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от Crazy Alex (ok) on 13-Янв-18, 15:25 
Так и есть - в соответствии с принципом "платить только за что, что используешь", то есть тоормоза надо запрашивать явно. Можно спорить, хорошо это в данном случае или нет, но есть оба варианта, и любой хоть как-то компетентный плюсовик это отличие знает.

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

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

42. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от Crazy Alex (ok) on 13-Янв-18, 15:14 
Возможна, и это хорошо - есть случаи, когда это действительно нужно. Но в повседневном программировании использование адресной арифметики, сырых массивов и (в меньшей степени) сырых указателей вообще - плохой тон начиная с C++11, в любом вменяемом проекте подобное завернут без хорошего обоснования.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

9. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +1 +/
Сообщение от Аноним (??) on 13-Янв-18, 00:49 
Кто-то что-то понял из несвязнного набора слов в статье?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +7 +/
Сообщение от angra (ok) on 13-Янв-18, 07:49 
Мне пришлось таки сходить по ссылке и почитать вполне связный набор слов в английской версии. Далее изложение(не дословный перевод) недостающей части:

Если realpath() скормить символическую ссылку, которая начинается с некоторого количества "../", то для превращения ее в абсолютный путь он вызывает getcwd, после чего начинает идти по слешам от _конца_ буфера и ожидает, что строка, возвращенная getcwd, начинается с "/". Как следствие из-за отсутствия одной из нужных проверок в случае с "(unreachable)" происходит выход за нижнюю границу буфера до следующего слеша в памяти и перезапись этого участка оставшейся частью симлинки.

Ну а дальше уже идет черная магия по подготовке памяти и симлинок для эксплуатации этой перезаписи.

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

19. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –2 +/
Сообщение от Аноним (??) on 13-Янв-18, 07:40 
> $ cat /sys/kernel/unprivileged_userns_clone
> cat: /sys/kernel/unprivileged_userns_clone: Нет такого файла или каталога
>$ uname -a
> Linux debian 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 > GNU/Linux

Опять какое-то особое ядро надо иметь? Особые настройки? Рут?

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

21. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +1 +/
Сообщение от angra (ok) on 13-Янв-18, 07:58 
Нет, всего лишь внимательно читать:

"Для инициирования появления относительного пути в эксплоите используется пространство имён идентификаторов пользователя, т.е. атака возможна только при активации поддержки "user namespaces" (sysctl kernel.unprivileged_userns_clone=1). "

По умолчанию это отключено. Используется обычно для некоторых конфигураций lxc/lxd/docker.

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

24. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –1 +/
Сообщение от Аноним (??) on 13-Янв-18, 08:54 
Я внимательно прочитал. sysctl управляет настройками в /sys, там этой настройки нет, следовательно и sysctl работать не будет.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

27. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от angra (ok) on 13-Янв-18, 10:55 
Я вообще-то про то, что в статье сказано о необходимости включения этого механизма для работы эксплоита. То есть сначала рут его должен включить, а потом уже его сможет эксплуатировать обычный пользователь.
Разумеется ядро можно собрать, выкинув userns напрочь и тогда возможности включить его не будет.
Конкретно в debian в штатном ядре userns присутствует, причем черти с какой версии.
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

52. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от EHLO on 13-Янв-18, 18:48 
> Я внимательно прочитал. sysctl управляет настройками в /sys, там этой настройки нет,
> следовательно и sysctl работать не будет.

в /proc/sys. А так логика верная =)

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

69. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +/
Сообщение от EHLO on 14-Янв-18, 23:58 
>> Я внимательно прочитал. sysctl управляет настройками в /sys, там этой настройки нет,
>> следовательно и sysctl работать не будет.
> в /proc/sys. А так логика верная =)

Уточню, потому что вдруг кто-то читает. "Верная логика" относится к соответствию sysctl и /proc/sys, а не к тому что отсутствие параметра "kernel.unprivileged_userns_clone" свидетельствует о невозможности эксплуатировать сабж.

kernel.unprivileged_userns_clone ― специфичный для ядра Дебиана параметр и его включение позволяет обычному юзеру в Дебианоподобных дистрах создавать пространства имён и соответственно облегчает поднятие привилегий. Отключение соответственно усложняет, но не есть и другие способы, см. ссылку на оригинал если что.

В других дистрибутивах свои особенности ограничения(или отсутствия ограничений) этой инновационщины, так что YMMV.

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

45. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –2 +/
Сообщение от Аноним (??) on 13-Янв-18, 16:06 
Странное дело: в новости про NPM было цело состязание злословия и конкурс моделей биореакторов, хотя проблему исправили за сутки и всё, в общем-то, обошлось лёгким неудобством. А тут целая эскалация привелегий в одном из центральных компонентов любого дистрибутива для прода, и поди ж ты — тишь, гладь, да божья благодать. Даже отстранять от работы и банить из интернета никого не требуют. Что так, друзья? Выдохлись в треде про NPM?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

46. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +2 +/
Сообщение от Борщдрайвен бигдата on 13-Янв-18, 16:32 
Кому что болит, о том и говорит. Тут, как видно, болит очень немногим, увы.
Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

64. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –1 +/
Сообщение от Аноним (??) on 14-Янв-18, 01:20 
по ходу только переписывание glibc на rust спасёт ситуацию
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

66. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –2 +/
Сообщение от RobotsCantPoop on 14-Янв-18, 13:21 
Тотальное выпиливание C/CPP спасёт от 90% проблем с безопасностью и.
Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

71. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –1 +/
Сообщение от Аноним (??) on 15-Янв-18, 18:41 
Как оно спасёт? Все имеющиеся там функции должны делать ровно то, что они делают сейчас. И ни грамма больше, ни меьше, иначе сломается совместимость с существующим прикладным софтом. Так что, для совместимости, если фунция не проверяет каких-то границ, она не должна их проверять, независимо, на каком языке написана.
Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

72. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  +1 +/
Сообщение от Michael Shigorin email(ok) on 16-Янв-18, 14:29 
> по ходу только переписывание glibc на rust спасёт ситуацию

Вы не понимаете, что значат буковки "glibc".

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

68. "Уязвимость в Glibc, позволяющая поднять привилегии в системе"  –1 +/
Сообщение от Аноним (??) on 14-Янв-18, 17:15 
Еще одна уязвимость, связанная с suid? Ну, дело не новое
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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


  Закладки на сайте
  Проследить за страницей
Created 1996-2018 by Maxim Chirkov  
ДобавитьРекламаВебмастеруГИД  
Hosting by Ihor