В развиваемой компанией ARM свободной крипографической библиотеке PolarSSL (https://www.opennet.ru/opennews/art.shtml?num=31442) выявлена (https://polarssl.org/tech-updates/security-advisories/polars...) критическая уязвимость (http://www.certifiedsecure.com/polarssl-advisory/) (CVE-2015-1182), которая потенциально может привести к выполнению кода злоумышленника при обработке средствами библиотеки специально оформленных последовательностей ASN.1 из сертификатов X.509. Проблема может проявляться в серверных и клиентских приложениях, использующих PolarSSL при организации шифрованного канала связи c подконтрольным злоумышленнику клиентом или сервером.
Среди программ, поддерживающих сборку с PolarSSL, можно отметить (https://polarssl.org/kb/generic/projects-using-polarssl) OpenVPN-NL (https://openvpn.fox-it.com/) (уязвим и требует обновления, так как использует (https://openvpn.fox-it.com/background.html) по умолчанию PolarSSL), OpenVPN, cURL, FreeRDP, PowerDNS. Проблема проявляется во всех выпусках PolarSSL 1.x, включая актуальные релизы 1.3.9 и 1.2.12. Исправление пока доступно в виде патча (http://www.certifiedsecure.com/polarssl-advisory/asn1parse.c...).
URL: https://polarssl.org/tech-updates/security-advisories/polars...
Новость: https://www.opennet.ru/opennews/art.shtml?num=41492
Теперь есть два типа дыр, случайные и намеренные. Так теперь у них принято
> Теперь есть два типа дыр, случайные и намеренные. Так теперь у них принято
> случайныеТакие еще где-то остались?
Точно, два типа дыр: случайные и критические.
Все некритические - обязательно случайные?
> специально оформленных последовательностей ASN.1Ну кто бы сомневался что в навороченном до ж...ы парсере очередной переусложненой фигни "на все случаи жизни" насажают багов. Ну что, советчики стандартного крапа, даже в сватаемом Polar SSL случился полярный лис, да? :)
Ну не бывает швейцарский нож с 200 лезвиями удобной отверткой, хорошими ножницами и годной открывашкой.
> Ну не бывает швейцарский нож с 200 лезвиями удобной отверткой, хорошими ножницами и годной открывашкой.Жестко ты Linux приложил.
В нем между прочим можно выбрать какие лезвия прикручивать - см. как это делают какие-нибудь опенвртшники. И основная масса лезвий по крайней мере не работает с внешними данными по сети. Не говоря о том что квалификация ядерных програмеров - зело выше средней по больнице. А обычную либу в юзермоде пишут черти кто. Спасибо если они хоть минимальное представление о криптографии имеют, а то вон в опенссл если попросить аппаратное ускорение - могут накормить сразу прямиком рандомом из аппаратного RNG, без подмешивания других источников энтропии. А бэкдоры в RNG - не, не слышали! А вот в лине одно только рассмотрение такой возможности вызывает саркастичные отповеди от какого-нибудь Теодора Тсо, который в общем то даже и не криптограф вроде. Так что в лине по поводу грубых плюх в криптографии получше чем у некоторых. Хотя и не идеально.
> В нем между прочим можно выбрать какие лезвия прикручиватьНо сути это не меняет.
> Но сути это не меняет.Да как сказать? Несмотря на большой размер кода багов которые были бы эксплуатируемы по сети там как-то было не сильно то дофига. И это в шмате кода на мегабайты. А тут казалось бы одна небольшая либа - и такая плюха.
Засчитывается то результат. В смысле, сломают вам систему или нет. Не вижу как ядро линя сильно этому способствует. А сабж вот довольно убедительно облажался при том что там кода неизмеримо меньше.
> Засчитывается то результат. В смысле, сломают вам систему или нет.
> Не вижу как ядро линя сильно этому способствует.Вообще-то способствует, вспомните недавние комментарии solardiz. Но это отдельная история и всяко не виндостудентам вылазить её порассказывать.
> Вообще-то способствует, вспомните недавние комментарии solardiz.А ссылочку подкинете? И да, может быть у меня склероз, но я не помню в линухе CVE с удаленным поимением ядра по сети в последнее время. Как минимум для сколь-нибудь распостраненных конфигураций. Я вполне согласен что может быть и лучше, но честно говоря я не сталкивался с сколь-нибудь ощутимыми проблемами по линии именно линукса как ядра ОС.
> Но это отдельная история и всяко не виндостудентам вылазить её порассказывать.
А виндостудентам всегда можно немного get the facts'ов подогнать: http://hitech.newsru.com/article/16jan2015/google_wind
Так что если они хотят сказать что у них лучше получается - что-то не похоже, имхо.
>> Вообще-то способствует, вспомните недавние комментарии solardiz.
> А ссылочку подкинете?https://www.opennet.ru/openforum/vsluhforumID3/101076.html#54
> http://hitech.newsru.com/article/16jan2015/google_wind
Да-да, с характерными истериками про coordinated release/responsible disclosure квартал спустя, как это узнаваемо... но это уже третья сказка :)
Полная история изложена здесь: http://spbit.ru/news/n113886/
> Полная история изложена здесь: http://spbit.ru/news/n113886/Мне малоинтересно почему в микрософте 3 месяца е...ли вола вместо того чтобы фиксить баг, при том что их о проблеме явно и громко уведомили. Ну ладно б они еще не знали о баге.
потому что расписание выпусков патчей важнее всего.а идиотские писки по поводу «нашли баг — молчите!» продолжают умилять. конечно, молчите: на рынке 0-day'ев он давно продаётся, не ломайте бизнес, не позволяйте людям даже узнать, откуда может быть следующая атака! а то ведь они и подготовиться могут.
> потому что расписание выпусков патчей важнее всего.У них вроде раз в месяц, так что они минимум 2 раза проипли срок.
> а идиoтские писки по поводу «нашли баг — молчите!» продолжают умилять.
Осталось еще набраться наглости и попросить хаксоров иметь юзерье по расписанию, громко анонсируя "кто не спрятался^W пропатчился - я не виноват!"
>> потому что расписание выпусков патчей важнее всего.
> У них вроде раз в месяц, так что они минимум 2 раза
> проипли срок.так это… список фиксов для следующих патчей давно составлен, туда не помещается. невозможно за одно и то же время сделать больше.
тут, на самом деле, ситуация вполне понятная. сделать багфикс — это ж не просто код вкоммитить. это делать кучу сборок, заново тестировать кучу сценариев, всё вот это. расписание составлено, люди заняты. тупо их срывать с текущей работы — это куча проблем. а релизнуть быстропатч к исходникам как временную меру — по очевидным причинам невозможно.
>> а идиoтские писки по поводу «нашли баг — молчите!» продолжают умилять.
> Осталось еще набраться наглости и попросить хаксоров иметь юзерье по расписанию, громко
> анонсируя "кто не спрятался^W пропатчился - я не виноват!"в общем-то, обида чувака вполне понятна: «ну, вы же понимаете, что такое багфиксы в большой конторе! играете нечестно, не по правилам!»
>> Ну не бывает швейцарский нож с 200 лезвиями
> Жестко ты Linux приложил.Линукс -- это общее название набора заготовок, комплектов деталей, одно- и многоцелевых готовых инструментов. И _так_ безграмотно вляпаться при попытке наехать надо было постараться. :)
> Линукс -- это общее название набора заготовок, комплектов деталей, одно- и многоцелевых готовых инструментов.Как и PolarSSL. От того, что вы его называете другими словами, суть не меняется ;)
> Как и PolarSSL. От того, что вы его называете другими словами, суть
> не меняется ;)Linux, PolarSSL... и правда, какая разница? :)
> даже в сватаемом Polar SSL случился полярный лис, да? :)нет, конечно. точнее, да: у тех идиотов, у которых выделялка памяти не чистит выделенное автоматически. ну, идиоты, что с них взять. ну да, авторы поляра заботливо положили для них грабли. а что, неужели никого не насторожил дефайн «#define polarssl_malloc malloc»? ну, ССЗБ.
Ну ок, так и запишем - те кто пользуются PolarSSL - ССЗБ. Правда это касается и остальных реализаций SSL/TLS. Потому что в таком монстрятнике просто не может не быть багов. В том числе и багов ведущих к проблемам безопасности.
а ещё в ядре баги есть. в том числе и ведущие к. ужас просто. твой выбор — счёты и голуби. хотя, конечно, даже там есть баги, ведущие к…
Отличное напомнинание крикунам и борцам, что баги бывают у всех. Рецепт лечения - консервативный подход к добавлению фич и проверка временем.
> Отличное напомнинание крикунам и борцам, что баги бывают у всех. Рецепт лечения
> - консервативный подход к добавлению фичНеа. Прежде всего консервативность нужна при исправлении багов и, особенно, закрытии дыр.
Обычно подобные вещи делаются в спешке, не проходят достаточного тестирования, и ведут к появлению новых ошибок и уязвимостей.
Ну, значит следом прилетит ещё один багофикс. Всё лучше, чем кидаться в объятия "инновационного" кода, не прошедшего проверку временем. Не та сфера, где нужно много инноваций.
> Ну, значит следом прилетит ещё один багофикс. Всё лучше, чем кидаться в
> объятия "инновационного" кода, не прошедшего проверку временем. Не та сфера, где
> нужно много инноваций.Багфикс - тоже вполне себе инновация.
Именно поэтому у серьезных дядек каждое исправление требует отдельной сертификации, в противном случае его установка отменяет сертификацию всей системы.
сертифицированное говно магически превращается в конфетку!
> сертифицированное гoвно магически превращается в конфетку!Ну надо же как-то оправдывать волокиту, бюрократию и имитацию бурной деятельности.
> - консервативный подход к добавлению фич и проверка временем.Ну, за шифр Цезаря! :)
Ну да, главное - чтобы метод прошел проверку временем.
Результат проверки неважен...
О, кто-то путает качество (и сферу применения) алгоритма и качество кода... бывает.
> О, кто-то путает качество (и сферу применения) алгоритма и качество кода... бывает.Внезапно, качество алгоритма тоже должно пройти проверку временем.
Речь была не о том.
Да все правильно выше сказали.
Проверку временем должен проходить и код, и алгоритм. Причем для алгоритма это важнее, потому что код строится на его основе.
угу. время — великий волшебник. заменяет все науки. что было хорошо для наших дедов — хорошо и для нас!
> угу. время — великий волшебник. заменяет все науки. что было хорошо для
> наших дедов — хорошо и для нас!Да вот странно - летают на самолетах зачем-то. Ездят на поездах. Автомобилей понаштамповали. Чем этим лохам лошади так не нравились? Проверенные же временем.
Ждём реализацию SSL на Rust.
Такие важные вещи следует писать на проверенных временем и хорошо зарекомендовавших себя языках.
Таких как Forth или Cobol.
> Такие важные вещи следует писать на проверенных временем и хорошо зарекомендовавших себя
> языках.
> Таких как Forth или Cobol.При том из шифрования желательно реализовать только шифр Цезаря. Остальные недостаточно проверены временем. Приходите через пару столетий - к тому моменту DES с 56 битым ключом станет уже более-менее проверенный.
> Такие важные вещи следует писать на проверенных временем и хорошо зарекомендовавших себя языках.
> Таких как Forth или Cobol.Forth и Cobol еще не прошли проверку временем. Латынь - и то получше (вон товарищ выше правильно предлагает шифр Цезаря). А вообще шумерская клинопись - самое то.
>А вообще шумерская клинопись - самое то.Зря смеёшься. Мне кажется, что шумерская клинопись более устойчива к взлому, чем "DES с 56 битым ключом".
>>А вообще шумерская клинопись - самое то.
> Зря смеёшься. Мне кажется, что шумерская клинопись более устойчива к взлому, чем
> "DES с 56 битым ключом".речь моего беззубого дедушки намного устойчивее, хрень разберёшь, что говорит ))
пс: 97666
>>А вообще шумерская клинопись - самое то.
> Зря смеёшься. Мне кажется, что шумерская клинопись более устойчива к взлому, чем "DES с 56 битым ключом".Кто вам сказал, что я смеюсь?
> Зря смеёшься. Мне кажется, что шумерская клинопись более устойчива к взлому, чем "DES с 56 битым ключом".А если алгоритм шифрования реализован на брейнфаке, адаптированном под шумерскую клинопись - мало кто догадается, что это шифр Цезаря :)
зачем ваще писать ? SSL уже похоронили - забыли ?
История с выявлением в SSLv3 уязвимости POODLE (CVE-2014-3566), позволяющей извлечь из зашифрованного канала связи закрытую информацию, что привело к массовому прекращению поддержки SSLv3 в браузерах и в серверном ПО.
Пс: оставлю тут минусаторам, версию 4 еще не придумали)
> Ждём реализацию SSL на Rust.Ждем повсеместных замен OpenSSL на NaCl (Networking and Cryptography library).
Новость кагбэ про polarssl, не?
Кого это волнует?
а потому что malloc, используемый в любом коде, но особенно в security-critical коде, должен обнулять выделеный блок памяти автоматически. уж сколько раз твердили миру…хорошо, что я везде, где использую поляр, именно так malloc'и и починил давным-давно.
Окей, ты хочешь сказать что авторы polarssl ламеры и делают глупые ошибки, показывающие что они нифига не смыслят в безопасности. Я правильно тебя понял?Так, стоп, а нафига нужна криптографическая либа от ламеров которые нифига не смыслят в безопасности и раздают либу с крутыми ляпами?
> Окей, ты хочешь сказать что авторы polarssl ламеры и делают глупые ошибки,
> показывающие что они нифига не смыслят в безопасности. Я правильно тебя
> понял?это вот ты сейчас с кем говорил вообще?