Компания Qualys раскрыла (https://www.openwall.com/lists/oss-security/2018/09/25/4) информацию об уязвимости (CVE-2018-14634 (https://security-tracker.debian.org/tracker/CVE-2018-14634)) в ядре Linux. Проблема вызвана целочисленным переполнением в функции create_elf_tables() и проявляется на 64-разрядных системах, имеющих более 32 Гб ОЗУ. Локальный атакующий может эксплуатировать уязвимость через исполняемый файл с флагом SUID root для получения полноценных root-привилегий в системе.
Вызывающая проблему ошибка была внесена (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) в ядро в июле 2007 года вместе с кодом для поддержки аргументов переменной длины. Около года назад в ядро был принято исправление (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...), ограничивающее размер стека для аргументов exec(). Данное исправление блокирует возможность эксплуатации уязвимости, но многие дистрибутивы не портировали его в свои длительно поддерживаемые пакеты с ядром.Например, проблема затрагивает (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-14634) ядро, поставляемое (https://access.redhat.com/articles/3588731) в Red Hat Enterprise Linux 6 и 7, Ubuntu 12.04 (https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2...) и Debian 8 (https://security-tracker.debian.org/tracker/CVE-2018-14634).
Уязвимость эксплуатируется через запуск при помощи функции execve() suid-файла с передачей ему очень большого числа аргументов (около 16 миллиардов). Для успешной атаки в системе должно быть как минимум 32GB свободной оперативной памяти. Код прототипов эксплоитов дотупен в открытом (https://www.qualys.com/2018/09/25/cve-2018-14634/poc-suidbin.c) доступе (https://www.qualys.com/2018/09/25/cve-2018-14634/poc-exploit.c).
URL: https://www.openwall.com/lists/oss-security/2018/09/25/4
Новость: https://www.opennet.me/opennews/art.shtml?num=49340
>очень большого числа аргументов (около 16 миллиардов)
>минимум 32GB свободной оперативной памятиподождите,подождите. 16 млрд аргументов по 8 байт каждый это уже 128GB
16 млрд по 2 байта? или не работает?
ну, я исхожу из того, что каждый аргумент - ссылка на строку, соответственно, каждый аргумент потребует как минимум 8 байт (и, если такое предположение изначально неверно, то и расчёт будет некорректным)
В C(СИ) массив строк (для exec..) это просто кусок памяти, а разделение в нём - нулевые символы \0
а, ну тогда всё правильно в новости написано, был неправ
В C как раз argv это массив указателей на строки
процессу передаётся именно одна большая строка, где разделители это \0, crt её потом парсит и устанавливает argv[] для сишных прогамм
Угу, поэтому в _C_ argv — это массив указателей.
Это он в userspace-коде - массив указателей. А в ядре, которое тоже, внезапно, на С - не обязан.
Паря, до того как твой main() получит управление - в обычной ситуации startup делает довольно много интересного. И есть некоторая разница между стандартом на язык си и тем как ядро по факту создает процесс в конкретной системе и как ему параметры передает.
откуда вы все берётесь то?!!
Ещё раз:
> Проблема вызвана целочисленным переполнением в функции create_elf_tables() и проявляется на 64-разрядных системах, имеющих более 32 Гб ОЗУ.- целочисленным переполнением
- в функции create_elf_tables()
- на 64-разрядных системах
- имеющих более 32 Гб ОЗУМожет ещё раз повторить? Или бесполезно?
В статье выше есть все необходимые ссылки, чтобы объяснить это.> We execve() a SUID-root binary with exactly 0x80000000 "items" (i.e.,
> INT_MIN "items"): roughly 0x80000000 * sizeof(char *) = 16GB of argument
> pointers, 16GB of argument strings, and 16GB of environment strings. Our
> exploit requires "only" 2 * 16GB = 32GB of memory, instead of 3 * 16GB =
> 48GB or more, because we use a few tricks to reduce its memory footprint
> (for example, we replace the nearly 16GB of equal argument pointers with
> equivalent file-backed mappings that consume practically no memory).
$ free
total used free shared buff/cache available
Mem: 131990704 8925636 115768364 1228 7296704 121915208
Swap: 0 0 0$ ./poc-exploit
execve: Argument list too long
died in main: 229Ничего не работает в этих ваших линуксах.
uname -r забыл показать
4.4.0-17134-Microsoft
$ uname -a
Linux steinberg 4.18.1-arch1-1-ARCH #1 SMP PREEMPT Wed Aug 15 21:11:55 UTC 2018 x86_64 GNU/LinuxОба бинарника компилировал, suid ставил.
> Около года назад в ядро было принято исправлениеочевидно, что в 4.18.1 оно есть. ищи ядро без него.
# gcc -O0 -o poc-suidbin poc-suidbin.c
# chown root poc-suidbin
# chmod 4555 poc-suidbin$ gcc -o poc-exploit poc-exploit.c
$ time ./poc-exploitну и рутом ты после этого все равно не станешь. это только POC, который показывает, что можно переписать LD_LIBRARY_PATH. а дальше уж сам.
Тоесть эксплоит возможен только с рутом?
Сначала выставляешь от рута set-uid бит, а затем эксплуатируешь. Или я что-то недопонимаю...
Читаем тут: https://seclists.org/oss-sec/2018/q3/274
>As a result, ld.so partly overwrites (i.e., rewrites) our "onebyte"
>environment variables with the fname[] buffer in handle_ld_preload()
>(whose contents we control through our LD_PRELOAD environment variable)
>and thereby nullifies process_envvars()'s filtering of UNSECURE_ENVVARS
>(LD_AUDIT, LD_LIBRARY_PATH, LD_PRELOAD, etc). The exploitation of this
>lack of UNSECURE_ENVVARS filtering in ld.so (via a suitable SUID-root
>binary) is left as an exercise for the interested reader.Короче, надо найти подходящий suid бинарь в системе. А в POC он тебе уже предоставлен.
Есть утилиты в системе с уже установленным SUID. Например, ping.
Это в каких системах?
stat /bin/ping
File: '/bin/ping'
Size: 66176 Blocks: 136 IO Block: 4096 regular file
Device: fc00h/64512d Inode: 33799631 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2018-09-25 11:35:24.036354277 -0400
Modify: 2017-08-02 14:11:53.000000000 -0400
Change: 2017-08-14 09:17:09.936638043 -0400
Birth: -
Ну возьмите at, chfn/chsh, crontab, su, mount/umount или десятки других. Замена в пинге сьюда на capabilities никак не убирает остальные suid-бинарники.
Что за наф?! Это заем бы mount'у быть suid? Чтобы всякие левые рожи могли все перемонтировать как им удобно и систему поизящнее ломануть?
Вывод: бежим на другое ядро, например>http://www.project-trident.org/download/
Trident-BETA3-x64!!!
Нет уж, к бздунам вы сами бегите.PS А это "x64" лишний раз почёркивает почитание бздунами Windows.
Дада, ибо правильно пишется - AMD64 :D.
> Нет уж, к бздунам вы сами бегите.Это родственники Дениски Попова.
> PS А это "x64" лишний раз почёркивает почитание бздунами Windows.
Смотрите дети, классические двойные стандарты лап4атых -- это вот так:
https://www.opennet.me/opennews/art.shtml?num=49321
> 23.09.2018 08:52 Проект WLinux развивает Linux-дистрибутив, нацеленный на использование в Windowshttps://www.opennet.me/opennews/art.shtml?num=45869
> 17.01.2017 12:18 Для запуска в Windows доступны окружения SUSE и openSUSEhttps://www.opennet.me/opennews/art.shtml?num=45151
> 15.09.2016 08:49 Arch Linux адаптирован для запуска в Windows
> Вывод: бежим на другое ядро, например
> http://www.project-trident.org/download/
> What is Project Trident?
> Project Trident is a desktop-focused operating system based on TrueOS. It
> uses the Lumina desktop as well as a number of self-developed utilities to
> provide an easy-to-use system that both BSD beginners and advanced system
> administrators can feel comfortable running 24⁄7.Отличное описание (да-да, цитированно полностью) из которого все становится понятно! (сарказм)
Чем оно отличается от Ъ-ОСи (которая после перехода на CURRENT, ZFS и выкидывания PBI стала совсем уж на любителя) и зачем вообще нужен еще один клон?
> Вывод: бежим на другое ядро, напримерРасчет на эффект неуловимого джо, чтоли? Linux то статическими анализаторами, фуззерами и кучей тестов пообвесили - и стали находить странные сценарии, когда в полнолуние високосного года даже палка оказывается стреляет. А в этом другом ядре хоть 10% от этих тестов? Или все дружно здят про мнимое качество кода, не подкрепляя это ничем кроме здежа?
> А в этом другом ядре хоть 10% от этих тестов?Да откуда? Никто там об этом, как обычно у бздюков и прочих бесперепрончатых, не слышал. Разве что самую малость что-то там обезъянничают:
https://scan.coverity.com/projects/freebsd
> On Coverity Scan since Feb 28, 2013
> Last build analyzed 2 days agofind /usr/src|grep -c test
11326
Я так понимаю, что в атакуемый сервант надо вкрутить памяти более 32Гб, а потом его пинать, да? :)
Мажоры должны страдать.
Имеющих более 32 Гб ОЗУ. расходимся.
Никто и не сомневался .. что новость не для активных участников форума... :)
Ну у меня с дюжину серваков с 200 Гб ОЗУ. Парочка даже просто лежит пыль копит.
Может, поднимешь на них OpenDNS, SearX или ещё что-нибудь такое? Люди поблагодарят хотя бы.
> Может, поднимешь на них OpenDNS, SearX или ещё что-нибудь такое?Пыльные, очевидно, в запасе и работать сейчас не должны.
Локальная уязвимость, я так понимаю, что можно проcто пройтись по серваку молотком, чем запихивать в него 32 гектара и взламать?
Лет 20 назад... подобные вопли можно было бы еще понять...но сейчас... ныть из - за 32 гигов оперативки.. домашние компы столько имеют...
32 свободных. Т.е. надо где-то 48. Ну и голую операционку. А вот зачем взламывать такой комп?
С другой стороны, если swap в zram, то надо немного меньше. :)
>сейчас... ныть из - за 32 гигов оперативкиПосле массового психоза канализации^Wвиртуализации... сколько сейчас не нарезанных на мелкие виртуалки/контейнеры осталось жирных серверов?
Они, есно, есть. Но полагаю, что это вменяемые люди и у них не хостинг.
Итого, риск от сей дыры на самом деле незначительный.
Плохо понимаешь. Имеется ввиду, что нужен локальный пользователь
можно взломать сервер виртуального хостинга, например.
И каким волшебным образом ты попадёшь на ноду?
через дырявый вротпресс
Ubuntu 12 уже не поддерживается. Скажите им кто-нибудь, пожалуйста.
Как отметил наш майнтейнер основного ядра,Сommit ff6f95dcf55d34def126a3c7aae3080af66eada7достаточно, чтобы эта дырка в альтовых бранчах была закрыта.
Author: Dmitry V. Levin <ldv@altlinux>
Date: Tue May 30 15:37:59 2017 +0000get_arg_page: limit argv+env strings size for suid/sgid binaries
https://lists.altlinux.org/pipermail/sisyphus/2018-October/3...