В поисках LD_PRELOAD

[kunix]

Я бы искал во внутренних структурах ld-linux*.
Собственно, именно он и занимается обработкой LD_PRELOAD и аналогичной фигни.
Поэтому факт загрузки по LD_PRELOAD чего-то оставит в нем следы.

[Inobelar]

Спасибо за труд! Статья впечатляющая, чем дальше читал — тем сильнее она будоражила воображение.

Но всё-же, выглядит как вечная борьба меча и щита. Не хватает резюме — есть ли универсальное гарантированное не-заменяемое хаками обнаружение LD_PRELOAD? Если нет, то почему?

[Goron_Dekar]

Нет, универсальных методов не бывает, ну кроме разве что статической линковки ключевых функций, что мешает переносимости кода.
И причина этому — сам механизм динамической линковки. Мы имеем возможность в юзерспейсе динамически использовать функционал другой программы. И это положительно сказывается на переносимости нашей программы. Мы даём возможность окружению самому сообщить нам, откуда можно дёрнуть какой-нибудь open() или rand(). Если завтра найдут баг в open() и выпустят патч, то нашу программу не надо будет пересобирать, она даже не узнает, что open() изменили. Но в этой инкапсуляции есть и беда: если это будет не патч безопасности, а злонамеренные изменения, то наша программа ровно так же не заметит этих изменений. Мы не можем заранее отличить плохие изменения от хороших.

[fougasse]

Если найдут баг в open() — то можно вешать ласты на гвоздь.

[Goron_Dekar]

Ну тут такое…
Хуже, если не найдут :)

Скрытый текст

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

[qw1]

Если машина, на которой запускается программа, контролируется атакующим, он может внести изменения в libc, или даже в kernel, перекомпилировать, и добиться изменения поведения без каких-либо LD_PRELOAD.

[9660]

Для использования LD_PRELOAD не нужно контролировать машину. Достаточно иметь туда доступ.

[ip1981]

А теперь то же самое на Солярисе, БэЭсДэ...

[MShevchenko]

да легко.