В стандартной библиотеке 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.dev/opennews/art.shtml?num=47894
Мне нравится этот красивый номер уязвимости.
CVE-2018-1000000 топчик
Да что ж такое-то, 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
Подстава случилась тогда когда придумали относительные пути, со всякими .. и проч :). На этом столько серверов погорело. И до сих пор наивные чукотские юноши не знают что ремота может .. прислать. Кто угодно тырит /etc/passwd в результате. Да и остальное.
> user namespacesНу почему каждая третья уязвимость связана с *этим*?
С напряжением ждём уязвимости /dev/null
При обращении к /dev/null можно задудосить и без того багнутый Meltdown камень
>> user namespaces
> Ну почему каждая третья уязвимость связана с *этим*?Хайпонули немножечко, бывает. Отключил, если вдруг не отключено по дефолту и забыл года на три про *это*. А там либо допилят, либо прикопают.
Больше должно напрягать, что последние несколько декад каждое второе поднятие привилегий связано с
>через манипуляцию с исполняемыми файлами с флагом suid root
И почти никто не шевелится их выпиливать из дистрибутивов
Первый раз отключил в августе '12-го года, что за уязвимость была не вспомню, но с тех пор # CONFIG_USER_NS is not set
Ну и как, контейнеры работают?
> Ну и как, контейнеры работают?Нет, а должны?
>>> user namespaces
>> Ну почему каждая третья уязвимость связана с *этим*?
> Хайпонули немножечко,
> Больше должно напрягать, что последние несколько декад каждое второе
>>через манипуляцию с исполняемыми файлами с флагом suid root
> И почти никто не шевелится их выпиливать из дистрибутивовОни шевелятся, ты не понял. Они готовят user namespaces на царствование.
Когда "каждое второе" будет через userns -- король умер, да здравствует король.
Всем срочно переходить на musl?
там пользователей из ад нету, как мы будем деньги микрософту платить?
Можно подумать, в прочих либцах совсем нет уязвимостей.
> Всем срочно переходить на musl?В нем тоже CVE случаются. Переходить надо на другой глобус, где програмисты не ошибаются.
полный опасносте мирок стандартных библиотек :)
Полон опасностей Си-мирок: то буфера переполнятся, то стеки слетают, то длину строк проверить забудут. В общем, тысяча и один способ накосячить трудноуловимо и критически.Писали бы на managed-языках - таких проблем by-design бы не было бы.
Правда, тупило бы непредсказуемо, память жрало и имело бы свои классы ошибок -- на managed языках как-то быстро расслабляются, с управлением ресурсами в особенности, забывая, что ресурсы - это далеко не только память.
Для Apple Lisa и Apple IIe большая часть программ написана на Pascal (Apple ObjectPascal уже тогда был, кажется). Недавно измеряли скорость ответной реакции системы на внешнее воздействие - 30-60 миллисекунд. Для примера ещё взяли современные смартфоны с операционными системами, написанными на C/C++,Java - скорость ответной реакции от 250 до 800 миллисекунд. Делайте выводы.
Всё переврали.
Там речь шла про скорость отклика в консольке. В Apple IIe она была чуть ли не аппаратно реализована, поэтому такое маленькое время отклика.
И никаких 800 мс я не вижу. В районе 100 на нормальных компьютерах и 120-130 на смартфонах. Это нормально, с учётом того, как работает тачскрин. https://danluu.com/input-lag/
> И никаких 800 мс я не вижу. В районе 100 на нормальных
> компьютерах и 120-130 на смартфонах. Это нормально, с учётом того, как
> работает тачскрин. https://danluu.com/input-lag/Это все галимая теория, в реальных условиях, у пользователя на его смартфоне за 4000р запущенно несколько программок в фоне, и телефону нужно продуматься, просто при выходе из VK.
>,Java - скорость ответной реакции от 250 до 800 миллисекундПчёлы (iZEN) против мёда! ;)
>>,Java - скорость ответной реакции от 250 до 800 миллисекунд
> Пчёлы (iZEN) против мёда! ;)В Android нет Java. Как язык высокого уровня используется, а как бинарный код - нет той JVM и среды исполнения, чтобы считать это Java.
Ты Мастер разбирающийся в сортах(Tm)!
Остальным пох, жаба она и в дройдах - жаба! :-р
И она такое же Г как и на пизюках.
Не - ну очередные "склад-магазины" клепать - самое оно! Хуже жабы - лучше нет! Но системное что то на ней лепить ... надо быть iZEN-ом на всю голову :-Р
> Ты Мастер разбирающийся в сортах(Tm)!
> Остальным пох, жаба она и в дройдах - жаба! :-р
> И она такое же Г как и на пизюках.
> Не - ну очередные "склад-магазины" клепать - самое оно! Хуже жабы -
> лучше нет! Но системное что то на ней лепить ... надо
> быть iZEN-ом на всю голову :-РА вот интересно, как вы разделяете, Oracle Access Manager системное или несистемное ПО?
Java может и нет. А тормозное памятежручее г@вно - есть. Так какая разница?P.S. Если что-то пишется - как жаба,тормозит - как жаба, память жрет - как жаба и глючит - как жаба, то это жаба и есть!
> Java может и нет. А тормозное памятежручее г@вно - есть. Так какая
> разница?
> P.S. Если что-то пишется - как жаба,тормозит - как жаба, память жрет
> - как жаба и глючит - как жаба, то это жаба
> и есть!JVM написана на C++. Ничего уж тут не поделаешь.
> Pascal
> скорость ответной реакции системы на внешнее воздействие - 30-60 миллисекунд.
> Java - скорость ответной реакции от 250 до 800 миллисекунд. Делайте выводы.Выводы: Java - г-но.
Ну да, а то на C/CPP софт не тупит, не течёт, сжирая гигабайты, и не падает. Ну ваще-ваще.
Ну да, а в C/CPP не расслабляются, прям так всё качественно контролируют, что софт на сях не тупит, не падает, не течёт сжирая гигабайты и уязвимостям ну ваще не подвержен.
> Правда, тупило бы непредсказуемо, память жралоХипстота не в курсе существования нормальных языков и концептов. Неудивительно.
Фантастика на уровне "АйФак 10". В вашей реальности хипстота на C пишет.
>Писали бы на managed-языках - таких проблем by-design бы не было бы.Ты внимательно читал описание бага? Ну допустим это был бы С++ и getcwd() возвращала бы std::string("(unreachable)"). Исправило ли бы это проблему? Нет! Просто это было идиотское архитектурное решение, ломающее обратную совместимость.
Это слишком сложно для меня. Я пишу на питоне совсем не что умен, а потому что проще. Зато у меня нет проблем с переполнением буферов.
Ты хотел сказать, что ещё не дорос до проектов, на которых нужны настолько сложные вещи, что и переполнение буфера будет вылезать?
наводящий вопрос - а на чём написан интерпретатор байт-кода питона?
> наводящий вопрос - а на чём написан интерпретатор байт-кода питона?А причём тут питон? Да хоть на Java - jython, например - это не изменит его интерпретативной сущности.
jython не на Java (язык программирования), а на байткоде, исполняемом JIT ядром - сишечкой, ассмеблерными вставками.
> А причём тут питон? Да хоть на Java - jython, например -
> это не изменит его интерпретативной сущности.Да какая разница? Валять дурака на левых входных данных можно и на питоне и на яве. Особенно если тебе внезапно кернел отгрузит какую-то фигню а хакер воспользуется недоразумением.
> Это слишком сложно для меня. Я пишу на питоне совсем не что
> умен, а потому что проще. Зато у меня нет проблем с
> переполнением буферов.А как вы решаете проблему зоопарка версий его величества питона ?, а то как не скачаешь что-то на пиотне, выясняется, что у меня версия не та, какие-то ошибки в коде не понятные, приходится методом тыка в заголовке файла версию указывать.
>> Это слишком сложно для меня. Я пишу на питоне совсем не что
> А как вы решаете проблему зоопарка версий его величества питона ?Две версии это да, дичайший зоопарк!
> а о как не скачаешь что-то на пиотне, выясняется, что у меня
> версия не та, какие-то ошибки в коде не понятные,Очевидно, тоже гадает и правит заголовок файла после написания скрипта!
Пользуюсь 3.6 и игнорирую код, несовместимый с ней. Ну примерно, как при сборке бинарников игнорируют PDP-11, например.В тяжёлых случаях — во всех двух! — пользуюсь virtualenv. Это примерно как поставить старый CentOS в контейнер для запуска старой версии софта, несовместимой с современными дистрибутивами, только места значительно меньше занимает.
Про «ошибки в коде непонятные» посмеялись вместе в Гвидо. Ух, и юморист же ты!
> Про «ошибки в коде непонятные» посмеялись вместе в Гвидо. Ух, и юморист
> же ты!Поставлю вопрос по другому, вы написали платную программу, но выложили в открытый доступ бесплатную демо-версию, с ограниченным функционалом.
Как сделать так, чтобы эта программа, написанная на питоне работала У ВСЕХ (для тех, кто любит подменять понятия, я хочу сказать, что у всех, у кого компы не старее 15ти лет, у кого или винда, или линукс, или макось).
К слову сказать, написнный на СИ бинарик, особенно под винду заработает 100%, а вот в случае с питоном - то питон не той версии, то его вообще нет.
А люди, кто готов платить деньги вовсе не обязаны быть программистами, или сисадминами, им нужен конечный результат, функционал.
Ты как раз описал SublimeText. К слову, нужная версия Питона там идёт в поставке с самой прогой.
Так пиши на третьей версии. Про вторую забывать уже пора, поддержка скоро закончится. А то, что Питона вообще нет, ну так в Винде же. Что ж теперь опенсорсу не использовать какие-либо интерпретаторы только потому, что их по умолчанию нет в Винде?
> К слову сказать, написнный на СИ бинарик, особенно под винду заработает 100%,Фантазер.
> Я пишу на питоне совсем не что уменКак раз именно поэтому.
С++ это не memory managed язык. В нем доступна прямая адресная арфиметика и возможность выхода за границы буфера. Например в go такая ошибка не могла бы произойти, работа программы прервется как только произойдет выход за нижнюю границу буфера. А в perl вместо вылета или уязвимости было бы заворачивание к концу буфера.
> С++ это не memory managed язык. В нем доступна прямая адресная арфиметикаТо, что она там доступна не означает, что ей обязательно нужно пользоваться. В C# она тоже доступна, но почти никто ей не пользуется. Проблема скорее в том, что обычно C++ код это дикая смесь Си и C++ кода, а нужно на весь Си код писать обертки.
Ну осталось глянуть как именно реализован оператор [] в std::string и что произойдет если обратится к [-1]. То описание, что мне попалось, говорит об отсутствии проверок на границы и рекомендует использовать at(), если проверка нужна. Получается, что даже в чистом C++ проблема остается.
Так и есть - в соответствии с принципом "платить только за что, что используешь", то есть тоормоза надо запрашивать явно. Можно спорить, хорошо это в данном случае или нет, но есть оба варианта, и любой хоть как-то компетентный плюсовик это отличие знает.В данном случае это значения не имеет - плюсовый код вообще не особо предполагает работу со строками через индексы на каждом шагу - где возможно используют готовые алгоритмы, в них все проверки на месте и в сто раз проще понять, что вообще делает код. А так - при желании можно хоть char* получить, конечно.
Возможна, и это хорошо - есть случаи, когда это действительно нужно. Но в повседневном программировании использование адресной арифметики, сырых массивов и (в меньшей степени) сырых указателей вообще - плохой тон начиная с C++11, в любом вменяемом проекте подобное завернут без хорошего обоснования.
Кто-то что-то понял из несвязнного набора слов в статье?
Мне пришлось таки сходить по ссылке и почитать вполне связный набор слов в английской версии. Далее изложение(не дословный перевод) недостающей части:Если realpath() скормить символическую ссылку, которая начинается с некоторого количества "../", то для превращения ее в абсолютный путь он вызывает getcwd, после чего начинает идти по слешам от _конца_ буфера и ожидает, что строка, возвращенная getcwd, начинается с "/". Как следствие из-за отсутствия одной из нужных проверок в случае с "(unreachable)" происходит выход за нижнюю границу буфера до следующего слеша в памяти и перезапись этого участка оставшейся частью симлинки.
Ну а дальше уже идет черная магия по подготовке памяти и симлинок для эксплуатации этой перезаписи.
> $ 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Опять какое-то особое ядро надо иметь? Особые настройки? Рут?
Нет, всего лишь внимательно читать:"Для инициирования появления относительного пути в эксплоите используется пространство имён идентификаторов пользователя, т.е. атака возможна только при активации поддержки "user namespaces" (sysctl kernel.unprivileged_userns_clone=1). "
По умолчанию это отключено. Используется обычно для некоторых конфигураций lxc/lxd/docker.
Я внимательно прочитал. sysctl управляет настройками в /sys, там этой настройки нет, следовательно и sysctl работать не будет.
Я вообще-то про то, что в статье сказано о необходимости включения этого механизма для работы эксплоита. То есть сначала рут его должен включить, а потом уже его сможет эксплуатировать обычный пользователь.
Разумеется ядро можно собрать, выкинув userns напрочь и тогда возможности включить его не будет.
Конкретно в debian в штатном ядре userns присутствует, причем черти с какой версии.
> Я внимательно прочитал. sysctl управляет настройками в /sys, там этой настройки нет,
> следовательно и sysctl работать не будет.в /proc/sys. А так логика верная =)
>> Я внимательно прочитал. sysctl управляет настройками в /sys, там этой настройки нет,
>> следовательно и sysctl работать не будет.
> в /proc/sys. А так логика верная =)Уточню, потому что вдруг кто-то читает. "Верная логика" относится к соответствию sysctl и /proc/sys, а не к тому что отсутствие параметра "kernel.unprivileged_userns_clone" свидетельствует о невозможности эксплуатировать сабж.
kernel.unprivileged_userns_clone ― специфичный для ядра Дебиана параметр и его включение позволяет обычному юзеру в Дебианоподобных дистрах создавать пространства имён и соответственно облегчает поднятие привилегий. Отключение соответственно усложняет, но не есть и другие способы, см. ссылку на оригинал если что.
В других дистрибутивах свои особенности ограничения(или отсутствия ограничений) этой инновационщины, так что YMMV.
Странное дело: в новости про NPM было цело состязание злословия и конкурс моделей биореакторов, хотя проблему исправили за сутки и всё, в общем-то, обошлось лёгким неудобством. А тут целая эскалация привелегий в одном из центральных компонентов любого дистрибутива для прода, и поди ж ты — тишь, гладь, да божья благодать. Даже отстранять от работы и банить из интернета никого не требуют. Что так, друзья? Выдохлись в треде про NPM?
Кому что болит, о том и говорит. Тут, как видно, болит очень немногим, увы.
по ходу только переписывание glibc на rust спасёт ситуацию
Тотальное выпиливание C/CPP спасёт от 90% проблем с безопасностью и.
Как оно спасёт? Все имеющиеся там функции должны делать ровно то, что они делают сейчас. И ни грамма больше, ни меьше, иначе сломается совместимость с существующим прикладным софтом. Так что, для совместимости, если фунция не проверяет каких-то границ, она не должна их проверять, независимо, на каком языке написана.
> по ходу только переписывание glibc на rust спасёт ситуациюВы не понимаете, что значат буковки "glibc".
Еще одна уязвимость, связанная с suid? Ну, дело не новое