Обнаружена уязвимость в OpenSSH

> Исходная статья здесь: http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf

Спасибо.

Ну а что вы хотите? В криптографии без паранойи никак...Ведь криптостойкость всей системы равна криптостойкости сАмого слабого звена. Поэтому даже такие мелочи приходиться учитывать, а то и толку то не будет от криптографии. Это раз.

А во-вторых, новость сообщает, что просто найдена уязвимость(даже не критическая) в OpenSSH. Криптография - неимоверно сложная штука, и создать действительно криптостойкий алгоритм крайне сложно. И вполне естественно, что в алгоритмах находят уязвимости и недоработки. Это даже хорошо, ведь теперь OpenSSH,например, стал еще безопаснее =)

>Ваша первая фраза не обосновывает вторую. Таким образом, вы высрали на просторы ЛОР-а классический сэмпл бессвязного бреда.

В варианте для имбецилов поясняю, если мне известно, что алгоритм А сводится к алгоритму Б путем отбрасывания первых 4-х байт последовательности, то в виду тривиальности этой операции криптографическая стойкость алгоритма А равна Б. Так достаточно просто? Если не все доступно тогда просто вместо 4-х подставь 0, хотя зря, наверное тебя это еще больше запутает.

> А в данном случае подмешивание рандома вообще ничего не даст кроме похеренной информации.

С чего бы это похеренной? Алгоритм предлагается "усовершенствовать" тупым добавлением 4-х случайных байт в результирующую последовательность. Или вы полагаете что такая операция необратимо меняет шифротекст? Могу доказать что нет, отбрасываем 4 первых байта и получаем результат без усоврешенствования.

Обнаружена - значит устранена

в честь этого знаменательного события предлагаю поднять бокалы

Терморектальный криптоанализ никто не отменял...

PS поддерживаю, bioreactor

Кстати - а в убунте lts таки древний еще пакет (4.7). Надо обновить чтоль...

> новость сообщает, что просто найдена уязвимость … в OpenSSH

Новость — 4.2

Ошибка не в OpenSSH, а в RFC (4251?), в архитектуре самого протокола SSH. Именно эту проблему в софте починили, правда стандарт ещё не поправили.

> Кстати - а в убунте lts таки древний еще пакет (4.7). Надо обновить чтоль...

вас так испугала фраза "с вероятностью 2^{-18} (один случай из 262,144) расшифровать кусок передаваемых данных длиной в 32 бита."?

Стоит отметить что и вы правы, и ваш опонент тоже. Конечно, добавление 4 рэндомных байтов не добавляет криптостойкости алгоритбу _без_ уязвимости. Но с другой стороны, добавляя эти 4 бесполезных байта вы получайте ту же криптостойкость что и у алгоритма без уязвимости. В итоге, предложеное решение таки устраняет проблему, хоть и увеличивает количество передаваемых данных.

> отбрасываем 4 первых байта и получаем результат без усоврешенствования.

...четыре первых байта которого дешифруются указанным в новости методом. Я ж говорю - ход гениальный.

>вас так испугала фраза "с вероятностью 2^{-18} (один случай из 262,144) расшифровать кусок передаваемых данных длиной в 32 бита."?

нет, меня испугало то, что разрабы "самого бетаверсионного дистра" (федора отдыхает от феерических глюков убунты) в lts ветку еще добавили еще пакет с версией 5.2 (где ошибка устранена). А ведь ногой себя в грудь били - мол мы все пропилим и дальше тока обновления безопасности клепать будем.

где они, я спрашиваю? (с) наша раша

> Могу доказать что нет, отбрасываем 4 первых байта и получаем результат без усоврешенствования.

Нет, получаем пустое множество. Потому, что кроме этих самых четырех байт атакующему ничего не известно.

> Вот кстате дайте ка мне того мудака, что постановил, что в русском языке дробная часть отделяется запятой, а не точкой. Уж я бы его поотделял.

тогда уж не стоит русской локалью ограничиваться. Тысячи их. Напр., в немецкой разделители такие же, как в русской. В швейцарской дробная часть отделяется точкой, а тысячные разряды - вообще апострофом. А про форматы дат я вообще молчу.

> Алгоритм предлагается "усовершенствовать" тупым добавлением 4-х случайных байт в результирующую последовательность.

Каменная ты голова, байты добавляются _до_ шифрования.

Одноразовый блокнот это многовековой бойан. Одна проблема только - пересылка ключей.

Вы таки определитесь, случайные дайты добавляются до шифровки или после ;)

В статье с ZDnet.com два утверждения по этому поводу:

"This is a design flaw in OpenSSH," said Patterson. "The other vulnerabilities have been more about coding errors."

The attack relies on flaws in the RFC (Request for Comments) internet standards that define SSH, said Patterson.

Если софт исправлен таким образом, что не соответствует стандарту, то возникает вопрос, могут ли коннектится, например, исправленный сервер и не исправленный клиент. И да, каким вообще образом решена проблема?

Чем больше кусок известного шифротекста - тем больше вероятнлсть расшифровать все телегу. Если в начале специально будет рандом - злоумышленнику это ни шиша не даст. Если будет 'ssh ' и он может слушать сеть - то останется проверить несколько вариантов (IP, доменное имя и т.д.) - и он уже знает байт 15-20. Если там будет, скажем, куча пробелов - опять плохо, он проверит варианты с 10-20 пробелами и тоже сможет расшифровать весь текст.

Так что даешь 5.2 (у кого до сих пор нет).

>ну а где ты возмешь так много качественных людей для сборки пакетов?

используйте клонирование или откажитесь от сборки наконец же

>Напр., в немецкой разделители такие же, как в русской.

надо же, неужели аж от Эйлера ноги растут

Вот ещё один аргумент за использование "текстовых" форматов. Атака срабатывает только при наличии нулевого байта в потоке, чего в "текстовых" файлах, паролях, и т.п. не наблюдается. Только сжатие включать нельзя.

>> Алгоритм предлагается "усовершенствовать" тупым добавлением 4-х случайных байт в результирующую последовательность.

> Каменная ты голова, байты добавляются _до_ шифрования.

Не хочу влезать в вашу милую беседу, но хочу скромно заметить, что этот спор не имеет смысла за отсутствием представления о том, какой конкретно алгоритм шифрования используется в данном конкретном случае. Но могу сказать, что в самом общем случае (вдруг откуда ни возьмись) известная *часть* открытого текста (пусть это всего 32 бита - неважно) всегда повышает шансы успешного криптоанализа. Потому что информация об открытом тексте - это потенциальная информация об используемом ключе шифрования. В реальном криптоанализе этим пользуются. И пользуются активно. Но подобные возможности для "взлома" возникают далеко не в каждом криптоалгоритме. Поэтому спор на самом деле бесполезен.

Я несколько слаб в программировании. Раскажите пожалуйста, каким образом эта уязвимость была исправлена. Забивка этих битов случайным бредом или подобная затычка? Всетаки уязвимость архитектуры

>Перепили все? Уязвимость полугодовой давности

Не, только вышли из запоя

> Я несколько слаб в программировании. Раскажите пожалуйста, каким образом эта уязвимость была исправлена. Забивка этих битов случайным бредом или подобная затычка? Всетаки уязвимость архитектуры

Бородатые инфантильные дяди из OpenBSD сели за свои компьютеры и начали агрессивно стучать по кнопкам. Их бороды раскачивались в такт взмахам их рук над клавиатурой. В голове их крутилась мысль о недавнем разговоре с Тео, который за каждую новую remote-hole проделывал им новую local-hole в заднице, таким образом у каждого из них их было уже по крайней мере три штуки: одна своя, родная, и две авторства отца-основателя OpenBSD. Пальцы стучали по клавишам, выводя все новые и новые строчки кода...

> Раскажите пожалуйста, каким образом эта уязвимость была исправлена.

Атака опирается на слишком детальные сообщения об ошибках со стороны сервера OpenSSH. Детальность уменьшена.

Атака также опирается на шифрование с использованием cipher-block chaining (cbc). Соответственно OpenSSH теперь предпочитает cbc не использовать.

Вроде бы предприняты еще какие-то контрмеры, но мне лень искать.

> Забивка этих битов случайным бредом или подобная затычка?

Забивка битов сломала бы совместимость со старыми версиями openssh, и существенно снизила бы пропускную способность.

> Не хочу влезать в вашу милую беседу, но хочу скромно заметить, что этот спор не имеет смысла за отсутствием представления о том, какой конкретно алгоритм шифрования используется в данном конкретном случае.

3des-cbc и aes128-cbc.

Снобизм цитирующих Булгакова понятен, непонятна лишь их собственная точка зрения, коюю они либо не имеют, либо недостаточно воспитаны, чтобы приподнести её правильно.

> Потому что информация об открытом тексте - это потенциальная информация об используемом ключе шифрования. В реальном криптоанализе этим пользуются. И пользуются активно.

Не знаю, что там с AES-128, а про 3DES пишут так. Для успешной атаки на 3DES потребуется около 2^32 бит известного открытого текста, 2^113 шагов, 2^90 циклов DES-шифрования и 2^88 бит памяти. ( http://ru.wikipedia.org/wiki/Triple_DES ) . Если считать, что процессор на частоте 100 ГГц делает 100 000 000 000 (примерно 2^37) шагов в секунду, то на взлом уйдет 2^76 секунд. Это примерно примерно 2^51 лет. Если вы богаты, и можете позволить себе кластер с миллиардом таких процессоров, то он успешно закончит взлом через 2^42=4398046511104 лет. Удачи :D

А в языке Ди вообще можно писать 1_234_567 :)

> Если вы богаты, и можете позволить себе кластер с миллиардом таких процессоров, то он успешно закончит взлом через 2^42=4398046511104 лет. Удачи :D

На практике, как правило, не всё так радужно и красиво, как пишут в статьях википедии. Особенно когда в таких источниках не предоставляется ссылок на соответствующие оценки криптостойкости - это во-первых. А во-вторых, время идет, и старые методы криптоанализа совершенствуются, при этом появляются и новые. Если одному подходу требуется то, о чем пишут в википедии, то другому может понадобиться на порядки меньше. Всё-таки это математика, а она на месте не стоит. В википедии и относительно A5/1 указаны подобные заоблачные оценки (и они на самом деле были верны на определенный момент времени). Хотя взлом A5/1 можно организовать уже реально существующими алгоритмами за 18 часов без знания той уймы информации, что указана в статьях. Повторюсь: методы могут быть разные. Ну а 30 бит открытого текста на самом деле могут помочь. Поэтому я думаю, что подобные "косяки" и "дыры" - это не шутка, и, пока не поздно, их нужно закрывать. Особенно с учетом того, что это касается безопасности.

> Ну а 30 бит открытого текста на самом деле могут помочь. Поэтому я думаю, что подобные "косяки" и "дыры" - это не шутка, и, пока не поздно, их нужно закрывать.

При попытке их получить, ssh сессия будет оборвана. А шансы на успешное получение - 1 к 262,144.

Помочь они, теоретически, могут. На практике же таких методов не известно (иначе трубили бы не о 32-х украденных битах, а о полноценном взломе).

Закрывать нужно, но на данный момент проблема и яйца выеденного не стОит. Слишком заметна атака, и слишком малы шансы на ее успех. И даже в случае успеха, ее результаты ограничены четремя бесполезными байтами.

> Чем больше кусок известного шифротекста - тем больше вероятнлсть расшифровать все телегу. Если в начале специально будет рандом - злоумышленнику это ни шиша не даст.

Вы что, сговорились? Поймите, я не говорю о том, что криптаналитик получает смысловую информацию или нет. Это не волнует. Мы получаем данные, которые _зашифровал_ пользователь, не важно что это случайные числа. Пользователю туда вписал случайные числа и зашифровал. А криптаналитик получил эти 4 случайных байта, те самые, которые зашифровал пользователь. Никто не говорит о практическом применении уязвимости.

> Атака срабатывает только при наличии нулевого байта в потоке

Неа. Требуется, чтобы байт из незашифрованного потока, будучи по-XOR-ен с байтом из одного зашифрованного блока, и затем с байтом из другого зашифрованнного блока, обращался ноль.

Да, упустил :-(

решето!

> непонятна лишь их собственная точка зрения

Собственную точку зрения держу при себе. И к этому же призывал цитатой.

Но если Вам интересно: обнаруженная уязвимость - не уязвимость в смысле безопасности OpenSSH, потому что практически её применить нельзя ни сейчас, ни потом. Это интересно только для обсуждения в соответствующих разделах форума. Ну а выдавать рандом в первых четырёх байтах, как сказали выше, - это вообще к решению проблемы (и к самой проблеме) никак не относится.

"32 бита" -- специльно чтобы ПОБОЛЬШЕ казалось? :DD

ну моглибы ещё и "64 полу-бита" написать или "128 четверть-бита" :DD

>>"с вероятностью 2^{-18} (один случай из 262,144)"

для ещё большей понятности былобы просто "с вероятностью 0.000003815"


в итоге получаем новость: 
"
Исследователи из Royal Holloway, University of London обнаружили уязвимость в OpenSSH, позволяющую злоумышленнику с вероятностью 0.000003815 расшифровать кусок передаваемых данных длиной в 4 байта.
"

О!!! КАК ЭТО ЭПИЧКСКИ!! :DDDDDD

> Исследователи из Royal Holloway, University of London обнаружили уязвимость в OpenSSH, позволяющую злоумышленнику с вероятностью 0.000003815 расшифровать кусок передаваемых данных длиной в 4 байта.

Вы забыли указать, что при этом злоумышленник оборвёт сессию, чем

1. спалится.

2. окончательно лишит полезности полученные данные.

А вообще, британские учёные в своём репертуаре.

Хотя, конечно, нельзя исключать вероятность того, что в будущем появится возможность восстановить ключ по четырём расшифрованным байтам.

P.S.

> "64 полу-бита" написать или "128 четверть-бита"

http://bash.org.ru/quote/402795

Ой-вей, мы все умрем.

> Конечно, используются. А потом в ленте новостей идут заголовки типа, "защита XXX была сломана YYY за n секунд" или "программа Z была взломана еще до выхода на рынок".

AVL2, изречения космического масштаба и космической же глупости - у Вас. Добавление случайной информации является штатным методом, а из стандартных подходов лучше всего вспомнить PKCS#1 (применение RSA) - там это является обязательным способом защиты против одной из атак (chosen plaintext). В RC4 сейчас принято пропускать первый килобайт, он слишком предсказуем.

А методов надёжности "железобетонная стена толщиной в 1 километр" не существует, или же они чрезмерно дороги.