Опубликованы (https://www.openssl.org/) корректирующие выпуски OpenSSL 1.0.1h, 1.0.0m и 0.9.8za, в которых устранена опасная уязвимость (https://www.openssl.org/news/secadv_20140605.txt) (CVE-2014-0224), позволяющая совершить MITM-атаку, которая может привести к расшифровке и модификации на транзитном шлюзе проходящего в рамках защищённого SSL/TLS-соединения трафика. Информация об уязвимости была направлена команде разработчиков OpenSSL исследователем безопасности Kikuchi Masashi, выявившем (http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Inject... наличие проблемы. До выхода исправления сведения об уязвимости не разглашались публично.Атака может быть успешно проведена только при использовании уязвимой версии OpenSSL одновременно на стороне сервера и клиента, между которыми организован канал связи. Уязвимость в клиентской части присутствует во всех версиях OpenSSL, в то время как на сервере уязвимость проявляется только при использовании веток OpenSSL 1.0.1 и 1.0.2-beta1.
Помимо MITM-уязвимости, в новых выпусках устранена уязвимость в коде обработки фрагментов DTLS (http://ru.wikipedia.org/wiki/DTLS) (CVE-2014-0195), которая потенциально может быть использована (https://www.imperialviolet.org/2014/06/05/earlyccs.html) для организации выполнения кода на стороне сервера или клиента через отправку специально оформленных DTLS-фрагментов. Проблеме подвержены только приложения, использующие OpenSSL в качестве DTLS клиента или сервера.Кроме того, в новых выпусках устранено несколько менее существенных уязвимостей:
- CVE-2014-0221 - возможность совершения DoS-атаки (крах процесса) через возврат пытающемуся соединиться клиенту специально оформленных DTLS-пакетов. Проблема затрагивает только клиентские приложения, использующие DTLS;
- CVE-2014-0198 - ошибка в функции do_ssl3_write, позволяет удалённому атакующему вызвать отказ в обслуживании через инициирование разыменования NULL-указателя. Проблема затрагивает только OpenSSL 1.0.0 и 1.0.1 с включенной опцией SSL_MODE_RELEASE_BUFFERS, которая не используется по умолчанию;- CVE-2010-5298 - условия гонки в функции ssl3_read_bytes позволяют удалённому атакующему добиться подстановки своих данных в рамках сеанса или вызвать отказ в обслуживании. Проблема проявляется только в многопоточных приложениях, использующих OpenSSL 1.0.0 и 1.0.1 с включенной опцией SSL_MODE_RELEASE_BUFFERS, которая не используется по умолчанию;
- CVE-2014-3470 - TLS-клиенты, использующие анонимный набор шифров ECDH, могут быть подвежены DoS-атаке.- CVE-2014-0076 - техника атаки по восстановлению параметров ECDSA через атаку по сторонним каналам (восстановление данных из кэша при помощи техники FLUSH+RELOAD). Проблема ранее была исправлена в выпуске OpenSSL 1.0.1g, а теперь устранена и в версиях
OpenSSL 1.0.0m и OpenSSL 0.9.8za.На момент написания новости обновления пакетов с устранением уязвимостей доступны для FreeBSD (http://security.freebsd.org/advisories/FreeBSD-SA-14:14.open... Ubuntu (https://lists.ubuntu.com/archives/ubuntu-security-announce/2... CentOS (http://lists.centos.org/pipermail/centos-announce/2014-June/... RHEL (https://rhn.redhat.com/errata/RHSA-2014-0625.html), SUSE Enterprise Linux (https://www.suse.com/support/update/). Пока недоступны обновления для openSUSE (http://lists.opensuse.org/opensuse-security-announce/2014-06/), Debian (https://www.debian.org/security), Fedora (https://admin.fedoraproject.org/updates/F20/security), Gentoo (http://www.gentoo.org/security/en/index.xml), Slackware (http://www.slackware.com/security/list.php?l=slackware-secur... NetBSD (http://www.netbsd.org/support/security/), OpenBSD (http://www.openbsd.org/security.html).
URL: https://securityblog.redhat.com/2014/06/05/openssl-mitm-ccs-.../
Новость: http://www.opennet.me/opennews/art.shtml?num=39938
Ну вот, опять... Впрочем, трудно уже будет переплюнуть heartbleed.
HB - это был отвлекающий манёвр, от более толстых дыр! Ваша NSA!
Раньше этот массив [redacted]кода никто особо не проверял, и с годами он сгнил. Heartbleed спровоцировал вокруг него некоторый ажиотаж, и вот теперь стали выявляться уязвимости.Это очень хорошо, на самом деле. Лучше найти и исправить ошибки сегодня, чем завтра.
> и с годами он сгнил.Позволю себе с этим поспорить. SSL/TLS гнилый by design сами по себе. Ибо переусложненные до ж...ы протоколы.
Если до сих пор толком не проверялись такие значимые пакеты - значит это было кому то нужно...
возможно проверялись, но результаты проверки не обнародовались
> Если до сих пор толком не проверялись такие значимые пакеты - значит
> это было кому то нужно...Значит, это было никому не нужно. Людям вообще мало что нужно кроме собственного благополучия.
я тебя удивлю: очень многим хочется сунуть нос именно в чужое благополучие.
Советую вам заглянуть в код OpenSSL, боюсь, что у вас тоже не появится желание проверять его код. Нужно иметь не только знания в программировании, но и в криптографических спецификациях.
А как там с LibreSSL от команды OpenBSD?
> А как там с LibreSSL от команды OpenBSD?Исправляют тож - так как товарищ Кикучи с ними не поделился инфой, то буквально прямо сейчас. Некоторые патчи отличаются от закоммиченных в OpenSSL (там целый набор уязвимостей по факту). В любом случае тем, кто не хочет принимать участие в проекте LibreSSL за пределами OpenBSD, смотреть сей форк в ближайшие месяцы смысла нет, так как пока нет portable-обвязки.
>> А как там с LibreSSL от команды OpenBSD?
> Исправляют тож - так как товарищ Кикучи с ними не поделился инфой,
> то буквально прямо сейчас. Некоторые патчи отличаются от закоммиченных в OpenSSL
> (там целый набор уязвимостей по факту). В любом случае тем, кто
> не хочет принимать участие в проекте LibreSSL за пределами OpenBSD, смотреть
> сей форк в ближайшие месяцы смысла нет, так как пока нет
> portable-обвязки.Вдогонку, поразмышлять о "забывчивости" (читай, порядочности) некоторых спецов по безопасности (нашедшему OpenBSD или LibreSSL на странице по первой ссылке - пирожок):
http://seclists.org/oss-sec/2014/q2/466
http://marc.info/?l=openbsd-tech&m=140199721323030&w=2
> так как товарищ Кикучи с ними не поделился инфойТоварищ Кикути вообще ни с кем не поделился. Это не его дело. Уведомлением вендоров занимался кто-то из OpenSSL. И это логично. Так что не катите бочку на японца и не вмешивайте его в свои OpenSSL-vs-LibreSSL разборки.
> так как товарищ Кикучи с ними не поделился инфойи со мной, гад, не поделился! вот ведь сволочь - исследовал openssl и с ними же и поделился! вот как он мог не знать что в одном из древних проектов я использовал что-то издали похожее?
> то буквально прямо сейчас....через месяц? Оперативный фикс..
В OpenBSD всё нормально: http://marc.info/?l=openbsd-cvs&m=140198794119051&w=2
OpenSSL is written by monkeys - M.Peereboom
https://www.peereboom.us/assl/assl/html/openssl.html
> OpenSSL is written by monkeys - M.Peereboom
> https://www.peereboom.us/assl/assl/html/openssl.htmlКстати, ASSL - весьма приятная обёртка, существенно упрощающая жизнь в тех случаях, когда не требуется фигурное управление SSL/TLS и не хочется заниматься кое-чем нетрадиционным с API OpenSSL.
> Кстати, ASSL - весьма приятная обёртка,Если завернуть г-но в фантик, конфета из него все-равно не получится, сколько ни заворачивай. Хотя, возможно, вы просто хотели повысить продажи производителю фантиков?
> OpenSSL is written by monkeys - M.Peereboom
> https://www.peereboom.us/assl/assl/html/openssl.htmlwww.peereboom.us uses an invalid security certificate. The certificate is not trusted because it is self-signed.
P. S. Я бы даже сказал, by bald monkeys.
Сколько ещё уязвимостей нужно, чтобы идиоты догадались наконец-то погуглить и открыли для себя GnuTLS?
Вы имели в виду Windows 8 Professional?
>Сколько ещё уязвимостей нужно, чтобы идиоты догадались наконец-то погуглить и открыли для себя GnuTLSДавай я сделаю это за тебя... Даю ссылку для идиотов: http://www.gnutls.org/security.html
Стало хорошо?
Ну всё, теперь не уснёт теперь, подумал 's/Морфеус/iZEN/'.
Жил не тужил...
> Стало хорошо?Если сравнивать с OpenSSL - там все достаточно неплохо.
>> Стало хорошо?
> Если сравнивать с OpenSSL - там все достаточно неплохо.Код закрыт, они юзают обсуфицированный openssl :)
> Код закрыт, они юзают обсуфицированный openssl :)Странно, я думал что весна закончилась. А обострения у некоторых почему-то продолжаются.
ну, в gnutls все граздо хуже
> ну, в gnutls все граздо хужеПо списку багов не видно что-то.
> Chrome
> в них не используется OpenSSLДа неужели?
на винде не используют.
> на винде не используют.Это виндовые ламаки думают что не используют. А потом удивляются - ой, откуда это столько ботов спамит, ддосит и что там еще. А оказывается это ламерье машины не патчит.
man nss
Вроде как кошерная замена OpenSSL не GnuTLS, а djB-шное NaCl. Другой вопрос, есть ли уже ssh-клиенты, использующие NaCl? Что-то не нашёл :(
Точнее, как раз не ssh-клиенты, а ssh-сервер + ssh-клиент. Хочу защитить свой локалхост от злых агентов АНБ.
> Точнее, как раз не ssh-клиенты, а ssh-сервер + ssh-клиент. Хочу защитить свой
> локалхост от злых агентов АНБ.ssh-сервер был в соседней новости. И хоть и делался какими-то забавными кидями, но стиль мышления у таковых был весьма разумным.
> Вроде как кошерная замена OpenSSL не GnuTLS, а djB-шное NaCl.нет. в NaCl строго один вид шифрования и хэширования, а в SSL надо поддерживать кучу, ибо есть на свете, к сожалению, сервера, разговаривающие на всякой фигне.
алсо, если очень уж не хочется обмазываться OpenSSL, можно взять, например, PolarSSL. она и поприятней будет, и кода там сильно меньше, можно и самому проаудитить.
> можно взять, например, PolarSSL.или http://wiki.musl-libc.org/wiki/Alternative_libraries#Crypto другую выбрать :)
> или http://wiki.musl-libc.org/wiki/Alternative_libraries#Crypto другую выбрать :)не спорю. просто советую то, чем сам пользовался. правда, аудита не делал, мне всего-то качалку с поддержкой SSL надо было, но оно хотя бы API нормальный имеет, а не тот ужас, который в OpenSSL.
> нет. в NaCl строго один вид шифрования и хэширования,Это не так, если удосужиться почитать описание апи либы. Просто по дефолту подсунут лучшее (по мнению авторов). При том оно таки будет если и не лучшим то уж как минимум good enough, ибо писано криптографами а не какими-то посторонними ламаками-дилетантами.
> а в SSL надо поддерживать кучу, ибо есть на свете,
И, увы, это ставит крест на какой либо безопасности. Ибо в либах будет зиллион багов. И в протоколе будет зиллион багов. И в использовании либы и протокола всеми кто не криптограф будет зиллион*зиллион багов. И все эти неучтенности и незапланированности будут больно кусать за зад.
> к сожалению, сервера, разговаривающие на всякой фигне.
К сожалению, кто-то думает что разговаривание на всякой фигне от чего-то защищает. А вот это неверно.
> алсо, если очень уж не хочется обмазываться OpenSSL, можно взять, например, PolarSSL.
"И вместо рака будет грыжа". В смысле, переусложненность и бестолковость SSL/TLS никуда не делась, да и возможности по прострелу пяток остались на месте. И как раз аудит этого кода делался сильно меньшим количеством народа.
> она и поприятней будет, и кода там сильно меньше, можно и самому проаудитить.
Аудитить код реализующий TLS - удовольствие сильно ниже среднего, ибо навороченный до ж...ы протокол. К тому же, хренли толку с твоего аудита если с той стороны окажется дырявый openssl который память с твоими данными недругу сольет? Все это TLS/SSL барахло лечится только гильотиной. И хватит уже пудрить людям мозги что оно от чего-то там защищает. Большинство людей и даже разработчиков никогда не сможет использовать TLS/SSL сколь-нибудь секурно.
>> нет. в NaCl строго один вид шифрования и хэширования,
> Это не так, если удосужиться почитать описание апи либы.а если исходник — то так. точнее, почти так.
>> алсо, если очень уж не хочется обмазываться OpenSSL, можно взять, например, PolarSSL.
> "И вместо рака будет грыжа". В смысле, переусложненность и бестолковость SSL/TLS никуда
> не делась, да и возможности по прострелу пяток остались на месте.
> И как раз аудит этого кода делался сильно меньшим количеством народа.PolarSSL достаточно мелкая для того, чтобы можно было проаудитить самостоятельно. удачи в самостоятельном аудите OpenSSL.
>> она и поприятней будет, и кода там сильно меньше, можно и самому проаудитить.
> Аудитить код реализующий TLS - удовольствие сильно ниже среднего, ибо навороченный до
> ж...ы протокол.найми эксперта, кто запрещает?
> хватит уже пудрить людям мозги что оно от чего-то там защищает.
это ты к кому обращаешься вообще?
> а если исходник — то так. точнее, почти так.Во первых, есть несколько реализаций с "одинаковым API". Как минимум, в природе замечены:
1) NaCl - непосредственно от дяденьки Берштейна. Там таки несколько разных алгоритмов в ряде вызовов возможны. Например, crypto_hash() может использовать 2 алгоритма, etc. Из очевидных грабель либы при применении: система сборки этой либы непортабельна и подразумевает *nix-like окружение.
2) libsodium - более портабельный вариант. Также использует SUPERCOP вместо Edwards-а для crypto_sign() по умолчанию. У Берштейна в NaCl тоже в этом вызове будет по дефолту SUPERCOP. Но потом. Но обещали. Так что если кто будет клювом клац-клац, получит граблями в лоб :). Впрочем, лично я на _sign класть хотел, мне оттуда нравится "authenticated encryption" с публичными ключами. Очень симпатичный diffie-hellman, "почти без обмена ключами" и с хорошими свойствами.
3) TweetNaCl. Пожалуй самое симпатичное из всего выводка. Очень компактная либа с минимализмом в реализации примитивов, совместимая по апи с предыдущими. Два файла, .c и .h без системы сборки, можно в два счета прочитать глазами. По минимуму, для использования D-H baseed crypto_box() хочет аж целый внешний randombytes(), который для *nix-like пишется вообще тривиально (открыть /dev/urandom и прочитать). Вот там в реализации алгоритмов конкретный минимализм, это да. Зато и либа мелкая.>> И как раз аудит этого кода делался сильно меньшим количеством народа.
> PolarSSL достаточно мелкая для того, чтобы можно было проаудитить самостоятельно.Скажем прямо, я не испытываю желания самостоятельно аудитить ни одну реализацию TLS вообще. Так, глядя на спецификации протокола и как это апликушники юзают. Ведь можно сделать в 10 раз проще и при том со свойствами которых TLS достигает только с кучей всяких опциональных довесков. Хороший пример - CurveCP. В таких вещах и апликушникам сложно лохануться (элементарно негде) и сорц мелкий. А с этими вашими SSL/TLS сами и ...тесь, если оно вам зачем-то надо. Мне с ними все понятно уже достаточно давно, уж извините. Декоративная секурити - хуже чем никакой секурити вообще.
> удачи в самостоятельном аудите OpenSSL.
Эхехе, там вон целый гугл и прочие упираются, а все-равно эвона какие плюхи лезут. Впрочем, чего ожидать от "криптографов", выдающих на-гора вывод хардварного RNG без подмешивания какой либо еще энтропии? Правильно - кучи обсираков во всех остальных местах! Потому что такую эпическую лажу даже вон в линуксном ядре не пропускают вообще обычные разработчики. Которые ни разу не криптографы даже, просто с головой дружат. В отличие от авторов openssl.
> найми эксперта, кто запрещает?
Да мне и самому хватает квалификации посмотреть на протокол и понять что горбатого могила исправит.
> это ты к кому обращаешься вообще?
А ко всем кто SSL/TLS крап сватает. Пора уже признать что эти протоколы - дepьмо и на практике от них в большинстве случаев мало толку. Дepьмо - еще на уровне дико переусложненного протокола с кучей костылей и подпорок. Остальное в общем то следствия. Заканчивайте уже вешать лапшу на уши с этими SSL и TLS. Задрали. Чем быстрее этот шит отправится на свалку истории, тем лучше. Еще можно в палату мер и весов - как эталон overengineering, со всеми вытекающими.
>> а если исходник — то так. точнее, почти так.
> Во первых, есть несколько реализаций с "одинаковым API".ты прямо написал NaCl.
> 1) NaCl - непосредственно от дяденьки Берштейна. Там таки несколько разных алгоритмов
> в ряде вызовов возможны. Например, crypto_hash() может использовать 2 алгоритма, etc.поэтому я и сказал «почти». чтобы увидеть «рекомендованый минимум» — как раз TweetNaCl можно взять, там ровно по одному методу на рыло.
>>> И как раз аудит этого кода делался сильно меньшим количеством народа.
>> PolarSSL достаточно мелкая для того, чтобы можно было проаудитить самостоятельно.
> Скажем прямо, я не испытываю желания самостоятельно аудитить ни одну реализацию TLS
> вообще.тогда молись, постись и всё такое. потому что это использовали и использовать будут ещё долго.
> Хороший пример - CurveCP.
плохой пример. оно, конечно, получше и попроще, но с багами в спеках. которые djb чинить не хочет. например, там возможно послать сообщение без данных, но невозможно сделать ему ACK. соответственно, при установке соединения клиент или сразу должен посылать что-то бесполезное, или бомбить сервер initiate-пакетами, надеясь на то, что оттуда придёт ACK по id'у (хотя в ответе поле lastid вообще не предназначено для ACK-ов, и если по нему убирать пакеты — чикага немного сходит с ума).
также там не предусмотрены простейшие keep-alive пакеты (то есть, их опять можно сделать только безжалостными хаками, чтобы не поломать совместимость с другими реализациями). а для UDP через NAT это иногда весьма полезно, иначе порт может закрыться.
CurveCP — это такая академическая игрушка, proof-of-concept.
> В таких вещах и апликушникам сложно лохануться
да, как я написал — достаточно облажаться авторам спеков. ;-)
т.е. уязвимость можно эксплуатировать только если OpenSSL с обеих сторон соединения - верно?
> т.е. уязвимость можно эксплуатировать только если OpenSSL с обеих сторон соединения - верно?У атакующего с его стороны всегда будет то что ему удобно и выгодно. Во всяком случае, вы должны действовать как будто это всегда так.
http://www.openwall.com/lists/oss-security/2014/05/02/7=> Тео сам себе Злобный Буратино
OpenBSD секурная! Самая секурная! Но критикал патч прое...ли почти на месяц. Орлы, итить.
Ну вот, пожалуйста, Tor и I2P ломается точно также.
> Ну вот, пожалуйста, Tor и I2P ломается точно также.I2P не использует OpenSSL, и не использует SSL вообще.
Хорошо, что народ стал активной искать уязвимости в таком важном проекте, и из закрывать.
> Хорошо, что народ стал активной искать уязвимости в таком важном проектеГорбатого могила исправит. Проект, где авторы нисколько не сомневаясь напрямую выдают вывожд аппаратного RNG приложениям, даже не пытаясь подмешивать стороннюю энтропию - пишется ламерьем и дилетантами, которые в криптографии разбираются меньше чем свинья в апельсинах. И желание использовать такую криптографическую либу можно объяснить или склонностью к мазохизму, или склонностью к очковтирательству.
> Горбатого могила исправит. Проект, где авторы нисколько не сомневаясь напрямую выдают вывожд
> аппаратного RNG приложениям, даже не пытаясь подмешивать стороннюю энтропию - пишется
> ламерьем и дилетантами, которые в криптографии разбираются меньше чем свинья в
> апельсинах.use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom.
не надо ничего туда «подмешивать», там уже всё есть.
> use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom.
> не надо ничего туда «подмешивать», там уже всё есть./dev/random, а не /dev/urandom.
Причём в OpenSSL его и используют. Среди прочего.
>> use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom.
>> не надо ничего туда «подмешивать», там уже всё есть.
> /dev/random, а не /dev/urandom.use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom.
могу повторять до просветления, раз поисковики — чересчур сложно. random(4) — это бредятина в стиле «мы сами не местные», но даже там есть умное предложение: «If you are unsure about whether you should use /dev/random or /dev/urandom, then probably you want to use the latter.» а поскольку ты вряд ли читал и понял реализацию в ядре, то use /dev/urandom.
> Причём в OpenSSL его и используют. Среди прочего.
для сидирования своего генератора. что не имеет никакого глубокого смысла, потому что ядро само отлично справляется с накапливанием энтропии и периодическим ресидированием /dev/urandom.
> use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom.У openssl есть возможность попросить аппаратную акселерацию. Вот они и акселерировали аппаратно, бэть!!! В том числе и генерацию случайных чисел. Руки за такую "акселерацию криптографии" обрывать.
> не надо ничего туда «подмешивать», там уже всё есть.
Ну вот некоторым хочется быть святее папы Римского. С понятным результатом...
В NSS такого нету? Я надеюсь.
решето наконец-то решили хорошенько потрясти? мне это старый анекдот напоминает. про то, как мужик думал, что проще: этих детей отмыть, или новых сделать.
Лучше новых сделать, но не ему )