The OpenNET Project / Index page

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

Уязвимость в Glibc, позволяющая поднять привилегии в системе

12.01.2018 23:04

В стандартной библиотеке Glibc выявлена уязвимость (CVE-2018-1000001), вызванная переполнением через нижнюю границу буфера в функции realpath(), проявляющимся при возврате относительного пути системным вызовом getcwd(). Изначально ядро Linux возвращало в getcwd() только абсолютные пути, но затем в ядре 2.6.36 поведение было изменено, но функции Glibc не были адаптированы на обработку относительных путей.

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

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

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

Обновление пакетов с устранением уязвимости уже выпущено для SUSE и openSUSE. Исправление пока недоступно для Ubuntu, Debian, Fedora и RHEL.

  1. Главная ссылка к новости (http://seclists.org/oss-sec/20...)
  2. OpenNews: Уязвимость в Glibc ld.so, позволяющая поднять свои привилегии в системе
  3. OpenNews: Удалённо эксплуатируемая уязвимость в Glibc, охватывающая большинство сетевых приложений в Linux
  4. OpenNews: Уязвимость GHOST в Glibc может проявляться в web-приложениях на языке PHP
  5. OpenNews: Критическая уязвимость в Glibc, которая может привести к удалённому выполнению кода в Linux
  6. OpenNews: В Glibc обнаружена серьезная уязвимость
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/47894-glibc
Ключевые слова: glibc, security
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (68) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 23:39, 12/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    Мне нравится этот красивый номер уязвимости.
     
     
  • 2.3, Багтрекер (?), 23:54, 12/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    CVE-2018-1000000 топчик
     
     
  • 3.49, pavlinux (ok), 17:09, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да что ж такое-то,  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




     
     
  • 4.75, Аноним (-), 23:36, 16/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Подстава случилась тогда когда придумали относительные пути, со всякими .. и проч :). На этом столько серверов погорело. И до сих пор наивные чукотские юноши не знают что ремота может .. прислать. Кто угодно тырит /etc/passwd в результате. Да и остальное.
     

  • 1.2, Аноним (-), 23:45, 12/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > user namespaces

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

     
     
  • 2.10, ы (?), 01:26, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    С напряжением ждём уязвимости /dev/null
     
     
  • 3.33, ХипстерСпам (?), 12:32, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    При обращении к /dev/null можно задудосить и без того багнутый Meltdown камень
     
  • 2.13, EHLO (?), 02:29, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >> user namespaces
    > Ну почему каждая третья уязвимость связана с *этим*?

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

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

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

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

     
     
  • 3.23, backbone (ok), 08:46, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Первый раз отключил в августе '12-го года, что за уязвимость была не вспомню, но с тех пор # CONFIG_USER_NS is not set
     
     
  • 4.53, Аноним (-), 19:04, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и как, контейнеры работают?
     
     
  • 5.55, backbone (ok), 19:15, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну и как, контейнеры работают?

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

     
  • 3.25, Andrey Mitrofanov (?), 09:55, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>> user namespaces
    >> Ну почему каждая третья уязвимость связана с *этим*?
    > Хайпонули немножечко,
    > Больше должно напрягать, что последние несколько декад каждое второе
    >>через манипуляцию с исполняемыми файлами с флагом suid root
    > И почти никто не шевелится их выпиливать из дистрибутивов

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

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

     

  • 1.6, минонА (?), 00:13, 13/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Всем срочно переходить на musl?
     
     
  • 2.31, Аноним (-), 12:23, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    там пользователей из ад нету, как мы будем деньги микрософту платить?
     
  • 2.54, Аноним (-), 19:09, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Можно подумать, в прочих либцах совсем нет уязвимостей.
     
  • 2.76, Аноним (-), 23:48, 16/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Всем срочно переходить на musl?

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

     

  • 1.8, ыы (?), 00:47, 13/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    полный опасносте мирок стандартных библиотек :)
     
     
  • 2.14, Анонимчик (?), 03:04, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Полон опасностей Си-мирок: то буфера переполнятся, то стеки слетают, то длину строк проверить забудут. В общем, тысяча и один способ накосячить трудноуловимо и критически.

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

     
     
  • 3.15, Crazy Alex (??), 03:36, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +17 +/
    Правда, тупило бы непредсказуемо, память жрало и имело бы свои классы ошибок -- на managed языках как-то быстро расслабляются, с управлением ресурсами в особенности, забывая, что ресурсы - это далеко не только память.
     
     
  • 4.29, iZEN (ok), 11:13, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Для Apple Lisa и Apple IIe большая часть программ написана на Pascal (Apple ObjectPascal уже тогда был, кажется). Недавно измеряли скорость ответной реакции системы на внешнее воздействие - 30-60 миллисекунд. Для примера ещё взяли современные смартфоны с операционными системами, написанными на C/C++,Java - скорость ответной реакции от 250 до 800 миллисекунд. Делайте выводы.
     
     
  • 5.34, h31 (ok), 12:38, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Всё переврали.
    Там речь шла про скорость отклика в консольке. В Apple IIe она была чуть ли не аппаратно реализована, поэтому такое маленькое время отклика.
    И никаких 800 мс я не вижу. В районе 100 на нормальных компьютерах и 120-130 на смартфонах. Это нормально, с учётом того, как работает тачскрин. https://danluu.com/input-lag/
     
     
  • 6.37, Адекват (ok), 14:52, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И никаких 800 мс я не вижу. В районе 100 на нормальных
    > компьютерах и 120-130 на смартфонах. Это нормально, с учётом того, как
    > работает тачскрин. https://danluu.com/input-lag/

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

     
  • 5.56, Аноним (-), 19:17, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >,Java - скорость ответной реакции от 250 до 800 миллисекунд

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

     
     
  • 6.60, iZEN (ok), 20:54, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • –5 +/
    >>,Java - скорость ответной реакции от 250 до 800 миллисекунд
    > Пчёлы (iZEN) против мёда! ;)

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


     
     
  • 7.73, _ (??), 17:22, 16/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ты Мастер разбирающийся в сортах(Tm)!
    Остальным пох, жаба она и в дройдах - жаба! :-р
    И она такое же Г как и на пизюках.
    Не - ну очередные "склад-магазины" клепать - самое оно! Хуже жабы - лучше нет! Но системное что то на ней лепить ... надо быть iZEN-ом на всю голову :-Р
     
     
  • 8.74, iZEN (ok), 21:03, 16/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А вот интересно, как вы разделяете, Oracle Access Manager системное или несистем... текст свёрнут, показать
     
  • 7.78, Аноним (-), 18:05, 17/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Java может и нет. А тормозное памятежручее г@вно - есть. Так какая разница?

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

     
     
  • 8.79, iZEN (ok), 18:34, 17/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    JVM написана на C Ничего уж тут не поделаешь ... текст свёрнут, показать
     
  • 5.63, Led (ok), 22:51, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Pascal
    > скорость ответной реакции системы на внешнее воздействие - 30-60 миллисекунд.
    > Java - скорость ответной реакции от 250 до 800 миллисекунд. Делайте выводы.

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


     
  • 4.35, RobotsCantPoop (?), 14:37, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну да, а то на C/CPP софт не тупит, не течёт, сжирая гигабайты, и не падает. Ну ваще-ваще.
     
  • 4.41, RobotsCantPoop (?), 15:14, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну да, а в C/CPP не расслабляются, прям так всё качественно контролируют, что софт на сях не тупит, не падает, не течёт сжирая гигабайты и уязвимостям ну ваще не подвержен.
     
  • 4.67, RobotsCantPoop (?), 13:26, 14/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Правда, тупило бы непредсказуемо, память жрало

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

     
     
  • 5.70, щи (?), 10:37, 15/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Фантастика на уровне "АйФак 10". В вашей реальности хипстота на C пишет.
     
  • 3.17, Аноним (-), 06:32, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Писали бы на managed-языках - таких проблем by-design бы не было бы.

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

     
     
  • 4.18, Анонимчик (?), 07:18, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это слишком сложно для меня. Я пишу на питоне совсем не что умен, а потому что проще. Зато у меня нет проблем с переполнением буферов.
     
     
  • 5.26, QuAzI (ok), 10:06, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Ты хотел сказать, что ещё не дорос до проектов, на которых нужны настолько сложные вещи, что и переполнение буфера будет вылезать?
     
  • 5.32, Hellraiser (??), 12:27, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    наводящий вопрос - а на чём написан интерпретатор байт-кода питона?
     
     
  • 6.39, iZEN (ok), 15:07, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > наводящий вопрос - а на чём написан интерпретатор байт-кода питона?

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


     
     
  • 7.61, Вареник (?), 21:34, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    jython не на Java (язык программирования), а на байткоде, исполняемом JIT ядром - сишечкой, ассмеблерными вставками.
     
  • 7.77, Аноним (-), 00:43, 17/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А причём тут питон? Да хоть на Java - jython, например -
    > это не изменит его интерпретативной сущности.

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

     
  • 5.38, Адекват (ok), 14:54, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Это слишком сложно для меня. Я пишу на питоне совсем не что
    > умен, а потому что проще. Зато у меня нет проблем с
    > переполнением буферов.

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

     
     
  • 6.40, другой Аноним (?), 15:07, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Это слишком сложно для меня. Я пишу на питоне совсем не что
    > А как вы решаете проблему зоопарка версий его величества питона ?

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

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


     
  • 6.44, Аноним (-), 15:53, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Пользуюсь 3.6 и игнорирую код, несовместимый с ней. Ну примерно, как при сборке бинарников игнорируют PDP-11, например.

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

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

     
     
  • 7.48, Адекват (ok), 16:44, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Про «ошибки в коде непонятные» посмеялись вместе в Гвидо. Ух, и юморист
    > же ты!

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

     
     
  • 8.50, Sirob (?), 17:17, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты как раз описал SublimeText К слову, нужная версия Питона там идёт в поставке... текст свёрнут, показать
     
  • 8.57, Аноним (-), 19:27, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так пиши на третьей версии Про вторую забывать уже пора, поддержка скоро законч... текст свёрнут, показать
     
  • 8.59, другой Аноним (?), 20:38, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Фантазер ... текст свёрнут, показать
     
  • 5.62, Led (ok), 22:46, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Я пишу на питоне совсем не что умен

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

     
  • 4.22, angra (ok), 08:13, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    С++ это не memory managed язык. В нем доступна прямая адресная арфиметика и возможность выхода за границы буфера. Например в go такая ошибка не могла бы произойти, работа программы прервется как только произойдет выход за нижнюю границу буфера. А в perl вместо вылета или уязвимости было бы заворачивание к концу буфера.

     
     
  • 5.28, Аноним (-), 10:57, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > С++ это не memory managed язык. В нем доступна прямая адресная арфиметика

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

     
     
  • 6.30, angra (ok), 11:26, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну осталось глянуть как именно реализован оператор [] в std::string и что произойдет если обратится к [-1]. То описание, что мне попалось, говорит об отсутствии проверок на границы и рекомендует использовать at(), если проверка нужна. Получается, что даже в чистом C++ проблема остается.
     
     
  • 7.43, Crazy Alex (ok), 15:25, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Так и есть - в соответствии с принципом "платить только за что, что используешь", то есть тоормоза надо запрашивать явно. Можно спорить, хорошо это в данном случае или нет, но есть оба варианта, и любой хоть как-то компетентный плюсовик это отличие знает.

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

     
  • 5.42, Crazy Alex (ok), 15:14, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Возможна, и это хорошо - есть случаи, когда это действительно нужно. Но в повседневном программировании использование адресной арифметики, сырых массивов и (в меньшей степени) сырых указателей вообще - плохой тон начиная с C++11, в любом вменяемом проекте подобное завернут без хорошего обоснования.
     

  • 1.9, Аноним (-), 00:49, 13/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Кто-то что-то понял из несвязнного набора слов в статье?
     
     
  • 2.20, angra (ok), 07:49, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Мне пришлось таки сходить по ссылке и почитать вполне связный набор слов в английской версии. Далее изложение(не дословный перевод) недостающей части:

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

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

     

  • 1.19, Аноним (-), 07:40, 13/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > $ 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

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

     
     
  • 2.21, angra (ok), 07:58, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет, всего лишь внимательно читать:

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

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

     
     
  • 3.24, Аноним (-), 08:54, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я внимательно прочитал. sysctl управляет настройками в /sys, там этой настройки нет, следовательно и sysctl работать не будет.
     
     
  • 4.27, angra (ok), 10:55, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я вообще-то про то, что в статье сказано о необходимости включения этого механизма для работы эксплоита. То есть сначала рут его должен включить, а потом уже его сможет эксплуатировать обычный пользователь.
    Разумеется ядро можно собрать, выкинув userns напрочь и тогда возможности включить его не будет.
    Конкретно в debian в штатном ядре userns присутствует, причем черти с какой версии.
     
  • 4.52, EHLO (?), 18:48, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Я внимательно прочитал. sysctl управляет настройками в /sys, там этой настройки нет,
    > следовательно и sysctl работать не будет.

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

     
     
  • 5.69, EHLO (?), 23:58, 14/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> Я внимательно прочитал. sysctl управляет настройками в /sys, там этой настройки нет,
    >> следовательно и sysctl работать не будет.
    > в /proc/sys. А так логика верная =)

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

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

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

     

  • 1.45, Аноним (-), 16:06, 13/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Странное дело: в новости про NPM было цело состязание злословия и конкурс моделей биореакторов, хотя проблему исправили за сутки и всё, в общем-то, обошлось лёгким неудобством. А тут целая эскалация привелегий в одном из центральных компонентов любого дистрибутива для прода, и поди ж ты — тишь, гладь, да божья благодать. Даже отстранять от работы и банить из интернета никого не требуют. Что так, друзья? Выдохлись в треде про NPM?
     
     
  • 2.46, Борщдрайвен бигдата (?), 16:32, 13/01/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Кому что болит, о том и говорит. Тут, как видно, болит очень немногим, увы.
     

  • 1.64, Аноним (-), 01:20, 14/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    по ходу только переписывание glibc на rust спасёт ситуацию
     
     
  • 2.66, RobotsCantPoop (?), 13:21, 14/01/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Тотальное выпиливание C/CPP спасёт от 90% проблем с безопасностью и.
     
  • 2.71, Аноним (-), 18:41, 15/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как оно спасёт? Все имеющиеся там функции должны делать ровно то, что они делают сейчас. И ни грамма больше, ни меьше, иначе сломается совместимость с существующим прикладным софтом. Так что, для совместимости, если фунция не проверяет каких-то границ, она не должна их проверять, независимо, на каком языке написана.
     
  • 2.72, Michael Shigorin (ok), 14:29, 16/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > по ходу только переписывание glibc на rust спасёт ситуацию

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

     

  • 1.68, Аноним (-), 17:15, 14/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Еще одна уязвимость, связанная с suid? Ну, дело не новое
     

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



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

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