Компания Red Hat сообщила (https://securityblog.redhat.com/2014/12/10/analysis-of-the-c.../) об обнаружении в пакетном менеджере RPM опасных уязвимостей (CVE-2013-6435, CVE-2014-8118 (https://rhn.redhat.com/errata/RHSA-2014-1976.html)), позволяющих добиться выполнения кода злоумышленника при установке специально модифицированного пакета. Проблема усугубляется тем, что в процессе установки система верификации не выявляет модификации в архиве с мета-данными, т.е. злоумышленник может изменить корректно подписанный пакет.Изменения вносятся в архив с метаданными, содержащими информацию о версии, описание и другую сопутствующую информацию. Данные из архива распаковывается в отдельную директорию с временным именем. Проверка цифровой подписи осуществляется после полного завершения записи временного файла. Если подпись корректна, файл переименовывается в его реальное имя. При определённых обстоятельствах (CVE-2013-6435) в результате состояния гонки система может интерпретировать неверифицированный временный файл и выполнить указанные в нём команды (например, временный файл в /etc/cron.d может подхватить cron). Вторая уязвимость (CVE-2014-8118) проявляется из-за переполнения буфера в процессе обработки модифицированного заголовка архива CPIO, что также может быть использовано для выполнения кода атакующего при распаковке изменённых подписанных пакетов.
В качестве защиты от уязвимостей рекомендуется проверить цифровую подпись пакета до начала его установки. Уязвимости в основном представляют опасность при установке пакетов из сторонних источников, так как при прямой установке из штатных репозиториев RHEL и Fedora применяется шифрование TLS, которое защищает от подмены транзитного трафика. Обновления с устранением уязвимостей выпущены для RHEL (https://rhn.redhat.com/errata/RHSA-2014-1976.html) (5.x (https://rhn.redhat.com/errata/RHSA-2014-1974.html), 6.x (https://rhn.redhat.com/errata/RHSA-2014-1975.html) и 7.x (https://rhn.redhat.com/errata/RHSA-2014-1976.html)) и CentOS (http://lists.centos.org/pipermail/centos-announce/2014-Decem...). Для Fedora (https://admin.fedoraproject.org/updates/F21/security), SUSE (https://www.suse.com/support/update/) и openSUSE (http://lists.opensuse.org/opensuse-security-announce/2014-12/) обновление пока недоступно.
URL: https://securityblog.redhat.com/2014/12/10/analysis-of-the-c.../
Новость: http://www.opennet.me/opennews/art.shtml?num=41250
> злоумышленник может изменить корректно подписанный пакет.Энтерпрайзный обcирак, как положено - "хренсгоры может на ровном месте поиметь весь ваш энтерпрайз" :)
>> злоумышленник может изменить корректно подписанный пакет.
> Энтерпрайзный обcирак, как положено - "хренсгоры может на ровном месте поиметь весь
> ваш энтерпрайз" :)а нефиг ставить пакеты не пойми откуда, тогда и проблем не будет. И неожиданно ынтерпрайз оказывается тут не при чем :) А если уж и ставишь с репозитария Дядюшки Ляо, так сам себе буратино
> а нефиг ставить пакеты не пойми откуда, тогда и проблем не будет.ты только что одним махом обозвал всех, кто чинит уязвимости, дебилами. ты мегакрут.
>>> злоумышленник может изменить корректно подписанный пакет.
>> Энтерпрайзный обcирак, как положено - "хренсгоры может на ровном месте поиметь весь
>> ваш энтерпрайз" :)
> а нефиг ставить пакеты не пойми откуда, тогда и проблем не будет.
> И неожиданно ынтерпрайз оказывается тут не при чем :) А если
> уж и ставишь с репозитария Дядюшки Ляо, так сам себе буратиноКак ты проверишь что адрес http://mirror.centos.org приведет тебя не к Дяде?
> Как ты проверишь что адрес http://mirror.centos.org приведет тебя не к Дяде?речь вроде шла об Ынтерпрайз, т.е. RHEL, а у них там подписка и просто так левое зеркало тебе никогда не дадут ;)
>> Как ты проверишь что адрес http://mirror.centos.org приведет тебя не к Дяде?
> речь вроде шла об Ынтерпрайз, т.е. RHEL, а у них там подпискаСкажу по секрету, Центось второй после Дебиана серверный дистрибутив в продакшне(по крайней мере в вэбе) по маркетшаре. Был раньше, до 7 версии конечно.
> и просто так левое зеркало тебе никогда не дадут ;)
MITM?
DNS cache poisoning?
Не, не слышал.
> и просто так левое зеркало тебе никогда не дадут ;)А хакирь на проводе или роутере может быть и не в курсе таких допущений.
> а нефиг ставить пакеты не пойми откуда,Так соль в том что даже в пакетах с правильной подписью можно получить черти-что и это черти-что выполнится. Нормальный такой remote code execution.
> а нефиг ставить пакеты не пойми откуда, тогда и проблем не будет.Так это, проверка подписи пакета - это то что дает уверенность в том что это не фиг знает что, непойми откуда, а легитимный пакет от его авторов. А тут вдруг раз - и из пакета что-то выполняется ДО того как проверена подпись. EPIC FAIL.
> уж и ставишь с репозитария Дядюшки Ляо, так сам себе буратиноКак бы я не могу контролировать весь путь полета пакетов по сети от меня до серверов репки. На этом пути может оказаться кто-то недружелюбный. Так, потенциально.
> применяется шифрование TLS, которое защищает от подмены транзитного трафика.Ну конечно. А скольким ауторити по дефолту доверяет эта либа? В смысле, сколько народа может сертификат на "а я типа тоже сервер рхел" выписать?
> Ну конечно. А скольким ауторити по дефолту доверяет эта либа? В смысле, сколько народа может сертификат на "а я типа тоже сервер рхел" выписать?Fedora uses a whole-file hash chain rooted in a hash downloaded over TLS/SSL from a Fedora-run central server.
Вообще, в силу особенностей уязвимости файлы с официальных реп, когда их скачивают yum'ом ей не подвержены. А вот если кто-то вначале скачает по http, а потом поставит - даже через yum localinstall - теоретически можно нарваться
Вообще баги интересные. И даже понятно, почему rpm так делает - вначале распаковывает файлы как временные, потом считает контрольные суммы. Когда-то (давно) двухпроходная распаковка - один раз для контрольных сумм, второй раз уже чтобы реально ставить - была непозволительной роскошью (во времена, когда с CD ставили); а с тех пор механизм подсчета контрольных сумм стал более гибким, например временно "откатывающий" изменения из-за prelink перед подсчетом, и иметь два совершенно разных способа подсчета, один для установленных файлов, а другой "виртуально" по файлам в памяти тоже было бы черевато ошибкой.
Идеальным бы решением было бы, наверное, распаковка в какой-нибудь /tmp с проверкой там и последующим копированием в фс - но файлы нынче в пакетах большие, а tmp все чаще в оперативке.. В общем, тоже не слишком удобно. Но, кстати, (вроде) виндовый инсталлятор так делает. И ничего, пользователи как-то переживают.
и ведь казалось бы, всего-то дел: взять, да и подписать уже созданый архив. и распаковывать ничего не надо, и ЩАСТЬЕ. но это слишком лёгкий путь, так неинтересно.
>И даже понятно, почему rpm так делаетДа не, Леннарт в те годы еще пешком под стол ходил.
Что-то ходжу Насреддина вспомнил. Таракана нужно поймать и насыпать инсектицид на хвост. Ну, в смысле, бомбануть репозиторий и засунуть свой "патч".
Просто нужно использовать подписанный JAR, как в энтерпрайзной Java.
Подписывать любишь? А, ну да, у тебя же загрузчик вантуза тоже подписан.
Что-то я не видел, чтобы чуваки из FreeBSD распространяли sendmail в JAR-ах.
> Просто нужно использовать подписанный JARУ них RPM подписан, но им это не помогло: эти таланты умудрились запускать некоторые скрипты раньше чем закончится проверка подписи. Круто придумано :).
>> Просто нужно использовать подписанный JAR
> У них RPM подписан, но им это не помогло: эти таланты умудрились
> запускать некоторые скрипты раньше чем закончится проверка подписи. Круто придумано :).Ну запускали не они, а cron. Который, как бы, работает независимо.. Они в блоге пишут про API, который позволяет положить файл так, чтобы его никто не видел (флаг O_TMPFILE), но нужно ядро новее, чем в EL7 и сам распоследний glibc, которого тоже там нет.