И почему не Джумла?:)

[qkowlew]

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

Домен зареган 1 ноября 2013.

Сайт залит на хостинг 6 ноября 2013.

8 ноября 2013 в него добавлено минимум три закладки формата "приход с запросом POST на определённый URI сотворяет и исполняет PHP код" и одну формата "создаём ежеминутное задание в кронтаб, исполняющее созданный 1.sh который творит бинарные файлы libworker.so и /usr/bin/host, причём их содержимое зависит от архитектуры. :)

В 2014 и в 2015 годах, явно по случаю продления домена, админы хостинга просыпались и обращали внимание, что сайт что-то делает не то. На тему чего его блокировали и частично очищали от говна (но часть говна, особенно бинарник /usr/bin/host, жила неизменно).

Cледы этого - в тикет-системе хостера, с датами блокировок

24 января (неизвестно, правда, каким кодом, и мне откровенно лень искать) в корне сайта было нагенерено около 80 тысяч статических .html, представляющих собой фишинговые страницы, имитирующие страницы магазинов японоязычного содержания, при этом сделанные как "якобы вы сюда пришли с результатов поиска в Yahoo", но формочки при этом отправляют POST с интересными данными на разные странные адреса.

25 января хостер написал ругательство - исправьте в течение недели а то заблокируем.
Примерно вчера заблокировали.

Иными словами, в течение 2 с лишним лет сайт не столько служил его заказчику, сколько помогал зарабтывать бабло целой пачке злоумышленников.

Сегодня я всего лишь копаюсь в коде этого угробища.

Comments

[besm6.livejournal.com]

Никаких LoggedOn. В любого юзера, только при наличии соответствующей capability (в норме она есть только у рута), и главное, это билет в один конец.

И это правильно, потому что если позволить прыгать туда-сюда, то в адресном пространстве накопятся данные, полученные от имени разных пользователей (включая, например, логин-пароль), и это похерит всю безопасность, за которую сражался Ку.

Поэтому практика применения setuid() включает выполнение минимум одного exec() на каждый setuid() - либо незадолго до, либо сразу после.

login, sudo и su работают по схеме "сразу после" - авторизовали юзера, setuid() и сразу exec() команды, которая уже будет выполняться от юзера. При этом в памяти процесса гарантированно не будет данных, которые были в памяти родителя-рута, и которые юзеру знать не положено.

А всякие почтовки, веб-сервера и т.п., особенно когда надо SSL, предусматривают возможность некоторые данные прочесть под рутом и сохранить после setuid() - у них, соответственно, exec(), минимальная инициализация под рутом, setuid(), и только потом остальная инициализация.