Представлено (http://permalink.gmane.org/gmane.org.fsf.announce/2003) корректирующее обновление пакета GnuPG 1.4.14 (http://gnupg.org/) (GNU Privacy Guard) и библиотеки Libgcrypt 1.5.3 (http://permalink.gmane.org/gmane.org.fsf.announce/2002) с реализацией компонентов, лежащих в основе механизмов шифрования, применяемых в GnuPG 2.0. В указанных выпусках устранена интересная уязвимость (http://eprint.iacr.org/2013/448), позволяющая восстановить содержимое закрытого RSA-ключа другого пользователя многопользовательской системы, используя особенности помещения данных в совместно используемый L3-кэш.Представленная техника атаки позволяет восстановить более 98% битов закрытого ключа при проведении в системе каждого цикла дешифровки данных или формирования цифровой подписи. В отличие от ранее известных атак, представленный метод не требует привязки выполнения на одном ядре CPU шифрующего кода и кода злоумышленника, так как L3-кэш разделяется между всеми процессорными ядрами. Более того, атака может применяться и в окружениях виртуализации, в которых злоумышленник может атаковать GnuPG-сеанс, выполняемый в другой гостевой системе.
Несмотря на то, что отдельного корректирующего обновления GnuPG 2.0 не выпущено, проблема также затрагивает ветку GnuPG 2.0.x, для пользователей которой выпущено обновление Libgcrypt 1.5.3 (в ветке GnuPG 2.0.x базовая логика шифрования вынесена в отдельную библиотеку).
URL: http://permalink.gmane.org/gmane.org.fsf.announce/2003
Новость: https://www.opennet.ru/opennews/art.shtml?num=37517
yummy!
> данных на основе методов статистического анализа.Офигеть!!!
АНБ со своими бэкдорами
если бы это было абн, а не человеческий фактор, то и не сказали бы
Сделал АНБ, а сказали, что человеческий фактор
>> если бы это было абн, а не человеческий фактор, то и не сказали быдоговор о неразглашении
Копание в потрохах соседних процессов и контейнеров виртуализации? Фиксить нужно в ядре, как можно скорее.
MMU не пофиксишь. Надо фиксить мозги инженеров создающих такое непотребство
воистину.
как и реализация SMI/SMM - лютый руткит хардварный.
или BMC на сервачных платах.
а очень характерные люки в IPMI ? :)
> воистину.
> как и реализация SMI/SMM - лютый руткит хардварный.
> или BMC на сервачных платах.
> а очень характерные люки в IPMI ? :)Это же энтерпрайз, еретик! Запилить непонятную фичу в железке и потом продать её! Из-за таких как ты прогресс тормозит.
оно посреди ТНП наличествует, при чем тут Ынтерпрайз, вертуальный ?
Ну какбэ имелось ввиду, что с энтерпрайза всё валится на ТНП
> как и реализация SMI/SMM - лютый руткит хардварный.
> или BMC на сервачных платах.Если б только на сервачных. Половина ноутов с ним тоже. И десктопные мамки от интеля были с ним, опять же. Потому что вентиляторами рулит, etc. На мамках всяких асусов и гигабайтов обычно относительно тyпой чип с PWM и датчиками, но интель же как обычно заботится об удостве пользователя. Даже если это большой брат :)
Можно сделать принудительную однозадачность со смывом кэша между переключениями, параллельно выполнять только треды одного процесса. Производительность окажется в заднице, зато безопасно! :3
Можно... нужно...
Необходимо запилить нормальный диспетчер памяти. Или даже лучше микрокод для MMU под конкретную систему.
> Необходимо запилить нормальный диспетчер памяти. Или даже лучше микрокод для MMU под
> конкретную систему.Ага, и зонд АНБшный прямо в микрокод запихать :)
> Ага, и зонд АНБшный прямо в микрокод запихать :)да оно уже там, потому и не пускают: чтобы ламер Вася всё не поломал ненароком.
Это как же надо через L3 атаку провернуть?
Несколько байтов кода в ring0
а это точно уязвимость в GPG а не в процессоре?
Формально -- да, в архитектуре MMU. Но зафиксить можно и на софтварном уровне. Так, к примеру, в ядрах старых операционок фиксили взвис от F0-0F-C7-C8.
а если так -- то почему это нужно фиксить в прикладной программе, а не в ядре операционной системы?нет возможности исправить это в операционной системе?
или разработчик GPG решил на всякий случай исправить и у себя тоже на случай если это вдруг не исправляет ядро?(спрашиваю потому что до конца не понял как эксплуатируется эта уязвимость)
# UPDATED
вопрос снимаю. атака на основе статистического анализа времени -- думаю не будут такое фиксить в ядре :)
> а если так -- то почему это нужно фиксить в прикладной программе,Да, ведванольщики/питонщики/прочие думать головой не лю. За них подумает ЯП, фреймворк и прочая. Поэтому такие только и могут что делать супер-пупер сервисы с мегашифрованием на JS или каком там еще скриптошите. Ни разу не парясь фактическим знанием предмета.
А оказывается - обана, это вполне себе рокетсайнс где вот такой небольшой промах при должной квалификации атакующего может иметь очень интересные последствия. Да, парни, криптография - это не написание очередной веселой фермы. Там надо понимать как работает алгоритм, как это будет происходить по факту в железе, какие потенциальные проблемы могут быть и прочая. А для этого надо всего ничего - понимать самую малость как, собственно, компьютеры работают. А не уповать что за вас умный фреймворк подумает. В таких случаях - нифига за криптографа думать никто не будет. Больно уж требования специфичные.
> при должной квалификации атакующего может иметь очень интересные последствия...и при присутсвии себя вторым пользователем на этом компьютере.. и при этом ни какие другие программы (и пользователи) не должны проявлять активность.
да! тайминг-атаки они такие! тут одной только квалификации мало -- а нужно ещё чтобы Луны Юпитера приняли нужное положение.
> А для этого надо всего ничего - понимать самую малость как, собственно, компьютеры работают. А не уповать что за вас умный фреймворк подумает. В таких случаях - нифига за криптографа думать никто не будет.
пока вы там ноете о том какая это сложная наука, криптография -- в это время люди сидят себе и делают програмы, используя умные фреймворки, не разводя соплей :)