Сломал систему на сервере

«Почему», понятно, но «зачем»?

Конечно же, экспериментировать нужно в контейнере. Но я был уверен что sudo и mv нельзя сломать.

Раскрутка стека останавливалась на libpthread, а у меня на домашнем не останавливается, наверное собрана с другими флагами. Короче, был на 99% уверен что не сработает, но ради того 1% попробовал скопировать свою либу на сервер.

завтра накачу новый образ

Зачем? Просто загрузись с внешнего носителя и почини.

Если есть физический доступ – загрузись с флешки, примонтируй раздел и верни библиотеке прежнее имя. Даже чрут не нужен. И времени нужно гораздо меньше, чем на переустановку.

И да, зачем так играться с системой? :)

История из серии «Remove system32 @ make your PC faster»

было бы логично, чтоб /bin/mv был собран статически и был работоспособен всегда, а /usr/bin/mv был динамическим. Но бардак есть бардак! :-)

UNIX-помойку (FHS) никогда нормально никто не проектировал и не продумывал варианты отказоустойчивости при повреждениях.

Следующий этап chmod -x -R /?

а вот если бы ты использовал booty-систему, которая загружается в tmpfs, — уже настроенная и готовая к работе, то её починка бы заключалась в нажатии одной кнопки RESET, чтобы вернуть систему в исходное состояние. так победим!

У него была цель сломать систему – он сломал, а ты тут со своими задница-системами лезешь.

Как в бородатом анекдоте:

- Мой друг сервер сломал.
- Он хаккер?
- Нет, он мудак.

хорошо что важных данных там не было

вот так вот работаешь-работаешь, а потом оказывается что ты не важен, даже поломаться, и никто не заметит

ахвх

Небось наркоман (с)

Linux уже на Марсе, а чего добился ты?

Оставь работу пакетного менеджера пакетному менеджеру.

Ну по идее /sbin был для статических бинарников.

И есть ещё во многих дистрибутивах статически собранный busybox, который может помочь в подобной ситуации. На busybox можно даже нацепить setuid, потому busybox в большинстве сборок сбрасывает права до текущих. В итоге получается единая замена для всех базовых утилит, включая su.

при повреждениях

kek

LD_PRELOAD

su? Любой другой бинарь root и с suid битом?

было бы логично, чтоб /bin/mv был собран статически и был работоспособен всегда, а /usr/bin/mv был

Ага, а потом когда ты пишешь mv то чтобы хз что выполнялось.

И эксплойты тоже классные начнутся.

UNIX-помойку (FHS) никогда нормально никто не проектировал и не продумывал варианты отказоустойчивости при повреждениях.

было бы логично, чтоб /bin/mv был собран статически и был работоспособен всегда, а /usr/bin/mv был

Чем в отличии от системд хорош классический инит, так в том числе и тем что достаточно рукастый человек такие огрехи может сравнительно легко исправить, можно даже сказать что х наличие ил отсутствие являются делом вкуса.

Ну шо тут сказать!? ССЗБ.

я не знаю, зачем вы это делаете, но раз на лоре нечем больше заняться, кроме половых извращений...

bewitched ~ # locate libpthread
/usr/lib/libpthread_p.a
/usr/lib/libpthread.a
/usr/lib/libpthread.so
bewitched ~ # mv /usr/lib/libpthread.so /tmp/
bewitched ~ # ls
INS@BagM
bewitched ~ # mv /usr/lib/libpthread* /tmp/
bewitched ~ # ls
INS@BagM
bewitched ~ # sudo 
usage: sudo blablabla...
usage: sudo blablabla...
bewitched ~ # mv /tmp/libpthread* /usr/lib/
bewitched ~ # uname -a
FreeBSD bewitched 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri Apr  9 04:24:09 UTC 2021     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 Intel(R) Xeon(R) CPU E5-2407 0 @ 2.20GHz FreeBSD

Без libpthread даже systemd не запустится.

Уверен, у тебя на сервере уже есть статический BusyBox как раз для таких случаев, ты просто не умеешь им пользоваться.

/bin/sh и вперёд…

он без libdl и неявных зависимостей (только libc). По идее вообще должен быть статиком, но в современных дистрах увы, но нет

mv в /sbin по-моему никогда не было. вообще набор утилит в /sbin лично для меня не очень понятный. в дебиан, например, там лежит gnome-menus-blacklist (!). в общем имно бардак.

Я пробовал busybox из /sbin, но su там не было, или я проглядел.

Вполне может быть. В любом случае физического доступа нет, а ssh возвращает ошибку.

Странно что libpthread, это же потоки. Зачем mv потоки? Понятно еще glibc, но потоки для sudo, ls и mv это странно.

Да, в таком случае запущенная система без физического доступа практически бесполезна, можно было починить только до разрыва соединения.

selinux и всякая интерактивщина (спросить подтверждения в консоли) может тянуть. там контексты безопасности, тут ввод/вывод в несколько потоков.

Думается все coreutils собираются тупо с -lpthread .

это же потоки.

функции потоков лежат в libc. libpthread оно

Historically, functions in this library provided POSIX threading support. See standards(5). This functionality now resides in libc(3LIB).

This library is maintained to provide backward compatibility for both runtime and compilation environments. The shared object is implemented as a filter on libc.so.1. New application development needs to specify -lpthread only to obtain POSIX semantics for fork(2) that assumes the behavior of fork1(2) rather than the default behavior that forks all threads.

а все способы просовывания переменной в судо были испробованы ? У меня хардкод выводит содержимое переменной корректно.

sudo HELLO=«foobar» echo $HELLO

В следущий раз разверните какую-нибудь мин сборку в chroot и примонтируйте туда весь корень mount –bind / /chroot/blabla. Если что-то сломается, то из чрута можно это оперативно починить.

А еще в некоторых дистрибутивах были статические sh, busybox и т.д. специально для таких случаев :)

Мне нужно было и внутри и снаружи LD_PRELOAD=... sudo LD_PRELOAD=... mv

Сам sudo не работал.

sudo: error while loading shared libraries: libpthread.so.0

https://stackoverflow.com/questions/41378462/how-to-set-ld-preload-for-su-or-sudo

В archlinux

$ ldd /bin/mv
	linux-vdso.so.1 (0x00007ffdae90e000)
	libacl.so.1 => /usr/lib/libacl.so.1 (0x00007ff53a2fa000)
	libattr.so.1 => /usr/lib/libattr.so.1 (0x00007ff53a2f2000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007ff53a126000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ff53a344000)

А в убунте

$ ldd /bin/mv
        linux-vdso.so.1 (0x00007ffdc07da000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f0004243000)
        libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f0004238000)
        libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f0004230000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f000403e000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f0003fae000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0003fa8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f000429c000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0003f83000)

sudo в обоих системах зависит от libpthread

вобщем, на SO советуют добавлять экспорт в ~/.bashrc либо сделать такой алияс I

alias sudo=‘sudo PATH=«$PATH» HOME=«$HOME» LD_LIBRARY_PATH=«$LD_LIBRARY_PATH»’

или вот еще env какой-то:

alias sudo=‘sudo env PATH=$PATH VAR1=SOME_VALUE VAR2=SOME_VALUE…’

ln без него работает? Сделай симлинк. Хотя это тоже бесполезно.

вышепреведенные варианты у меня не сработали, а экспорт сработал, по крайней мере с echo

export LD_LIBRARY_PATH=«$LD_LIBRARY_PATH:/tmp» && sudo echo $LD_LIBRARY_PATH

ln без него работает? Сделай симлинк.

cat, chmod chown тоже так-же чтобы восстановить побитый libpthread.so…

но ТС порвал сессию и более у него нифика нет, кроме возможно «login:», да и то это временно :-(

А если симлинк в какую-нибудь ~/lib и туда делать LD_LIBRARY_PATH как советуют выше? Чисто интересно, жаль, если ТС уже сделал логаут.

А если симлинк в какую-нибудь ~/lib и туда делать LD_LIBRARY_PATH как советуют выше? Чисто интересно, жаль, если ТС уже сделал логаут.

до странного, но чем чёрт не шутит, может прокатить scp. Интерактивный шелл ведь ненужен, bash полностью не раскручивается и возможно не потянет libpthread через libld.

ведь в загруженных процессах, линки на libpthread правильные пока, на неубитую версию.

Да, это работает, но проблема в том что sudo сам не работал. Он не спрашивал пароль, он валился с ошибкой. Потому что LD_LIBRARY_PATH на него не влияет, это специально сделали ради безопасности.

cat, chmod chown всем нужны права. А sudo не работает и без него непонятно как получить права, я даже пробовал это скачать https://github.com/remram44/static-sudo не работало, с этой ошибкой https://github.com/remram44/static-sudo/blob/master/rpzsudo.c#L61 пробовал разные комбинации uid, gid.

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

может тогда просто su ?

>ldd `which sudo`
        linux-vdso.so.1 (0x00007ffe83dd3000)
        libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007fa1ff3c0000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fa1ff395000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fa1ff390000)
        libsudo_util.so.0 => /usr/lib/sudo/libsudo_util.so.0 (0x00007fa1ff371000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa1ff187000)
        libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007fa1ff17f000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fa1ff0ed000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa1ff0e7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa1ff438000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa1ff0c5000)
>ldd `which su`
        linux-vdso.so.1 (0x00007ffe41ce4000)
        libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f1c6e8eb000)
        libpam_misc.so.0 => /lib/x86_64-linux-gnu/libpam_misc.so.0 (0x00007f1c6e8e6000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f1c6e8e1000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1c6e6f7000)
        libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007f1c6e6cb000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1c6e6c5000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f1c6e92d000)
        libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007f1c6e6bb000)
>

у него нет libpthread в зависимостях