Зафиксирована (https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d695...) атака на сеть серверов криптографических ключей, построенных на базе ПО SKS Keyserver (https://bitbucket.org/skskeyserver/sks-keyserver/src/default/). Атакующие воспользовались проблемой в протоколе OpenPGP, о которой известно уже более 10 лет, но которая неустранима без кардинальных изменений и до сих пор не применялась для осуществления реальных атак. В случае импорта с сервера атакованного OpenPGP-сертификата проблема приводит к нарушению работы окружения GnuPG у пользователя (зависание, делающее невозможным дальнейшую работу).
Суть атаки в размещении на серверах хранения открытых ключей большого числа подписей для сертификата жертвы. Спецификация OpenPGP даёт возможность пользователям добавлять цифровые подписи для произвольных сертификатов, подтверждая их владельца, но не регламентирует максимальное число таких подписей. Сервер ключей SKS допускает размещение в сети до 150 тысяч подписей на один сертификат, но GnuPG такое число подписей не поддерживает. Попытка загрузки атакованного сертификата приводит к трудно восстановимому нарушению нормальной работы GnuPG и других реализаций OpenPGP.В силу распределённого характера сети ключей предсказать на какие ещё сертификаты направлена атака невозможно до момента начала проявления сбоев при их обработке. Иными словами любой сертификат может быть атакован и эта атака проявится лишь тогда, когда начнутся сбои. Единственным способом защиты является полное прекращение использования серверов ключей, т.е. необходимо удаление настроек keyserver из gpg.conf и добавление строки "keyserver keys.openpgp.org" в конец файла dirmngr.conf. Если проблема уже проявилась, то если известен проблемный сертификат для восстановления работы достаточно его удалить из локального хранилища, а если сертификат не известен, то
возможно потребуется пересоздание хранилища сертификатов.
Рекомендация по полному прекращению использования существующих серверов ключей обусловлена тем, что пострадавшие в ходе атаки сертификаты не могут быть удалены из сети серверов ключей, а атакованные сертификаты невозможно отследить до проявления сбоя на стороне пользователей. Атака не может быть блокирована на уровне существующих сетей хранения ключей SKS в ближайшее время. В строй введён новый экспериментальный сервер ключей keys.openpgp.org, в котором реализована защита от подобных атак, но БД данного сервера заполняется с нуля, а сам сервер не входит в сеть серверов криптографических ключей.
Основная проблема в том, что одним из ключевых принципов ключей хранения являет то, что уже размещённый сертификат никаким образом не может быть удалён. Сертификаты и любую другую информацию можно только добавлять, но не удалять, чтобы оставалась цепочка для прослеживания всех действий и было невозможно подменить сертификат после его удаления. Более того, сервера криптографических ключей постоянно взаимодействуют между собой и осуществляют сверку своих баз для выявления возможных изменений или удаления сертификатов. Не существует единого эталонного сервера, на котором можно было бы удалить проблемные записи, все серверы равноправны, что делает задачу внесения архитектурных изменений крайне сложной.Маловероятно, что исправление, нарушающее данную концепцию, будет внесено на уровне протокола OpenPGP. В любом случае для исправления и обновления ПО на серверах и клиентских системах потребуется очень много времени. В ближайшем выпуске GnuPG ожидается добавление обходного пути для предотвращения сбоев. Внесению изменений в SKS (Synchronizing Key Server) мешает необходимость аккуратного изменения проверенного временем достаточно сложного алгоритма синхронизации. Задача усложняется тем, что SKS написан на достаточно специфичном языке OCaml и остаётся без сопровождающего - никто из остающихся в сообществе разработчиков не знает начинку настолько хорошо, чтобы безболезненно вносить фундаментальные изменения (в текущем виде в код вносятся лишь исправления ошибок, но в данном случает требуется переработка архитектуры).
В настоящее время приводящее к проблемам наводнение подписями сертификатов зафиксировано для двух известных участников сообщества OpenPGP (Robert J. Hansen (rjh) и Daniel Kahn Gillmor (https://dkg.fifthhorseman.net/blog/openpgp-certificate-flood...) (dkg)). Ожидается, что атака не остановится на двух жертвах и из-за простоты проведения атаки число проблемных сертификатов лишь будет расти со временем. Возможный размер ущерба от атаки пока трудно оценить.
URL: https://lists.gnupg.org/pipermail/gnupg-users/2019-June/0620...
Новость: https://www.opennet.me/opennews/art.shtml?num=51006
(чешет репу) неприятно...
Неприятно - не чеши (:
Не надо трогать сервера!Не надо прикасатся к алгоритмам!
Не надо прикасатся к ключам!!!
Надо увеличить максимальное число подписей ключа до 150 000 всего у одной программе - GNUpg !
Это просто дос атака на кейсервера?
На пользователей этих серверов. Импортировал сертификат и всё зависло. Повезёт если знаешь, из-за какого сертификата проблема, а иначе весь кейринг придётся пересоздавать по крупицам.
Подписи-шмодписи, зачем они? Т.е. я знаю зачем, но толку, если ты в глаза всё равно не видел никого из подписантов? А даже если и да, то это всё равно ничего не гарантирует.
вот кто-то и решил показать на практике, что вся эта секьюрить выеденного яйца не стоит.
> вот кто-то и решил показать на практике, что вся эта секьюрить выеденного яйца не стоит.А можно отгрузить Камаз свежайшего, из под коровок, прям под дверь и громко смеятся над несекьюрностью этих ваших дверей и замков!
> А можно отгрузить Камаз свежайшего, из под коровок, прям под дверь и громко смеятся над
> несекьюрностью этих ваших дверей и замков!ну если через дверь протечет - то несекьюрна, а если не - то, разумеется, дверь ок, но наличие отсутствия рва с крокодилами и подъемного моста - несекьюрно. (разгрузку в ров камаза предотвращает внешний вал и автоматические огнеметы, разумеется)
А так-то на камазе можно просто в дом въехать - необязательно даже через дверь.
Мне привези. У меня черви в саду голодают.
Это к кадырову он спец по откорму червей.
Из-под свинок лучше, оно крепче смердит
Тебя боевые чукчи угрозами заставляют использовать сервера ключей?
Простой пример: пакеты с подписями. А иначе можно установить что угодно. А атака вообще ни о чём и не задевает пользователей этих пакетов.
Как связаны пакеты с подписями и подписи самих ключей?
> Не существует единого эталонного сервера, на котором можно было бы удалить проблемные записи, все серверы равноправны, что делает задачу внесения архитектурных изменений крайне сложной.Аргументация, как при миграции скайпа на сервера, прям.
> Задача усложняется тем, что SKS написан на достаточно специфичном языке OCaml
Смузимжны не осилили.
>> Задача усложняется тем, что SKS написан на достаточно специфичном языке OCaml
> Смузимжны не осилили.ты-то, конечно, уже осилил бы - вот только щас-щас-щас, пехепешный скриптик доотладишь, и тут же побежишь исправлять SKS?
все же писателей на нескучных язычках без жесткого обоснования необходимости надо гнать из проектов, пока они маленькие.
Вот-вот!
Понапишут на непонятных фриковских языках а другим потом страдать.
Но это же можно и по-другому повернуть. Побегут на хайповый нодыжс, и написать ничего толкового на нём не написали и на тот софт что есть программистов нет. Как тебе такая точка зрения?
> Но это же можно и по-другому повернуть. Побегут на хайповый нодыжс, и написать ничего толкового на нём не написали и на тот софт что есть программистов нет. Как тебе такая точка зрения?Так это просто оборотная сторона медали. И те и другие пишут на модном в своём кругу языке, с одинаковым результатом.
> все же писателей на нескучных язычках без жесткого обоснования необходимости надо гнать из проектов, пока они маленькие.И использовать проект на правильном и скучном языке, только немного нереализованный? Или в котором 100500 дырок?
Напоминая, что сама проблема НЕ в SKS и предыдущее, скромно опущенное предложение
> мешает необходимость аккуратного изменения проверенного временем достаточно сложного алгоритма синхронизациинамекает, что лучше уж так, чем куча "улучшайзеров", которые наулучшали бы уже давно все к такой-то маме.
> И использовать проект на правильном и скучном языке, только немного нереализованный? Илишансов реализоваться тоже больше у проектов на банальном си - просто в виду большего количества разработчиков, способных именно к разработке, а не тривиальным исправлениям.
> в котором 100500 дырок?
а волшебный ocaml от них волшебно защищает? (а, ну да - их никто там найти не может)
> Напоминая, что сама проблема НЕ в SKS и предыдущее, скромно опущенное предложение
проблема яйца выеденного не стоит, добавить лимит на число подписей.
Очевидно что уже два десятка - перебор и ни для чего не нужно. А проблем не будет и при сотне.>> мешает необходимость аккуратного изменения проверенного временем
перевожу: написанного на том же нескучном язычке и никем не понимаемым - как-то проработал двадцать лет, хз как.
> достаточно сложного алгоритма синхронизации
да уж
> намекает, что лучше уж так, чем куча "улучшайзеров", которые наулучшали бы уже
лучше бы его поломали пока он был маленький - чем вот так, в любой момент ВСЕ автопроверялки подписей могут превращать свои проекты в тыкву.
>> И использовать проект на правильном и скучном языке, только немного нереализованный? Или
> шансов реализоваться тоже больше у проектов на банальном си - просто в
> виду большего количества разработчиков, способных именно к разработке, а не тривиальным исправлениям.Шансов подвергнуться остракизму на опеннете - несомненно.
А ссылочку на вашу реализацию тех (или вообще, любых) времен можно?
>> в котором 100500 дырок?
> а волшебный ocaml от них волшебно защищает? (а, ну да - их
> никто там найти не может)Список проблем и уязвимостей в SKS - в студию!
>> Напоминая, что сама проблема НЕ в SKS и предыдущее, скромно опущенное предложение
> проблема яйца выеденного не стоит, добавить лимит на число подписей.
> Очевидно что уже два десятка - перебор и ни для чего не нужно. А проблем не будет и при сотне.Увы, оне не опеннет, у них видимо нет своих знатоков и экспертов-по-всему ((
А ваш патч и умный совет в рассылке наверное не захотели принять, не так ли?
> Список проблем и уязвимостей в SKS - в студию!вон, в начале страницы. Ах, ну да, это ж не уязвимость и не в SKS.
Жаль что вся основанная на них структура вышла из доверия и пользоваться ей нельзя, но никакой уязвимости, вообще никакой.
>> Список проблем и уязвимостей в SKS - в студию!
> вон, в начале страницы. Ах, ну да, это ж не уязвимость и
> не в SKS.Расскажите нам, какое слово в
This attack exploited a defect in the OpenPGP protocol itself in order to "poison" rjh and dkg's OpenPGP certificates
вам не понятно?> Жаль что вся основанная на них структура вышла из доверия и пользоваться
> ей нельзя, но никакой уязвимости, вообще никакой.А кто вам лично не давал сделать правильную реализацию на правильном ЯП еще 20 лет назад? Необходимость раздавать на опеннете ЦУ для других проектов?
> Расскажите нам, какое слово веще двести миллионов раз повторите мантру "это не в sks, это не в sks", перед вами появится харя Кришны. Выслушайте ее внимательно, и немедленно отправляйтесь в указанном направлении.
> А кто вам лично не давал сделать правильную реализацию на правильном ЯП еще 20 лет назад?
вероятно, то что мне лично нафиг не нужен web of shitty-trust, и вдобавок я верю только в одну реализацию pgp - ту, которая стараниями засланных казачков уничтожена в этом вашем интернете полностью.
к сожалению, работать приходится из того г-на, которое нате на лопате.
>все же писателей на нескучных
>язычках без жесткого
>обоснования необходимости
>надо гнатьТочно. Всез этих пэхапэшников надо гнать их профессии, чтобы они не множили завалы дырявого, неподдающегося отладке гуано.
> все же писателей на нескучных язычках без жесткого обоснования необходимости надо гнать
> из проектов, пока они маленькие.Вообще-то ML это классика. Его даже программисты из Микрософт, на которых тут принято показывать пальчиком, осилили и создали свой F с диезом и фреймворками.
проблема, как видите, в том, что разобраться даже в сравнительно тривиальной программе на этой классике - никто не может, а те трое программистов из microsoft, к сожалению, заняты на работе.
> проблема, как видите, в том, что разобраться даже в сравнительно тривиальной программе
> на этой классике - никто не можетКогда разбираться то? Надо строчить каменты, критикуя трёхфакторную идентификацию, которую внедрила microsoft, и предлагая всё переписать на Rust.
Вообще-то программистов на камле дофига и больше. Его, как и SML в институтах преподают.Но, вообще, надо быть отчаянно серым человеком, чтобы никогда не слышать о, скажем, INRIA.
ML - это база, на которой стоит Haskell, который разрабатывается с серьёзной поддержкой MS. Кроме того, если хоть чуть-чуть интересоваться софтом для верификации программ, сразу же попадаешь в чудесный мир Coq, Why3, и т.д., и т.п.В общем, мы с сотрудниками замечательно поржали. Минский, наверное, тоже. Кстати, 27го будет Jane Street tech talk, наверно там вспомнят.
Не надо трогать сервера!Не надо прикасатся к алгоритмам!
Не надо прикасатся к ключам!!!
Надо увеличить максимальное число подписей ключа до 150 000 всего у одной программе - gnupg !
Значит необходимо добавить в Gnupg патч добавляющий поддержку подобного количества ключей, и все дела. Раздули проблему на ровном месте. )))
окей, сколько раз тебе подписать ключ, чтобы он в память твоего "десктопа" просто не влезал? Мне не жалко - у меня зомбонет большой.
больше 150к ты не сможеш, тут действительно нужно только клиентскую часть обновить чтобы решить проблему.
> Значит необходимо добавить в Gnupg патч добавляющий поддержку подобного количества ключей, и все дела. Раздули проблему на ровном месте. )))Скоты хотят испортить алгоритмы и базы ключей! Видять скотам они теперь сильно мешать начали...
Не надо трогать сервера!
Не надо прикасатся к алгоритмам!
Не надо прикасатся к базам ключей!!!
Надо увеличить максимальное число подписей ключа до 150 000 всего у одной программе - gnupg !
Не вижу сложности, достаточно научить клиенты удалять записи с большим количеством ключей. Для этого можно написать фильтр который восстанавливает работу клиентской системы.
кульхакер: не вижу сложности подписать ключи всех убунтят и великого Линуса по пять тыщ раз - пусть твоя поделка их удаляет нахрен.
Не работают апдейты ни одного дистрибутива, полагающегося на keyservers? Так лохам и надо!
А в каких дистрибутивах апдейты полагаются на keyservers?
> А в каких дистрибутивах апдейты полагаются на keyservers?да вроде уже во всех? Есть какой-то набор ключей на дистрибутивных носителях, но никто не обещал что их не меняют - дальше добрый apt или кто у тебя там просто спрашивал "тут новый ключ приехал - всосать?!"
У дебиана свой сервер для ключиков.
думаешь, что-то мешает прямо там и подписать 149999 тыщ раз? ;-)
То, что тебя туда никто не пустит?
Апдейты ключей, внезапно, приезжают в пакетах. Ну для apt, по крайней мере. Всякие шляпы просто спрашивают юзера: "Тут репа каким-то незнакомым ключом подписана, принять?" Юзер не глядя жмёт y, ключ, загруженный с зеркала, импортируется, всё секурно, все довольны.
> Ну для apt, по крайней мере.для как раз apt пришлось открывать порты для keyservers - иначе, кажись, с очередным апдейтом бубунточки возникли сложности.
У шляпы да, там нет встроенного в rpm или dnf ненужного bloatware, но д'Эффехтивным хочется сесурити, а огорчать пользователя ненужно-знанием не хочется. Поэтому "принять? [Y|Да|Ok|Confirm|All]" - и никакого лишнего траффика, угрожающего безопастносте корпоративных сетей. У suse, помнится, аналогично.
Вот только не с keyservers ли их сборочная система эти самые ключи берет? ;-)
Знаешь, вот примерно в этот момент я начинаю думать, что идея пацанов OpenBSD с их signify (который просто проверяет ключи, без web-of-trust) это не самая плохая идея для дистрибутивов.
а как он их проверяет-то, если "никому верить нельзя"? Просто спрашивает у папаши Мюллера?
Публичный ключ для проверки лежит в /etc/signify/openbsdXY-release.pub и на сайте/твитторе/мастодоне/etc.
Только личная встреча и обмен ключами. На том стоимъ!
а анализ ДНК-то у встреченных берешь, или так, по старинке, на скан паспорта вся надежда?
Тоже не выход. Например, однояйцевый близнец и ДНК у него та же.
Личная встреча, какой нах скан? Только оригинал, только хардкор.
так откуда ты знаешь, что под маской не фантомас?
> Сервер ключей SKS допускает размещение в сети до 150 тысяч подписей на один сертификат, но GnuPG такое число подписей не поддерживаетПфф, тоже мне проблема... ну пусть ограничат 10 тысячами.
> предсказать на какие ещё сертификаты направлена атака невозможно до момента начала проявления сбоев при их обработке
А цикл на сервере по всем ключам сделать и посчитать подписи что мешает? Администраторов способных написать `for k in` уже не осталось?
> При этом в обозримом будущем атака не может быть блокирована на уровне уже существующих сетей хранения ключей SKS.
Какая то странная попытка раздуть из мухи слона.
Теперь мы знаем, что не осталось людей, которые "знает начинку настолько хорошо, чтобы безболезненно вносить фундаментальные изменения". Есть только группа людей, которые обслуживают бог-машину, пока она не сломается.Как бы всегда казалось, что как и с ОТО, на свете почти нет людей, ясно понимающих что как на самом деле работает все от и до в этих GPG.
Что помешало на этих кеу серверах уменьшить макс число новых ключей до допустимого gnupg..
ЧТо-то из области технологической религии. А попросту никто не хочет брать на себя отвественность, так как боитья что сломается еще что-то. Сейчас будут собирать комитеты, рабочие группы и совещаться, совещаться...
Не освещатся, а внедрять незаметный изян в идеальный алгоритм.Сервер ключей трогать не надо!!!
Алгоритмы трогать не надо!!!
Виснет gpg на стороне НЕКОТОРЫХ пользователей. Следовательно проблему надо исправить всего то увеличив лимит допустимых подписей ключа в _одной_ КЛИЕНТСКОЙ программе gpg!
> Что помешало на этих кеу серверах уменьшить макс число новых ключей до допустимого gnupg..Не надо трогать сервера!
Не надо прикасатся к алгоритмам!
Не надо прикасатся к ключам!!!
Надо увеличить максимальное число подписей ключа до 150 000 всего у одной программе - gpg !
Но ведь тебе не нужны 100500 подписей ключа. Тебя интересует весьма небольшое множество - юзкейс же я хочу проверить подписан ли этот ключ теми ключами, которым я доверяю, а не всеми вообще, а это уже, по всей видимости, требует потрогать сервера чтобы они в это умели вместо того чтобы вываливать на клиента всё и сразу. Ну или хотя бы итераторы изобрести, чтобы можно было порциями подписи скачивать, пока не найдётся удовлетворяющая критерию или подписи не кончатся.
Одобрям, не ну правда же, 10 лет не исправляли и получили пинка под зад.
мудрое решение проблемы — чтобы размещать подписи, сколько бы их ни было, мог бы размещать только владелец ключа.пока что это только лишь знак хорошего тона, хочешь подписать ключ — подпиши и отправь зашифрованное письмо владельцу, а уж он сам выложит на сервер.
сделать такую практику обязательной — всего и делов то.
На стороне пользователя можно придумать алгоритм гарантирующий защиту :0. Допустим хранилище содержит только верифицированные, подписанные, доверительные публичные ключи. 1 ваш секретный ключ.
1. Бекапим папку ${HOME}/.gnupg
cp -pr ${HOME}/.gnupg ${HOME}/.gnupg_backup-20190708
2. Бекап публичных ключей:
gpg --armor --export --output pgp_public_keys-20190708.pubПросмотр бекапа:
gpg --show-keys pgp_public_keys-2019.pubЭтими ключами можно обмениваться при личной встрече!
3. Теперь можно делать import ОДНОГО открытого ключа с сервера.
4. Смотрим импортированный ключ
gpg -- fingerprint5. Верифицируем загруженный ключ и все ключи в нашей базе на сервере ключей.
Если не подвисло значит в нашей базе нет атакованных ключей.
Если подвисло, значит как минимум один ключ атакован.
Востанавливаем с бекапа ключи по одному и повторяем верификацию принудительно после каждого добавленного ключа.
Если верификация прошла ключ помещаем в белый список.
После импорта атакованого ключа система подвиснет.
Знаем ещё один атакованный ключ, вносим его в черный список, который при восстановления хранилища из бекапа не подгружаем.
Загруженную базу ключей с белого списка и принудительно верифицируем.
Если верификация не прошла, анулируем белый список и начинаем сначала, по одному ключу восстанавливать с бекапа.
Продолжаем пока все ключи с бекапа не будут востановлены и верифицированные, за исключением созданного чёрного списка.Этот алгоритм необходимо использовать при импорте очередного публичного ключа.
В случае большого числа атакованный ключей, чёрный список разрастется и верификация через сервера будет невозможна.
Ключи в чёрном списке можно использовать для верификации в крыптографии, для верификации в офлайне руками, они могут быть импортированы в рабочей системе, но не могут в ней находится при верификации ключей с серверов ключей!