И почему не Джумла?:)
...он с любопытством ковырялся в пойманном проклятии, всё ещё колебавшемся на кончике палочки, вытягивал пальцами красные искры и отщёлкивал их в стороны, разбирая заклинание на части, словно детскую игрушку-конструктор...
Домен зареган 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 с лишним лет сайт не столько служил его заказчику, сколько помогал зарабтывать бабло целой пачке злоумышленников.
Сегодня я всего лишь копаюсь в коде этого угробища.
no subject
В виндах не надо никаких процессов запускать, ImpersonateLoggedOnUser имеется. В линуксах наверняка есть аналог.
no subject
И это правильно, потому что если позволить прыгать туда-сюда, то в адресном пространстве накопятся данные, полученные от имени разных пользователей (включая, например, логин-пароль), и это похерит всю безопасность, за которую сражался Ку.
Поэтому практика применения setuid() включает выполнение минимум одного exec() на каждый setuid() - либо незадолго до, либо сразу после.
login, sudo и su работают по схеме "сразу после" - авторизовали юзера, setuid() и сразу exec() команды, которая уже будет выполняться от юзера. При этом в памяти процесса гарантированно не будет данных, которые были в памяти родителя-рута, и которые юзеру знать не положено.
А всякие почтовки, веб-сервера и т.п., особенно когда надо SSL, предусматривают возможность некоторые данные прочесть под рутом и сохранить после setuid() - у них, соответственно, exec(), минимальная инициализация под рутом, setuid(), и только потом остальная инициализация.