https://www.opennet.ru/openforum/vsluhforumID3/115292.html Исследователь безопасности Max Justicz, известный выявлением уязвимостей в репозиториях Packagist, NPM и RubyGems, опубликовал (https://justi.cz/security/2018/09/13/alpine-apk-rce.html) информацию о новой критической уязвимости в пакетном менеджере APK, применяемом в дистрибутиве Alpine Linux (используется по умолчанию для контейнеров Docker). Уязвимость несколько дней назад уже устранена (https://git.alpinelinux.org/cgit/apk-tools/commit/?id=6484ed9849f03971eb48ee1fdc21a2f128247eb1) в APK, а проект Alpine Linux выпустил (https://alpinelinux.org/posts/Alpine-3.8.1-released.html) обновление 3.8.1, в который включено данное исправление.<br><br><br>Атакующие, имеющие возможность совершить MITM-атаку или изменить пакеты на зеркале, могли подменить загружаемый пользователем apk-пакет и инициировать выполнение своего кода в системе c правами root. В Alpine Linux при доступе к штатным репозиториям по умолчанию не применяется TLS-шифрование канала связи, а используется только верификация целостности и источника пакета по https://www.opennet.ru/openforum/vsluhforumID3/115292.html#26 Mon, 01 Oct 2018 07:29:42 GMT &gt;интересно, как в этом плане обстоят дела у apt/dnf/zypper<br><br>предсказуемо хуже. Поиск по базе CVE в помощь.<br> https://www.opennet.ru/openforum/vsluhforumID3/115292.html#25 Mon, 01 Oct 2018 04:46:58 GMT &gt; У dnf/zypper в их родной среде должно быть меньше проблем, так как <br>&gt; rpm это не матрёшка из tgz/txz, а специфичный формат, содержащий подпись <br>&gt; в заголовке и, если я правильно понял, подписывающей cpio-payload, а не <br>&gt; файлики внутри по одному.<br><br>Ещё бы тебе уяснить, что на подписи отдельных пакетов, если таковые вообще имеются, никто и никогда не смотрит, потому что достаточно один раз проверить подпись репозитория, а дальше уже просто сверять хеш пакета с проверенным. И это общий подход для дистров, что для deb, что для rpm.<br> https://www.opennet.ru/openforum/vsluhforumID3/115292.html#24 Thu, 27 Sep 2018 15:42:55 GMT Лучше. За годы развития их все-таки в целом отучили от детских болезней. Тот же apt+dpkg вообще ничего распаковывать не будет если подпись или хэш кривые. До этого дело просто не дойдет.<br> https://www.opennet.ru/openforum/vsluhforumID3/115292.html#23 Mon, 17 Sep 2018 00:03:02 GMT ...стукнули буквы с квэрти, это самая ужасная новость за пол ночи...<br> https://www.opennet.ru/openforum/vsluhforumID3/115292.html#22 Sun, 16 Sep 2018 18:58:21 GMT в след раз почитай про сабж прежде, чем начнешь быковать.<br> https://www.opennet.ru/openforum/vsluhforumID3/115292.html#21 Sun, 16 Sep 2018 18:51:00 GMT они и так руту принадлежат<br> https://www.opennet.ru/openforum/vsluhforumID3/115292.html#20 Sun, 16 Sep 2018 16:56:06 GMT Перднуть. А разве не так?<br> https://www.opennet.ru/openforum/vsluhforumID3/115292.html#19 Sun, 16 Sep 2018 08:12:42 GMT &gt; Это значит, что пакетные менеджеры следует разбивать на часть, которая принимает, распаковывает, <br>&gt; проверяет КС и часть, которая на самом последнем этапе помещает прошедшие <br>&gt; проверку файлы в ФС ОС. Первая часть должна перед началом работы <br>&gt; сменить владельца процесса на какого-нибудь совсем бесправного пользователя.<br><br>А почему нельзя сделать, чтобы системное дерево и файлы принадлежало пользователю типа rootfs?<br>Чтобы никто кроме rootfs и root не мог изменить файлы. <br> https://www.opennet.ru/openforum/vsluhforumID3/115292.html#18 Sun, 16 Sep 2018 06:55:23 GMT Это значит, что пакетные менеджеры следует разбивать на часть, которая принимает, распаковывает, проверяет КС и часть, которая на самом последнем этапе помещает прошедшие проверку файлы в ФС ОС. Первая часть должна перед началом работы сменить владельца процесса на какого-нибудь совсем бесправного пользователя.<br>