URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 95331
[ Назад ]

Исходное сообщение
"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."

Отправлено opennews , 10-Апр-14 13:38 
Стали появляться (http://arstechnica.com/security/2014/04/heartbleed-vulnerabi.../) свидетельства возможного применения Heartbeat-уязвимости (http://www.opennet.me/opennews/art.shtml?num=39518) в OpenSSL (CVE-2014-0160) для совершения вредоносных действий за несколько месяцев до выявления проблемы сотрудниками  компаний Google и Codenomicon. Следы одной из таких атак зафиксированы компанией MediaMonks в журналах аудита, датированных ноябрём прошлого года. Сохранённые в журналах пакеты с нескольких серверов, подозреваемых во вредоносной активности, совпали по своему характеру с пакетами, применяемыми при эксплуатации Heartbeat-уязвимости.

По мнению (https://www.schneier.com/blog/archives/2014/04/heartbleed.html) Брюса Шнайера, известного эксперта в области компьютерной безопасности, Heartbeat-уязвимость в OpenSSL следует причислить к категории катастрофических уязвимостей, уровень опасности которой составляет 11 баллов, если рассматривать существующую 10-бальную шкалу степеней опасности с учётом того, что OpenSSL является самой распространённой криптографической библиотекой в Сети.


Благодаря широкому освещению проблемы за два дня с момента её обнародования около 1/3 всех серверов уже применили обновление с устранением уязвимости. Тем не менее, по предварительным данным в Сети ещё остаются (http://blog.erratasec.com/2014/04/600000-servers-vulnerable-...) уязвимыми около 600 тысяч серверов. Но проблема далека от своего решения - непонятно, что делать со встраиваемыми и мобильными продуктами, подверженными уязвимости, но не предусматривающими возможность автоматического обновления прошивки.

Кроме того, начинается волна атак на клиентские приложения, использующие OpenSSL. Например, вслед за появлением (http://www.opennet.me/opennews/art.shtml?num=39529) эксплоитов для серверных систем уже доступен (https://github.com/Lekensteyn/pacemaker) прототип эксплоита с реализацией фиктивного HTTPS-сервера, при обращении к которому осуществляется атака на клиента. Эксплоит успешно протестирован для извлечения данных из памяти таких приложений, как  wget 1.15, curl 7.36.0, links 2.8, git 1.9.1, MariaDB 5.5.36 (клиент), nginx 1.4.7 (в режиме прокси). Например, можно извлечь параметры прошлых запросов, в том числе содержащих пароли доступа.


В условиях возможности незаметного проведения атаки, без оставления следов в логе, также предстоит длительный процесс смены SSL-сертификатов, ключей шифрования и обычных паролей, отсутствие утечки которых невозможно гарантировать. Потенциально любой пароль и сертификат мог попасть в руки злоумышленников, и непонятно, когда и где подобные утечки могут проявиться. Из крупных сайтов, которые потенциально могли подвергнуться атаке отмечаются (http://news.netcraft.com/archives/2014/04/08/half-a-million-...) Twitter, GitHub, Yahoo, Tumblr, Steam, DropBox, а также многие банки и финансовые сервисы.


Шнайер считает близкой к единице вероятность того, что различные спецслужбы уже успели воспользоваться уязвимостью для массового извлечения приватных ключей. Другой вопрос, случайно или нет подобная уязвимость появилась в OpenSSL. Даже если проблема была внесена случайно, за два года присутствия в кодовой базе заинтересованные лица вполне могли её обнаружить и молча использовать.

URL: http://arstechnica.com/security/2014/04/heartbleed-vulnerabi.../
Новость: http://www.opennet.me/opennews/art.shtml?num=39544


Содержание

Сообщения в этом обсуждении
"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 10-Апр-14 13:38 
>а также многие банки и финансовые сервисы

А как ругали карточки одноразовых кодов ВТБ-шные, а.
Как же, каменный век, Java, сертификаты, прогресс, СМС.


"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 19:16 
Карточки одноразовых кодов - это круто. А в почту тоже логиниться по карточке одноразовых кодов? И в жаббер? Слушай, а может проще тогда сообщения доставлять голубями? Впрочем, на этот случай есть граждане с рогатками. Хотя стоп, они уже давно проапгрейдились до пневматики с оптическим прицелом, так что перехватят ваши сообщения, как пить дать.

"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено XoRe , 10-Апр-14 22:26 
> Карточки одноразовых кодов - это круто. А в почту тоже логиниться по
> карточке одноразовых кодов? И в жаббер? Слушай, а может проще тогда
> сообщения доставлять голубями? Впрочем, на этот случай есть граждане с рогатками.
> Хотя стоп, они уже давно проапгрейдились до пневматики с оптическим прицелом,
> так что перехватят ваши сообщения, как пить дать.

Не стоит передергивать.
Если когда-нибудь лишитесь 3700 евро со счета, поймете прелесть одноразовых паролей при работе с деньгами.


"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 23:17 
> Если когда-нибудь лишитесь 3700 евро со счета, поймете прелесть одноразовых паролей при
> работе с деньгами.

Странно, ворочаю килобаксами/килоевро по счетам уже 7 лет. Как-то пока все ок (да, я очень внимательно изучаю все списки транзакций).


"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 10-Апр-14 23:59 
Ну если клобаксами, то, полагаю, можете чувствовать себя спокойно, изготовление копии  сим-карты оценивается как раз примерно в килобакс. Когда дойдете до хотя бы десятков, чего я вам искренне желаю, а лучше - сотен, тогда советую задуматься.

"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 02:15 
>  изготовление копии  сим-карты оценивается как раз примерно в килобакс.

Весьма зависит от симкарты. Старые можно дома, на коленке. Древняя атака с вычислением Ki по куче запросов. Сейчас вроде oпcocы перешли на другой алгоритм генерации ответа, как минимум кто-то из них, там этой проблемы нет. Но честно говоря не особо мониторил что там сейчас творится.

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

Ну, знаешь, если ты сотнями ворочаешь - тут и охрана пригодится уже, etc.


"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 11-Апр-14 02:26 
> Древняя атака с вычислением Ki по куче запросов

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


"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 02:59 
> Какие ж вы, гики, предсказуемые.

Такие же как и вы. Люди вообще достаточно предсказуемы. Особенно глупые.

> (как "потерянной") любым заинтересованным лицом новой сим-карты (с вашим номером)

А тут у вас продолб в терминологии, по поводу чего вас и не поняли. Копия - то что совпадает с оригиналом.  А это не "копия" сим карты, скорее "перевыпуск", в том плане что авторизация будет прописана заново, на новую симку. Содержимое SIM будет совершенно новым - wtf "копия"? При этом старая карта работать по идее перестанет, что будет весьма шустро обнаружено владельцем. И уж наверное те кто ворочает сотнями k$ может позволить себе отдельный мобильник и отдельный номер для вещей связанных с банковскими операциями. Хотя даже само по себе знание мобильника опять же не позволяет ничего умыкнуть.

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


"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено XoRe , 12-Апр-14 23:59 
> Ну если клобаксами, то, полагаю, можете чувствовать себя спокойно, изготовление копии  
> сим-карты оценивается как раз примерно в килобакс.

Да каво, дешевле можно)
Но сейчас банки палят смену симкарты и не присылают смс на новую симку.
После замены надо позвонить в банк/зайти в отделение.
А там килобакса не хватит.


"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено XoRe , 13-Апр-14 00:03 
>> Если когда-нибудь лишитесь 3700 евро со счета, поймете прелесть одноразовых паролей при
>> работе с деньгами.
> Странно, ворочаю килобаксами/килоевро по счетам уже 7 лет. Как-то пока все ок
> (да, я очень внимательно изучаю все списки транзакций).

Тю. Атаки уровня heartbleed тоже годами не было)
Анализа уже совершенных транзакций мало.
Если счет на физ лицо, можно очень быстро вывести деньги на только что созданный кошелек qiwi/yandex/etc, потом на другой, потом вывести на какую-нибудь не именную карточку, и снять.


"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 11-Апр-14 00:05 
>А в почту тоже логиниться по карточке одноразовых кодов?

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


"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 02:16 
> почему бы и нет.

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


"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 11-Апр-14 02:36 
> Сканирование? Сетчатки глаза? Чипом с проприетарной фирмварой? Не-не-не, Дэвид Блейн,
> засуньте ваши зонды себе. А я такой системой пользоваться вообще не
> буду

Как тонка эта грань между паранойей и шизофренией.
Вы в чипе CCD-камеры не пробовали зонды искать? А в LM317?

> целиком перейду на какой-нибудь биткоин и полностью возьму ответственность
> за их кражу у меня на самого себя.

Непонятно что здесь меняет конечная цель аутентификации (биткойн, e-mail, пароль к сейфу с почтовыми голубями), если мы говорим о способах аутентификации.

А по большому счету ответственность и так на вас. Вы попробуйте как-нибудь на досуге оспорить транзакцию, проведенную вами через интернет-банкинг в российском банке, на практике. Узнаете много интересного.


"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 03:10 
> Как тонка эта грань между паранойей и шизофренией.
> Вы в чипе CCD-камеры не пробовали зонды искать? А в LM317?

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

> Непонятно что здесь меняет конечная цель аутентификации (биткойн, e-mail, пароль к
> сейфу с почтовыми голубями), если мы говорим о способах аутентификации.

Мне не придется мудохаться с всякими мегазондами претендующими на мою биометрию, несекурными протоколами, клиентами на всяком жаба-деpьме и прочими отходами мозговой деятельности. Оно не сольет логи в налоговую. И не заморозит счета при введении санкций. А где именно будут храниться фантики-циферки - мне если честно все-равно. Они один фиг абстракция. И так и эдак, в любой инкарнации. Биткоины использовать достаточно комфортно. И как их защищать с хорошим уровнем безопасности я более-менее понимаю. И не надо никаких почтовых голубей и прочих бумажек с одноразовыми паролями. Хватит оффлайнового кошелька, например. Отключенный оффлайн компьютер еще ни 1 хакер ломать не научился :)

> А по большому счету ответственность и так на вас. Вы попробуйте как-нибудь
> на досуге оспорить транзакцию, проведенную вами через интернет-банкинг
> в российском банке, на практике. Узнаете много интересного.

Поэтому я на самом деле достаточно компетентно и осторожно пользуюсь онлайн оплатой, оценивая риски и лимитируя возможный урон. То-есть для всяких покупок и прочего я вообще visa virtual использую, там можно и назваться Mr. Cardholder'ом, и денег - только впритык на покупку, etc. Спирать нечего будет :)


"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено bugmenot , 11-Апр-14 05:06 
Вы таки не поверите, но...
http://www.opennet.me/opennews/art.shtml?num=38583
http://www.pvsm.ru/radiosvyaz/55388/print/

"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 10:32 
Это вообще к чему? Ну TCP/IP. Ну по побочному каналу. И что?

"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено bugmenot , 11-Апр-14 17:43 
К тому, что машина, не имеющая доступ к сети, но стоящая в одном помещении с машиной, такой доступ имеющей - потенциально все равно уязвима. Поэтому "отправить машину в оффлайн" это не панацея, увы, в современном мире.

"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 20:59 
> потенциально все равно уязвима.

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


"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено iZEN , 11-Апр-14 21:17 
>> потенциально все равно уязвима.
> Потенциально, вам завтра на голову может упасть метеорит. Ничему не противоречит. Ну
> вот вероятность этого - примерно такая же как машина с чистой
> операционкой станет обмениваться по воздуху данными с соседями через микрофон. И,
> кстати, у моего десктопа например чисто физически нет микрофона. Очень интересно,
> придет агент АНБ и с раздосадованной миной подарит мне микрофон, чтобы
> я его подключил? Или чего?

У ноутбуков есть микрофоны. И они практически всегда включены.



"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 22:31 
> У ноутбуков есть микрофоны. И они практически всегда включены.

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


"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 12-Апр-14 00:08 
Компьютеры в оффлайне, а сотовый наверняка с андроидом. И наверняка подключали его к компьютеру по usb (чтоб зарядить, например).. Лучше б подискутировали на тему, как можно передавать данные с Андроида, если в нём выключен интернет вообще. И как с помощью одной симки можно получить полный контроль над телефоном.

"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 12-Апр-14 08:29 
это чаще использется для сопоставления данных по мобильным устройствам и ноутам/настольным.
то есть, для связывания воедино и идентификации (и отслеживания его перемещения)пользователя, более надежной, нежели для пенетрации и/или коммуникации с зондами, в АНБ, ЦРУ и ко.

"Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."
Отправлено iZEN , 16-Апр-14 18:50 
>>а также многие банки и финансовые сервисы
> А как ругали карточки одноразовых кодов ВТБ-шные, а.
> Как же, каменный век, Java, сертификаты, прогресс, СМС.

Алексей Шипилёв — Прагматика Java Memory Model: http://www.youtube.com/watch?v=iB2N8aqwtxc


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 13:46 
Столько паники из-за капли в океане. Про спецслужбы - вообще смешно. Они и без того обязаны следить за разработкой таких продуктов и проводить аудит всех патчей к ним. Думаю, они о ней знали (и эксплуатировали) уже через месяц - два после её появления.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Нанобот , 10-Апр-14 14:55 
>Думаю, они о ней знали (и эксплуатировали) уже через месяц - два после её появления

зря ты недооцениваешь спецслужбы... об уязвимости они знали (и эксплуатировали) за месяц-два то её появления


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 10-Апр-14 15:17 
За десятки лет до появления OpenSSL спецслужбы уже написали инструментарий для эксплуатации её будущих уязвимостей. Срочно в номер.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено EuPhobos , 10-Апр-14 17:24 
<irony>
Были особые люди, которые решили создать спецслужбы для того, что бы они спроектировали и написали сам OpenSSL
</irony>

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 19:30 
> За десятки лет до появления OpenSSL спецслужбы уже написали инструментарий для эксплуатации

В каком-то роде. SSL и TLS наархитектили так, что секурно ими пользоваться почти невозможно. А навороченная либа неизбежно содержит 100500 багов.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 10-Апр-14 23:38 
>наархитектили так, что секурно ими пользоваться почти невозможно

И это вы тоже склонны приписать страшным спецслужбам?


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 14:09 
> И это вы тоже склонны приписать страшным спецслужбам?

Учитывая как NIST-у протолкали несекурный ГПСЧ, не удивлюсь если и протокол старались сделать так, чтобы секурно и без лажи его фиг с два получилось реализовать.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 00:24 
Сказано словно можно создать (и уже создано) что-то более простое и секьюрное.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 11-Апр-14 01:33 
Это вы шутите так или действительно видели человека, утверждающего что чего-то более простого и секьюрного чем OpenSSL создать невозможно, и он над вами не глумился в этом момент?

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 02:18 
> Сказано словно можно создать (и уже создано) что-то более простое и секьюрное.

Такого человека звали D.J. Berstein. И он таки сделал это - либу NaCl. У нее простое логичное апи, даже дуболому негде облажаться. А еще она может шифровать даже отдельные пакеты, не в пример меньше кластрефака чем в SSL.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 19:15 
Всё может быть. Только тогда это спецслужбы какой-то одной страны... с хорошим мозговым центром.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено iZEN , 10-Апр-14 14:07 
Да всё протроянено на высшем уровне. Вы как вчера родились.

Как можно доверять секретную и конфиденциальную информацию иностранной операционной системе, которая подключена к их же сети?!


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 19:47 
Это ты сам у себя спрашиваешь? ;)

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Andrey Mitrofanov , 11-Апр-14 09:44 
> Это ты сам у себя спрашиваешь? ;)

У голосов в голове. И они отвеча-а-ают...


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено XoRe , 10-Апр-14 22:32 
> Да всё протроянено на высшем уровне. Вы как вчера родились.
> Как можно доверять секретную и конфиденциальную информацию иностранной операционной системе,
> которая подключена к их же сети?!

Как вы можете пользоваться буржуйским браузером, который запущен во вражеской ОС, работающей на ПК, собранным потенциальным противником?


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено iZEN , 10-Апр-14 22:47 
>> Да всё протроянено на высшем уровне. Вы как вчера родились.
>> Как можно доверять секретную и конфиденциальную информацию иностранной операционной системе,
>> которая подключена к их же сети?!
> Как вы можете пользоваться буржуйским браузером, который запущен во вражеской ОС, работающей на ПК, собранным потенциальным противником?

Всё просто: все заинтересованные в обладании конфиденциальной информации юридические и физические лица действуют в правовом поле и подчиняются институтам права. Не будь этого, SSL/TLS ничего бы не стоило без сквозного контроля на каждом уровне представления информации. Другими словами, в беспределе нужно было бы каждой группировке/человеку разрабатывать собственное железо и ПО, как-то согласовывать протоколы обмена информацией с другими такими же лицами. При этом собеседники должны принимать ряд базовых вещей от простейших рефлексов до космических технологий, что невозможно в принципе в обществе, где никакие законы (кроме физической силы) не действуют. ;)

В АНБ могут в любой момент списать некую сумму с любой пластиковой карточки любого гражданина их или не их страны, но не делают этого. Вопрос: почему?

Думаю, понятно объяснил.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 23:41 
> карточки любого гражданина их или не их страны, но не делают
> этого. Вопрос: почему?

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


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено user , 11-Апр-14 14:04 
Насчет гопстопа. У нас на работе несколько человек получали з/п на карточки Собин-банка. Картой раплатиться они не могли, да, но снять с нее деньги в отделении банка - без проблем, ни одной копейки не потерялось.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 14:06 
> Картой раплатиться они не могли, да, но снять с нее деньги
> в отделении банка - без проблем, ни одной копейки не потерялось.

И зачем нужна карточка, которой можно пользоваться только в отделении какого-то банка? Мне тогда проще получать сразу наликом - его в любом магазине принимают, минус время на посещение банка.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено user , 11-Апр-14 16:36 
>> Картой раплатиться они не могли, да, но снять с нее деньги
>> в отделении банка - без проблем, ни одной копейки не потерялось.
> И зачем нужна карточка, которой можно пользоваться только в отделении какого-то банка?
> Мне тогда проще получать сразу наликом - его в любом магазине
> принимают, минус время на посещение банка.

Получайте, разрешаю


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 20:55 
> Получайте, разрешаю

Ну а вы оставьте такие карточки себе, для меня они ничего кроме дополнительного геморроя не дают.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено user , 11-Апр-14 23:16 
Так уж и быть, можете не брать такие карточки.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено t28 , 12-Апр-14 12:00 
> в беспределе нужно было бы каждой группировке/человеку разрабатывать
> собственное железо и ПО, как-то согласовывать протоколы обмена информацией
> с другими такими же лицами.

Все эти механизмы, интерфейсы и протоколы были учтены и разработаны в CCITT при ООН ещё в 70-е—80-е годы. Стандарты открыты — бери и пользуйся. Только в этих ваших интернетах решили делать всё по-своему. В принципе, это очень хорошо, если бы также параллельно развивались ITU-T-шные концепции. Однако из-за фактического отсутствия альтернативы паре IEEE + The Internet имеем что имеем. Причём пропихнуть на внешний рынок что-то прогрессивное и хорошее, но несовместимое со стандартами IEEE сейчас просто невозможно. А в отличие от ITU, IEEE — частная американская конторка, куда вас могут и не принять по каким-нибудь идеологическим причинам.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Андрей , 10-Апр-14 14:20 
А в роутерах на WRT прошивке или в серверных IMPI интерфейсах эта библиотека случайно не используется?

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Sabakwaka , 10-Апр-14 14:44 
Совершенно случайно нет.
Уязвимостью чревата сама идея TLS Heartbeat. На уровне замысла.
И мы еще услышим.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 15:40 
Расскажите.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Sabakwaka , 10-Апр-14 16:20 
> Расскажите.

Суть TLS Heartbeat, как следует из драфта
http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04

есть «the usage of keep-alive functionality without performing a renegotiation».

Типа, если есть прокисшее SSL соединение, то «TLS Heartbeat»
будет позволять продолжать считать его доверенным на основании вот того
свободного размена данными, который происходит сейчас в атаке bleed.

То есть поле для новых злоупотреблений просто непаханное.

И все это просто для того, чтобы не надо было жать кнопочку «Refresh»
после трех часов простоя окошка с данными кредитки, типа.

Типа, страшно удобно. Данные формы можно держать, типа, восемь суток
и не забивать по новой номер кредитки, если соединение оторвется.

Как без этого жили, да.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 20:41 
Хотя идея heartbeat довольно дурная сама по себе, сабж тут не виноват. В сабже довольно крутой баг с утеканием памяти в сеть. Это не было задумано. Это просто лютый баг в либе. Одной конкретной либе.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено balda , 11-Апр-14 06:26 
В сабже довольно крутой баг с утеканием памяти в сеть. Это не было задумано. Это просто лютый баг в либе. Одной конкретной либе.

...Одной конкретной либе.
...Одной конкретной либе.
...Одной конкретной либе.
...Одной конкретной либе.
...Одной конкретной либе.
...Одной конкретной либе.


и там до посинения. Может станет правдой )))


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 10:34 
> и там до посинения. Может станет правдой )))

В других либах именно этого бага - нет. Зато может быть куча иных, не менее веселых. Навороченному протоколу - куча багов, все честно.

Впрочем, вам с вашим ником простительно нести чушь.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 12-Апр-14 04:56 
да не, автор коммента - прав.
реально убогая идея для решения несуществующей проблемы.
та-же хрень с курисами в браузерах для аутентификации, благодаря чем - мы до сих пор не имеем нормальной авторизации в веб-е.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Тампарам , 11-Апр-14 17:50 
Для реализации heartbeat достаточно было бы определить пакеты для запроса и ответа. Они же там наворотили зачем-то "отправку запрошенного количества байтов". Ну и программер явно был в доле, потому что не специально отправить по запросу произвольное количество байт - очень сложно.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено pavlinux , 10-Апр-14 14:49 
На OpenWRT какой-то свой шайтан-ssl-сервер писанный на LUA.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 10-Апр-14 15:36 
Сервер-то свой, а суть всё та же.

http://luci.subsignal.org/trac/browser/luci/trunk/libs/nixio...


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 20:43 
> На OpenWRT какой-то свой шайтан-ssl-сервер писанный на LUA.

На LUA там написаны скрипты которые морду рисуют. Сервер там самопальный, uhttpd, но писан он таки на сях. А шифрование он таки из OpenSSL вроде как использует, так что если некто вывесил его в WAN или публично доступный LAN - ахтунг, ахтунг, ахтунг.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Онаним , 10-Апр-14 16:01 
> А в роутерах на WRT прошивке или в серверных IMPI интерфейсах эта
> библиотека случайно не используется?

1. ATTITUDE ADJUSTMENT (12.09, r36088):
root@OpenWrt:~# opkg info libopenssl
Package: libopenssl
Version: 1.0.1e-1
"Системы, использующие выпуски OpenSSL 1.0.1[abcdef], требуют срочного обновления."
Да и gnutls-utils - 2.8.6-2 там есть. Одна радость, что ни то, ни другое по умолчанию не стоит.

2. Не "IMPI", а IPMI. И скорее всего да! Хотя, кто ее - блобятину знает... Если ниже 1.0.1, то нет. Можете проверить свои сервера одэем и нам их IP рассказать )


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено mickvav , 10-Апр-14 16:19 
У меня единственное место, где живет IPMI настолько древнее, что 1.0 openssl еще не написали тогда. И в инет не смотрит :)

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 20:44 
> Да и gnutls-utils - 2.8.6-2 там есть.

А при тем тут gnutls? В нем какие-то баги есть? В openssl баг специфичный для этой либы.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 11-Апр-14 00:07 
> А при тем тут gnutls? В нем какие-то баги есть?

"Уязвимость оценивается как очень серьёзная и подрывающая доверие к проекту. Ховард Чу (Howard Chu), главный архитектор проекта OpenLDAP, ещё в 2008 году выступал с рекомендацией прекращения использования GnuTLS в связи с несоблюдением элементарных правил безопасности в кодовой базе GnuTLS, в частности, повсеместном использовании функций strlen и strcat. По мнению Ховарда, исправить ситуацию может только полный пересмотр API GnuTLS"
http://www.opennet.me/opennews/art.shtml?num=39239


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 02:22 
> "Уязвимость оценивается как очень серьёзная и подрывающая доверие к проекту.

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


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 11-Апр-14 02:40 
Осталось ответить на вопрос почему им никто не пользуется.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 03:15 
> Осталось ответить на вопрос почему им никто не пользуется.

Появился относительно недавно. И, кстати, кто сказал что им не пользуются? В последнее время NaCl/libsodium(более портабельный вариант) использует довольно много софта. Откуда я про них и узнал, собственно.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Тампарам , 11-Апр-14 17:51 
>> "Уязвимость оценивается как очень серьёзная и подрывающая доверие к проекту.
> А, про это я уже забыл. Ну а что, нагородили меганавороченные протоколы
> с кучей фич - получите кучу багов в их реализациях. Вроде
> логично. Хорошие вещи должны быть простыми. Теперь вы понимаете почему мне
> нравится NaCl. Очень прикольно сделанный диффи-хеллман на эллиптических кривых с неплохой
> подборкой алгоритмов. И апи которым может пользоваться даже простой смертный, а
> не только супергуру.

Эллептические кривые - прямиком из лабораторий АНБ. Хрен знает что они там придумали.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 20:51 
> Эллептические

У... я так смотрю, вы мегамозг. Только не спрашивайте как я это узнал :).

> кривые - прямиком из лабораторий АНБ.

Вы переоцениваете АНБ. Эллиптические кривые, FYI, придумали математики. А АНБ всего лишь вовремя подсуетилось, чтобы NIST подсунуть бажную реализацию ГПСЧ на их основе, не более. Вот кстати выбору кривых от NIST я бы доверять не стал. Но какой-нибудь Берштейн, его группа любителей криптографии и выбранные ими кривые - к NIST и АНБ относятся чуть менее чем никак. Ну нет у АНБ эксклюзивных прав на довольно базовые конструкции из области математики.

> Хрен знает что они там придумали.

С таким уровнем знаний лучше молчать в тряпочку и не высовываться. За умного сойдешь. А когда вы занимаетесь тем что распостраняете ламерский буллшит, абсолютно не разбираясь в вопросе и даже не зная как пишется слово "эллипс" - это пржде всего выставляет лично вас некомпетентным болваном, который, тем не менее, имеет мнение. То-есть, ламером.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Тампарам , 12-Апр-14 08:12 
Берштейну или какому-нибудь его помощнику АНБ просто заплатило немножко денег, чтобы направить его поиск в нужном направлении. Никто ж не заметит и все доверяют.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 12-Апр-14 08:33 
> Берштейну или какому-нибудь его помощнику АНБ просто заплатило немножко денег, чтобы направить
> его поиск в нужном направлении. Никто ж не заметит и все
> доверяют.

про скандал с обоим закладками от АНБ, проплаченными RDA за миллионы баксов - читали ?
там в обоих случаях - так нефигово, в тысячи раз, была ослаблена реализация =)
мораль: имея физическую возможность давления на разработчика(не суть частное лицо или компанию, комьюнити) и/или mitm-интерференции с их работой - это не ахти какой сложности задача для Люьбой спецслужбы )


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Sabakwaka , 12-Апр-14 13:26 
> сложности задача для Люьбой спецслужбы )

ВСЕ «системы шифрования» уязвимы ПРИНЦИПИАЛЬНО.
На уровне ДИЗАЙНА, на уровне МАТ. МОДЕЛИ, положенной в их основу.
«Бекдоры», тривиальные состояния системы, существуют в них ПРИНЦИПИАЛЬНО.

Ради того, чтобы банкомат хавал 4-х значный PIN.
С некоторой степенью надежности.

Или носи с собой бумажку с набором одноразовых 108-буквенных паролей, или PIN,
но с возможностью обнаружения и утечки эксплойта.

При этом, самый тупой «шифр» прошлого ТЫСЯЧЕЛЕТИЯ — НИКАК И НИЧЕМ НЕ ВСКРЫВАЕТСЯ.

Так что хорош пенить ситро.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 12-Апр-14 22:26 
>бумажку с набором одноразовых

Вот видите, совсем не все "системы шифрования» уязвимы ПРИНЦИПИАЛЬНО"

>108-буквенных паролей

Пяти-шести-цифровых вполне достаточно IRL


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Sabakwaka , 12-Апр-14 13:17 
Эллиптические кривые - прямиком из оснований математики, вообще-то.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 14:05 
> А в роутерах на WRT прошивке

Там по дефолту ничего SSLного в сеть не торчит вроде. Но если торчит - да, заапдейтить надо.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено MPEG LA , 10-Апр-14 14:25 
gmail, fb и vk попали под раздачу?

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 20:47 
> gmail, fb и vk попали под раздачу?

Вполне вероятно. Более того - баг вывешивает память процесса в сеть, так что даже приблизительно оценить масштабы пи...ца будет довольно сложно.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Andrey Mitrofanov , 11-Апр-14 09:47 
> что даже приблизительно оценить масштабы пи...ца будет довольно сложно.

Шнайер облегчает наши сомнения: 11 из 10 баллов.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Sw00p aka Jerom , 10-Апр-14 14:36 
баг специально внесли из-за коммерческой выгоды, все попёрли менять ssl сертификаты - круто

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Sabakwaka , 10-Апр-14 14:44 
> баг специально внесли из-за коммерческой выгоды, все попёрли менять ssl сертификаты -
> круто

Да ну?


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Нанобот , 10-Апр-14 14:46 
>все попёрли менять ssl сертификаты

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


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено pavlinux , 10-Апр-14 15:25 
Для "истеричек, паникёров и лохов..." ниже показал скриншот,
с реально рабочего сервера, с довольно полезной инфой для конкурентов.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 20:48 
> попёрли менять сертификаты только истерички, паникёры и лохи, которые

...которые не хотят сливать свои пароли и приватные ключи всему миру. Только вот они то как раз не лохи. Лохи - те кто этого не сделал. По поводу чего в будущем их будет ждать мнооооого интересных поимений.

> предприимчивые дельцы, баг в openssl - лишь очередной способ из подоить,
> не первый и не последний

То что PKI лохоразвод - вы, конечно, правы, но в данном случае пи...ц таки имеет место быть.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено serverX , 10-Апр-14 14:54 
я бесплатно перевыпустил свои сертификаты. причем сроки сертификатов остались старыми.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Тампарам , 12-Апр-14 08:10 
Старые-то заэкспайрить не забыли? :)

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено pavlinux , 10-Апр-14 14:36 
Redmine тоже дырявый. http://i59.fastpic.ru/big/2014/0410/2e/9fd0122735fb7d475abc7...

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Xaionaro , 10-Апр-14 14:57 
Как данный скриншот указывает на дырявость Redmine?

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено pavlinux , 10-Апр-14 15:01 
> Как данный скриншот указывает на дырявость Redmine?

Cookie: _redmine_session и далее по тексту ...assword=v_pupkin&login=Login+vasya

Для тех кто не в курсе: Redmine может работать как в режиме CGI, или как самостоятельный сервер.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено XoRe , 10-Апр-14 22:35 

> Для тех кто не в курсе: Redmine может работать как в режиме
> CGI, или как самостоятельный сервер.

Но это не значит, что его надо так запускать.
Вообще, веб сервер на Ruby - не самый лучший фронтенд :)
Лучше спрячьте за nginx, мой вам совет.
nginx обновить может быть куда проще.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Xaionaro , 11-Апр-14 08:25 
>> Как данный скриншот указывает на дырявость Redmine?
> Cookie: _redmine_session и далее по тексту ...assword=v_pupkin&login=Login+vasya
> Для тех кто не в курсе: Redmine может работать как в режиме
> CGI, или как самостоятельный сервер.

А причём тут "дырявость" redmine-е, если данные получены через уязвимость libssl? (или может вообще обычным tcpdump - не знаю как были получены данные не screenshot-е).


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 10:37 
> А причём тут "дырявость" redmine-е,

При том что пароль в открытом виде фигачат, полагаясь на "защиту соединения", которая не очень то и защищает.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Xaionaro , 11-Апр-14 22:01 
>> А причём тут "дырявость" redmine-е,
> При том что пароль в открытом виде фигачат, полагаясь на "защиту соединения",
> которая не очень то и защищает.

А другие Web ITS как работают?


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 22:34 
> А другие Web ITS как работают?

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


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Xaionaro , 12-Апр-14 00:19 
>> А другие Web ITS как работают?
> Так же как и все остальное от веб хомячья, разумеется. Т.к. дыра
> на дыре и дырой погоняет.

Ну, получается, что >95% сайтов с поддержкой аутентификации (включая www.opennet.ru) - дырьё.

Я согласен, что передавать plaintext пароли даже через SSL - моветон. Но "обычный пользователь" не способен освоить аутентификацию по сертификатам, а делать а-ля CHAP на базе JS - это изврат. А другие варианты не очень совместимы сквозь зоопарк браузеров.

В любом случае, вне зависимости от того, насколько это соответствует правилам хорошего тона, данная особенность Redmine не является дырой. Это просто известная особенность современных web-ресурсов и известными методами защиты, и с известными проблемами этих методов.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено anonymus , 10-Апр-14 15:31 
А потом все удивлялись, откуда такой ажиотаж вокруг сноудена, все же знали, что следят. Видимо, без капитана сноудена наивные обыватели не способны представить во что выливаются те или иные технические проколы. А как только посмотрят презентацию с надписью "собрано 2 миллиарда ключей" - так сразу начнут вопить как резанные.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 17:58 
мало того, некоторым и выступлений Сноудена недостаточно

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 20:50 
> Redmine тоже дырявый.

Ну что ты как маленький, скрипткидизы думали что мегалиба сделает им зашибись. Поэтому слали пароль открытым текстом, как есть. А теперь пора выкусить результаты.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 15:20 
> но не предусматривающими возможность автоматического обновления прошивки.

А Столман давно говорит, что надо делать.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 03:15 
> А Столман давно говорит, что надо делать.

Ну дык. Использовать девайсы где исходники прошивки есть.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Ansomgsom , 10-Апр-14 15:40 
Писали открытый ССЛь, скопипастили проприетарный код не глядя :)

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 16:32 
причем наверняка АНБ :)

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено anonymous , 10-Апр-14 17:43 
> причем наверняка АНБ :)

Как будто список спецслужб мира состоит из одного АНБ. Все они одним миром мазаны.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 18:00 
> Как будто список спецслужб мира состоит из одного АНБ. Все они одним
> миром мазаны.

может и не АНБ, но американская точно


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 19:20 
>> Как будто список спецслужб мира состоит из одного АНБ. Все они одним
>> миром мазаны.
> может и не АНБ, но американская точно

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


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 21:54 
> над чем задуматься, правда? ;)

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


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 12-Апр-14 09:09 
ха, я был прав http://lenta.ru/news/2014/04/12/heartbleed/

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 16:37 
Ловим гадов через iptables

 
iptables -I INPUT -p tcp -m string --algo kmp --hex-string '|18 03 02 00 03 01 40 00|' -j LOG --log-level debug --log-prefix "ScriptKiddy detected: "


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 20:51 
> "ScriptKiddy detected: "

Действительно, detected: залоггил и забил. Ну а дропать пакет кто будет, Пушкин? :)



"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 21:15 
...и вместо 40 00 может быть нечто другое...

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 21:53 
> ...и вместо 40 00 может быть нечто другое...

Я знаю. Зато запись в логе понтовую - нарисовал. Вот как-то так скрипткидисы и детектируются :).


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 21:56 
> ...и вместо 40 00 может быть нечто другое...

И детектировать как string... ну в общем, намного более нормальный рецепт написан в советах: http://www.opennet.me/tips/2830_openssl_block_iptables_heart...

Тут вам и логгинг, и удавка пакета, и, блин, ищется u32 а не string, что по идее заметно быстрее.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено pavlinux , 11-Апр-14 12:30 
>> ...и вместо 40 00 может быть нечто другое...
> И детектировать как string... ну в общем, намного более нормальный рецепт написан
> в советах: http://www.opennet.me/tips/2830_openssl_block_iptables_heart...
> Тут вам и логгинг, и удавка пакета, и, блин, ищется u32 а
> не string, что по идее заметно быстрее.

То чудное правило, банит всех подряд кто пытается установить соединение с heatbeat опцией.

Например 128.140.169.183 - mail.ru, забанило.

DKIM: d=mail.ru s=mail2 c=relaxed/relaxed a=rsa-sha256 [verification succeeded]
P=esmtps X=TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 16:37 
Появились сведения (http://techrights.org/2014/04/08/howard-schmidt-codenomicon/), что публикация данных о Heartbeat-уязвимости является манёвром Microsoft, отвлекающим от проблем, вызванных прекращением поддержки Windows XP, и направленным  на будущую дискредитацию СПО в глазах потребителей.

Уязвимость раскрыта в день прекращения поддержки Windows XP и активно продвигается с использованием ранее не применяемых в СПО PR-методов (например, был создан отдельный сайт heartbleed.com). Председателем совета директоров открывшей уязвимость компании Codenomicon является Howard Schmidt, бывший глава службы безопасности Microsoft.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено pavlinux , 10-Апр-14 16:40 
Ну чо, спасибо посанам из маздайсофта, спалили бэкдор!!! Дайте иcчо! :)
А под Debian 6 и SLES нету? А то какбэ они не дырявые.  

> Уязвимость раскрыта в день прекращения поддержки Windows XP и активно продвигается

Google, Dropbox, Facebook уже бегут ставить на свои сервера Вантуз 8, ога.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 18:02 
всё может быть

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 19:54 
И шо они скажут? В Windows Next самое неуязвимое шифрование? :) Кто им поверит? Не, ну конечно, те кто и раньше безропотно заглатывали их "продукты" и дальше глотать будут. Таких и убеждать не надо.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено некто , 10-Апр-14 22:03 
типа не переходите c XP на сторонние *nix-системы, там все плохо, вот например дыра в openssl. Но ведь стэк openssl используется и на винде и во многом входит/заимствован в составе инфраструктуры винды в части криптографии. Ибо как IE реализует https?

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Волкот , 10-Апр-14 22:36 
http://www.securitylab.ru/vulnerability/449697.php
дыра во всех виндах с 2001 года. им и без openssl хорошо.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Адекват , 11-Апр-14 08:15 
> криптографии. Ибо как IE реализует https?

Оффтоп - а почему IE не может пройти авторизацию, если пароль передается в виде хеша md5 ?
Просто тупо правильный пароль не подходит - во всех остальных браузерах все ок.



"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 10:40 
Возьми снифер да посмотри что там передается по факту. Может он digest авторизацию считать не умеет? Или что ты там используешь...

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено ALex_hha , 10-Апр-14 23:48 
> Появились сведения (http://techrights.org/2014/04/08/howard-schmidt-codenomicon/),
> что публикация данных о Heartbeat-уязвимости является манёвром Microsoft, отвлекающим
> от проблем, вызванных прекращением поддержки Windows XP, и направленным  на
> будущую дискредитацию СПО в глазах потребителей.

а какое отношение имеет openssl к линуксу как таковому?


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 03:17 
> а какое отношение имеет openssl к линуксу как таковому?

А никакого. Чуть погодя юзеры виндов узнают сколько софта юзало статически влинкованную либу и по этому поводу бессовестно продалбывало их данные злонамеренным серверам.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Andrey Mitrofanov , 11-Апр-14 09:51 
> либу и по этому поводу бессовестно продалбывало их данные злонамеренным серверам.

Ну, за здоровье IIS! Не чокаясь.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 10:40 
> Ну, за здоровье IIS! Не чокаясь.

Ага, здоровый зомбяк. Все время из могилы вылезает, зараза.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Andrey Mitrofanov , 11-Апр-14 10:49 
>Все время из могилы вылезает, зараза.

Спонсер-вурдалак-некромансер бдит и собирает opennet.ru/openforum/vsluhforumID3/81138.html#34 opennet.ru/openforum/vsluhforumID3/74800.html#285 жатву. [тёмный жнец]


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 17:31 
> Спонсер-вурдалак-некромансер бздит

//fixed.

> и собирает

И апачует.

> opennet.ru/openforum/vsluhforumID3/74800.html#285 жатву.

Что-то нет там ничего, видимо потерли.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено некто , 10-Апр-14 16:47 
У них там в загашниках типа еще есть гостинцы?

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено axe , 10-Апр-14 16:56 
вангую появление новой библиотеки

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено anonymous , 10-Апр-14 17:44 
> вангую появление новой библиотеки

Попроси вангователь у анонима сверху. NaCl уже есть.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено pavlinux , 10-Апр-14 18:21 
> ... NaCl уже есть.

а PoCl и NeСl будут?


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 19:23 
>> ... NaCl уже есть.
> а PoCl и NeСl будут?

Не, не так. KCl и Na(OH)2


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Michael Shigorin , 10-Апр-14 19:37 
> Не, не так. KCl и Na(OH)2

Выделил оценку по неорганике, если что.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 00:06 
Извиняюсь, перепутал валентность металлов.
Если так напишу:
Na(OH)2-
Ион сойдёт за оправдание? :)

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 02:24 
> Ион сойдёт за оправдание? :)

А что за ион такой странный? NaOH диссоциирует на Na+ и OH-. А это что за хрень?


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 08:53 
Теоретически возможный в какой-либо момент времени. Разумеется, сразу распадётся, как образуется.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Andrey Mitrofanov , 11-Апр-14 09:53 
> Теоретически возможный в какой-либо момент времени. Разумеется, сразу распадётся, как
> образуется.

полимеры Na[NN]OH[MM] тоже по броску кости могут образовываться!


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 20:38 
Если и будут, то будет PoCl на всех 3х, ибо NeCl

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 02:25 
> ибо NeCl

Да, удачи вам заставить неон провзаимодействовать с хлором...


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Адекват , 11-Апр-14 08:16 
>> ибо NeCl
> Да, удачи вам заставить неон провзаимодействовать с хлором...

При помощи кувалды и такой-то матери...


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 10:45 
> При помощи кувалды и такой-то матери...

Сдается мне, тут даже термоядерная кувалда может спасовать.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено pavlinux , 11-Апр-14 12:24 
>> При помощи кувалды и такой-то матери...
> Сдается мне, тут даже термоядерная кувалда может спасовать.

Вдуваешь в баллон 50% неона, 50% хлора, взбалтываешь! Опа!  


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Michael Shigorin , 11-Апр-14 12:49 
> Вдуваешь в баллон 50% неона, 50% хлора, взбалтываешь! Опа!

Расслаивается и продолжает болтаться себе.  Неон вообще-то инертен.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено pavlinux , 11-Апр-14 13:17 
>> Вдуваешь в баллон 50% неона, 50% хлора, взбалтываешь! Опа!
> Расслаивается и продолжает болтаться себе.

Надо было добавить, "Взболтать перед употреблением"

>   Неон вообще-то инертен.

Ну это его проблемы, взболтать никогда не помешает (к инициирующим ВВ не относится)


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 22:37 
> Надо было добавить, "Взболтать перед употреблением"

Ну вот в сабже не добавили, видишь чего получилось?


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено некто , 10-Апр-14 18:28 
> вангую появление новой библиотеки

давно пора разнообразие, хотя на примере ffmpeg/libav особенного прогресса не наблюдается...


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 10-Апр-14 23:42 
Да и ядро ОС неплохо бы, основанное не на идеях 50-летней давности.
А множатся что-то лишь нескучные хипстерские обои. Странно, да?

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 00:25 
> Да и ядро ОС неплохо бы, основанное не на идеях 50-летней давности.

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


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 11-Апр-14 01:31 
>> Да и ядро ОС неплохо бы, основанное не на идеях 50-летней давности.
> А зачем чинить то что не сломано?

Точно не сломано? Что ж тогда всё чинят и чинят, и всё костылями да костылями, один другого неприглядней.

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

То-то у всех ваших гаджетов блоки питания линейные, с большими трансформаторами. Хотя постойте..



"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 01:59 
> Точно не сломано? Что ж тогда всё чинят и чинят, и всё
> костылями да костылями, один другого неприглядней.

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

> То-то у всех ваших гаджетов блоки питания линейные, с большими трансформаторами. Хотя
> постойте..

То-есть, подъем частоты преобразования не меняет на фундаментальном уровне принцип его работы. Это лишь позволяет сделать трансформатор меньше по размеру.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 19:34 
Я всегда знал, что даже на Tor полностью надеяться нельзя.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено anonymous , 11-Апр-14 01:49 
В области распространения германских языков Тору посвящён день недели — четверг (англ. thursday, нем. Donnerstag). по четвергам можно пользоваться

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 11:07 
> Я всегда знал, что даже на Tor полностью надеяться нельзя.

В конструкции сети Tor есть минимум 2 серьезных упущения, вообще никак не связанных с SSL.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 13-Апр-14 08:07 
учитывая кем и для чего был разработан Тор, ваша ремарка - может лишь улыбку, вызвать )

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 19:42 
>Другой вопрос, случайно или нет подобная уязвимость появилась в OpenSSL.

Это вопрос не "другой", это вопрос самый главный.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено lucentcode , 10-Апр-14 20:23 
Да, такого фейла ещё не было наверное в истории IT. А некоторые люди ещё и отказываются обновлять OpenSSL на своих серверах. Это было бы смешно, если не было бы так печально...

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Oinari , 10-Апр-14 20:47 
Debian oldstable спасает.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 21:51 
> Debian oldstable спасает.

Совсем не включать компьютер - надежнее.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 20:26 
> люди ещё и отказываются обновлять OpenSSL на своих серверах.

Не пользуйтесь такими серверами. Проипут они ваши данные и логины с паролями.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено iZEN , 10-Апр-14 20:24 
C/C++ всё погубил.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 20:40 
> C/C++ всё погубил.

Но жабка мало чего годного из либ родила


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 20:55 
> C/C++ всё погубил.

Остальные облажались бы еще раньше, ибо GC и тому подобные - криптографии не друг и не товарищ: ключи из памяти требуется изничтожать предсказуемо, как только они перестали требоваться, затерев явным образом. А не "когда GC раздуплится" и "хрен его знает насколько он там почистит". На твоей жабе способов прострела себе пятки в криптографии в 100500 раз больше. И уж там дыр сроду было всех сортов и размеров. Их по 30 штук критикалов в каждом релизе давят. Просто все уже привыкли к тому что там постоянный п....ц и уже не обращают на него внимания.  


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено iZEN , 10-Апр-14 21:25 
>> C/C++ всё погубил.
> Остальные облажались бы еще раньше, ибо GC и тому подобные - криптографии
> не друг и не товарищ: ключи из памяти требуется изничтожать предсказуемо,
> как только они перестали требоваться, затерев явным образом. А не "когда
> GC раздуплится" и "хрен его знает насколько он там почистит". На
> твоей жабе способов прострела себе пятки в криптографии в 100500 раз
> больше. И уж там дыр сроду было всех сортов и размеров.
> Их по 30 штук критикалов в каждом релизе давят. Просто все
> уже привыкли к тому что там постоянный п....ц и уже не
> обращают на него внимания.

Java написана на C/C++, поэтому в ней полно дыр. Очевидно и логично.



"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 10-Апр-14 21:49 
> Java написана на C/C++, поэтому в ней полно дыр. Очевидно и логично.

Логика жабиста: во всем виноваты ... нет, не программисты. Си и плюсы во всем виноваты, о как. Вот это я понимаю, ламерство. Впрочем, в openssl есть ламерство и на уровне чистейшей алгоритмики, вообще без привязки к сям и плюсам. Ну вот например, почему криптографическая либа, поюзав память, вообще не чистит ее после юзежа? Ах, авторы раздолбаи и не парятся? Ах, еще и malloc перехватили, чтобы система на могла поумничать. Замечательно. Правда такое по смыслу долбоклюйство можно повторить на любом ЯП, а экспонаты с GC еще и помогут наступить на грабли дюжиной неочевидных способов, прихранив ключи в памяти еще на полчасика, хотя об этом никто не просил. Ведь GC лучше знает когда ключ протух, правда?


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено iZEN , 10-Апр-14 22:06 
>> Java написана на C/C++, поэтому в ней полно дыр. Очевидно и логично.
> Логика жабиста: во всем виноваты ... нет, не программисты. Си и плюсы
> во всем виноваты, о как.

Потому что ЯП C/C++ допускают использование памяти небезопасным способом даже из другого потока — что и продемонстрировано уже миллион раз. Это на уровне ДНК конкретного языка и лечится только сменой ЯП.

> Вот это я понимаю, ламерство.

Понимай как хочешь. Как был упёртным синюшником, так и проживёшь им до старости. А там уж маразм прихватит — не до других концепций программирования будет.

> Впрочем,
> в openssl есть ламерство и на уровне чистейшей алгоритмики, вообще без
> привязки к сям и плюсам. Ну вот например, почему криптографическая либа,
> поюзав память, вообще не чистит ее после юзежа?

Наверно потому, что в C/C++ нет возможности определить, понадобится эта память ещё раз или нет — лучше перестраховаться, чем нарываться периодически на NullPointerException (или что там у вас обозначает NPE: Error, "сливай воду — программа выполнила недопустимую операцию и будет свалена в кору", "память не может быть Read"?).

> Ах, авторы раздолбаи и не парятся?

Да разработчики на C/C++ что и делают, так это парятся, как бы их поделия были устойчивыми и не ловили NPE на ровном месте — там, где другие языки давно ушли по эволюционной лестницы от смарт-поинтеров и null-терминейт массивов с алгоритмами Шлемиля к чётко определённым структурам данных заведомо известных типов без всяких оверхедов на RTTI.

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

Ты Java Memory Model изучил, чтобы такую чепуху городить здесь?



"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Anonym2 , 10-Апр-14 23:52 
>> Впрочем,
>> в openssl есть ламерство и на уровне чистейшей алгоритмики, вообще без
>> привязки к сям и плюсам. Ну вот например, почему криптографическая либа,
>> поюзав память, вообще не чистит ее после юзежа?
> Наверно потому, что в C/C++ нет возможности определить, понадобится эта память ещё
> раз или нет - лучше перестраховаться, чем нарываться периодически на NullPointerException
> (или что там у вас обозначает NPE: Error, "сливай воду -
> программа выполнила недопустимую операцию и будет свалена в кору", "память не
> может быть Read"?).

Не де Билл ли? :-)


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 00:15 
> Потому что ЯП C/C++ допускают использование памяти небезопасным способом

У криптографов свои, очень кастомные понятия отом что такое "безопасность", чувак. Так, навскидку:
1) Стандартные функции сравнения сравнения двух кусков памяти криптографам не нравятся. Дело в том что положительный и отрицательный результат возвращается за разное время. Что позволяет туеву хучу тайминг-атак, позволяющих угадывать ключи/пароли по косвенным признаками типа "за какое время приехал отлуп". Но жабисты о таком подумают потом, когда какой-нибудь гад пароль из 20 символов подберет за полчаса, меряя время отклика после проверки пароля и последовательно подбирая по букве. Так что 26^20 (или сколько там) плавно станет 26 * 20 (в хучшем случае). "Небольшое" упрощение подбора на основе таймингов, да? :)
2) Управление памятью требуется весьма тонкое и гранулярное. Надо аккуратно выделять, аккуратно освобождать, вовремя затирать, защищать от чтения другими/попадания в своп/etc. Не комильфо если другой процесс спи...т из нашего ключ, правда? Еще менее здорово если некто посторонний получит блок памяти который мы ранее юзали. А том - обана! - наш приватный ключ. Который никто не удосужился прибить оттуда.

> даже из другого потока — что и продемонстрировано уже миллион раз. Это на уровне
> ДНК конкретного языка и лечится только сменой ЯП.

Про ДНК ты прав, только для исправления ДНК надо не кровати переставлять, а менять б-дей^W программистов, пардон. Вот ты криптографические операции не напишешь безопасно ни на каком языке. Ни на жабе, ни на питоне, ни на си, на на брейнфаке.

> Понимай как хочешь. Как был упёртным синюшником, так и проживёшь им до
> старости. А там уж маразм прихватит — не до других концепций
> программирования будет.

Как раз си нормально ложится на криптографию. Он быстрый и там есть тонкое управление памятью, которое вообще-то должно использоваться для того чтобы криптография была реально безопасной, ну и он прост и предсказуем как топор, нет шансов что рантайм поумничает и подставит реализатора незапланированными/неучтенными свойствами. Криптография чувствительна к низкоуровневой механике и самым базовым свойствам самых простейших операций, типа сравнения 2 массивов. Впрочем, лабухов пишущих openssl это не касается - они с выделением памяти там нахимичили такого, что мало не покажется. В смысле, они выделение памяти перехватили, но ... не для того чтобы протирать освобожденные регионы, что было бы логично для криптографической либы и зарубило бы на корню атаку типа сабжа, а для того чтобы тормоза на каких-то особо кривых платформах воркэраундить. Елки, ну нихрена себе расстановка приоритетов у криптографической либы! Заметь, это организационная проблема - проблема расстановки приоритетов, etc.

> Наверно потому, что в C/C++ нет возможности определить, понадобится эта память ещё
> раз или нет — лучше перестраховаться,

Наверное потому что недопустимо чтобы блок памяти c приватным ключом уехал кому-то еще, выпал в своп и прочая, засветив приватный ключ посторонним юзерам, процессам, etc. Вот поэтому надо явно затереть блок при деаллокации. Ну это так, если по нормальному делать. В openssl с этим все оказалось плохо. Но виноват в этом не си, а те сапожники которые это писали. Это продолб на уровне принятия решений, для начала.

> программа выполнила недопустимую операцию и будет свалена в кору", "память не
> может быть Read"?).

Знаешь, если привкей с которым работала программа может быть read когда этого быть не должно - это пипец и лютый баг. Сабж если что как раз про это. Кроме всего прочего, либа для шифрования оказывается довольно фривольно относится к содержимому памяти после деаллокации, да еще и мешает параноикам типа опенбздунов это фиксить. Что для криптографической либы вообще-то FAIL. Или уж сами протирайте, или уж хоть другим не мешайте. Но нет, эти с... починили тормоза в кривых платформах. Зато теперь они сливают память с паролями и привкеми по всему интернету. Вот это я понимаю, отсутствие мозга у разработчиков. Нет, я уже увидел достаточно признаков что они те еще ламеры, но чтобы _настолько_, что ...

> Да разработчики на C/C++ что и делают, так это парятся, как бы
> их поделия были устойчивыми и не ловили NPE на ровном месте

В криптографии вообще иные приоритеты. Приоритет номер ноль - не продолбать приватные ключи и прочий чувствительный материал. Это кроме всего прочего подразумевает при реализации в нормальном виде весьма аккуратное fine grained управление памятью и внимательность в самых базовых операциях. Криптографы ходят по минному полю и ошибаются 1 раз. В си на поле 10 мин, а в жабе - 5000. Ты какое предпочитаешь разминировать? :)

Прочий ламерский бред поскипан.

> Ты Java Memory Model изучил, чтобы такую чепуху городить здесь?

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


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено vn971 , 11-Апр-14 12:07 
Ругаетесь вы клёво, но всё-таки выход за рамки массива -- это таки то что хочется чтобы запрещал язык.
Я понимаю что всегда можно обвинить в тупизне разраба -- и так оно и есть. Но умных разрабов не бывает (имхо). Так что до тех пор пока мы не идеальны, а проги наши не верифаятся "математически" компьютером -- надо ожидать от себя ошибок. В частности, не говорить что без плохого менеджмента и руководства мы написали бы хороший софт. И признавать недостатки языка вместо оправдывания оного.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 18:46 
> Ругаетесь вы клёво, но всё-таки выход за рамки массива -- это таки
> то что хочется чтобы запрещал язык.

По конкретно этому пункту - я даже согласен до некоторой степени. И сдается мне что проще это оформить как расширение си/си++ чем бодаться с мегасложным рантаймом, пытаясь из него предсказуемость нужную криптографам выжать.

> Я понимаю что всегда можно обвинить в тyпизне разраба -- и так
> оно и есть. Но умных разрабов не бывает (имхо).

Не совсем так. Каждый должен заниматься своим делом. А если дворник поперся булки печь, получился какой-то трэш и хлебозавод несет адские убытки - человек занимался не своим делом, по поводу чего закономерно получился хреновый результат. Ну вот от тех кто лезет писать криптографическую либу ожидается некое понимание проблематики области и соответствюущее мышление и квалификация. Если этого не наблюдается - будет честно, если у него сольется репутация и он будет известен как БРАКОДЕЛ, продукцию которого использовать не стоит.

Ну так вот, посмотрим на уязвимость. Пароли, говорите, отсылаются? Из памяти? Ок! А какого, собственно, пароли в памяти забыли? Коли она не занята и вообще? Ах, пароли и ключи никто не чистил, после того как они перестали быть нужны? Воооооо! В этом месте мы начинаем догадываться: начальный источник проблем - это оно, а то что такая память так или иначе может утекать - СЛЕДСТВИЕ более фундаментальной проблемы: какие-то удоды не чистят за собой память с чувствительными данными. Заметьте, блок памяти может не только улететь в сеть из-за бага либы. Какая-нибудь программа в другом месте может выделить себе блок памяти. И если никто расчисткой не заморачивался - там ВНЕЗАПНО окажутся эти ключи и пароли. Круто, правда? А то что это другой пользователь и другой процесс - нууу... никто же не чистил память! По изначальной идее, пароли и ключи живут в памяти абсолютно минимально необходимое время и как только не требуются - явно затираются. Это нагибает такие векторы атак. Если бы это было сделано - утечка памяти, конечно, неприятно, но не была бы фатальной. А вот в таком виде - тут только остается гадать: где еще оно выстрелит в следующий раз? В многозадачной многопользовательской системе процесс для начала живет не один. И результаты его жизнедеятельности могут в принципе оказаться доступны другим, если они не озаботились этим вопросом.

> Так что до тех пор пока мы не идеальны, а проги наши не
> верифаятся "математически" компьютером

А тут нам Тюринг объяснил что нет в жизни счастья. Одна программа не может анализировать другую произвольную программу и выносить какой либо определенный вердикт. FAIL.

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

Хороший софт начинается с грамотного программиста. Если некто хочет что-то делать с криптографией, он для начала должен начать мыслить как криптограф. Вокруг враги. Враги хотят спереть наши данные. И придется параноидально защищать от них каждый бит. Тогда враг [может быть] не пройдет. А если оно как в openssl - там еще много интересных багов бомбанет, совершенно независимо от того, будет ли проверка диапазона массива. Замести мусор под ковер - это не фикс. Ведь намного более фундаментальная проблема "куча ценных данных болтается в памяти неопределенный срок и их никто не чистит" - никуда от проверки границ не делась. А если "мы, тут, типа, соединение защищаем", да еще с API как у OpenSSL, которое сколь-нибудь секурно использовать может только тот кто в криптографии уже неплохо разбирается - это примерно как дедушка-сторож, у которого из вооружения только клюка, против банды из десяти головорезов.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено vn971 , 11-Апр-14 20:21 
> А тут нам Тюринг объяснил что нет в жизни счастья. Одна программа не может анализировать другую произвольную программу и выносить какой либо определенный вердикт. FAIL.

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

В общем, я имею в виду вот эту технологию:
https://en.wikipedia.org/wiki/L4_microkernel_family
(Current research and development) Посмотрите, это может быть интересно.:)
> It has been formally verified,[11] which means that there is a (machine-checked) mathematical proof that the implementation is consistent with the specification. This provides a guarantee that the kernel is free of implementation bugs such as deadlocks, livelocks, buffer overflows, arithmetic exceptions or use of uninitialised variables. seL4 is claimed to be the first-ever general-purpose operating-system kernel that has been verified.[11]


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 22:56 
> любой другой скажет остановится ли она. Но у нас _одна_ программа
> анализ которой нужно сделать.

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

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

> В общем, я имею в виду вот эту технологию:
> https://en.wikipedia.org/wiki/L4_microkernel_family

Ну понятно, очередной академик натирающий мозоли на микроядра.

> (Current research and development) Посмотрите, это может быть интересно.:)

Я уже забыл сколько лет я слышу эту фразу от любителей микроядер. Уже были minix и hurd, etc. У них всех было кое-что общее: они нафиг никому не уперлись на обычных серверах, десктопах и прочем. Знаете, называя вещи своими именами, я тоже могу написать простой тасквичер без багов. Ну это так, если идею микроядра довести до абсолюта. А на баги в остальных компонентах системы сделать козью морду - мол, не мои баги, "это все они".

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

> provides a guarantee that the kernel is free of implementation bugs such as deadlocks,
> livelocks, buffer overflows, arithmetic exceptions or use of uninitialised variables.

Да я тоже простейший тасксвичер напишу без багов. А кому он будет нужен? В общем то единственная проблема с микроядрами: там просто сложные вещи перепихнуты на чуть другие головы, поэтому те кто писал "тасксвичер" могут встать в позу Д'Артаньяна и гордо заявить что у них багов нет. Это вполне может быть правдой, в силу того что само микроядро мелкое. К сожалению это означает лишь то что сложные моменты перепихнули в иные компоненты. И, заметим, про их верификацию все технично молчат в тряпочку. Поэтому секурным оно будет в тепличных условиях, у академиков в лаборатории, где одно лысое ядро которое ничего не делает. А сделай из этого десктопник, с навороченными драйверами и софтом - и будет все как обычно.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено vn971 , 11-Апр-14 23:03 
Ээээ, я просто объяснял что значит компьютерно-верифицированная программа..

И, кстати, как и в математике -- доказательства легко можно модифицировать в случае небольших изменений требований в задаче. То есть, версия никуда гвоздями не прибита. Модифицируешь код, модифицируешь доказательство кода -- всё ок.

На счёт времени верифицирования -- вы не правы, оно очень мало. Все возможные состояния никто не рассматривает, так же как не рассматривают все возможные состояния неупорядоченного массива когда доказывают корректность bubble sort (мелом на доске).


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Anonym2 , 10-Апр-14 22:53 
> Ну вот например, почему криптографическая либа,
> поюзав память, вообще не чистит ее после юзежа? Ах, авторы раздолбаи
> и не парятся? Ах, еще и malloc перехватили, чтобы система на
> могла поумничать.

А зачем её чистить? Вся программа должна быть достаточно надёжной, в составе которой работает эта библиотека. И которой программе как-то все секретные пароли даются и она ими управляет... :-)


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 00:21 
> А зачем её чистить?

Чтобы врагам не досталось! Ну там другим процессам, другим юзерам, etc. Не айс будет если какой-то хмырь выделит себе блок памяти, а там бац - привкей от банка с миллионом лежит! Потому что его никто оттуда не снес, вы прикиньте?

> Вся программа должна быть достаточно надёжной,

И в рамках криптографии надежность кроме всего прочего подразумевает защиту ключей от утечки. Блокирование памяти от доступа другими процессами. Запрет выгрузки в своп. Затирание нулями как только ключ более не требуется, etc. Параноидальное отношение к самым базовым операциям, типа операций сравнения. Это отдельная тонкая механика. И ее проще всего реализовать на простом и предсказуемом рантайме. Потому что допинать сложный навороченный рантайм до кондиции когда его фичи не будут вызывать внезапный прострел пяток в самых непредсказуемых ситуациях - сложно, да.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 11-Апр-14 01:23 
>допинать сложный навороченный рантайм до кондиции когда его фичи не будут вызывать внезапный прострел пяток в самых непредсказуемых ситуациях - сложно, да

Но заказчики хотят Java, так что будут допинывать.
Вот у low-latency лагеря те же проблемы - http://mechanical-sympathy.blogspot.ru/2012/03/fun-with-my-c...


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 11-Апр-14 02:04 
А в real-time мире так и к С++ больше вопросов чем ответов.
http://www.embedded.com/design/programming-languages-and-too...

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 02:10 
> А в real-time мире так и к С++ больше вопросов чем ответов.

Меньше чем к яве. А так то да - чем проще некая конструкция, тем она предсказуемее. А в криптографии это далеко не последнее дело. Вон scrypt'у например припомнили что там время работы зависит от cache hit/cache miss. Вроде пустячок, а тайминг атаки потенциально позволяет. Так появились catena, sponge и т.п, время работы которых - более-менее постоянное, независимо от характера данных.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 02:04 
> Но заказчики хотят Java, так что будут допинывать.

Ну, если заказчик просит веревку и мыло - надо ему их выдать. А если он в них повесится - это уже на его совести.

> Вот у low-latency лагеря те же проблемы

Насколько я помню, MS со своим дотнетом вылетел с LSE в том числе и за неспособность обеспечить обещанные времена задержек. Как зашел вопрос о бабле - они и на си++ софт переписали, и линух поставили. Потому что бабло побеждает зло.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Anonym2 , 11-Апр-14 04:07 
>> А зачем её чистить?
> Чтобы врагам не досталось! Ну там другим процессам, другим юзерам, etc. Не
> айс будет если какой-то хмырь выделит себе блок памяти, а там
> бац - привкей от банка с миллионом лежит! Потому что его
> никто оттуда не снес, вы прикиньте?
>> Вся программа должна быть достаточно надёжной,
> И в рамках криптографии надежность кроме всего прочего подразумевает защиту ключей от
> утечки. Блокирование памяти от доступа другими процессами. Запрет выгрузки в своп.
> Затирание нулями как только ключ более не требуется, etc.

Нельзя сказать, что UNIX не подразумевает...

Многие не верят, что кое у кого все программы на отдельных машинах. (при чём виртуальных) :-)
Но вообще OPENSSL_cleanse есть. И иногда используется... Затирает даже не нулями.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 19:08 
> Нельзя сказать, что UNIX не подразумевает...

Сами по себе многозадачки общего назначения не страдают в общем случае такой паранойей, т.к. это сильно тормозило бы работу программ.

> Многие не верят, что кое у кого все программы на отдельных машинах.
> (при чём виртуальных) :-)

Я верю, концепты типа "1 контейнер = 1 сервис" мне по вкусу. Но это никак не адресует тот факт, что если освобожденный блок памяти явно не протерт ровно в тот момент когда ключ/пароль/etc перестали требоваться - потенциально кто-то другой может его получить. На уровне физики процесса. Оно чисто физически лежит в ячейках RAM, покуда кто-то не запишет туда что-нибудь другое. По этой причине те кто не полный дятел в криптографии - сносят чувствительные данные из памяти и протирают этот регион бесполезными данными сразу как только ценные данные перестали быть нужны.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Anonym2 , 11-Апр-14 20:00 
> Сами по себе многозадачки общего назначения не страдают в общем случае такой
> паранойей, т.к. это сильно тормозило бы работу программ.

...сказал Микрософт (вслед за кое кем вероятно) и выпустил DOS NIX.
>:-)


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 20:15 
> выпустил DOS NIX.

Нечто такое называлось DJGPP и было GCC для DOS и даже какие-то либы. Правда я не в курсе насколько там POSIX и стандартные вызовы всяких libc были реализованы :).


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Anonym2 , 11-Апр-14 04:36 
> Не
> айс будет если какой-то хмырь выделит себе блок памяти, а там
> бац - привкей от банка с миллионом лежит! Потому что его
> никто оттуда не снес, вы прикиньте?

Много уже было украдено до нас...


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено rob pike , 10-Апр-14 23:46 
Предлагаю сразу кремний.. да что там, просто физику во всём обвинять. Какие к нам вопросы, это всё Бор с Эйнштейном, да.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 00:22 
> Предлагаю сразу кремний.. да что там, просто физику во всём обвинять. Какие
> к нам вопросы, это всё Бор с Эйнштейном, да.

Ну а что, это процессор во вем виноват! Он программу написанную лабухом выполняет! Вот детектировл бы он IQ автора программы и отказывался бы запускать код от изенов - сразу стало бы безопаснее в два раза.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено vn971 , 11-Апр-14 11:54 
> ключи из памяти требуется изничтожать предсказуемо, как только они перестали требоваться, затерев явным образом

конкретно в этом вы не правы, кажется. Никто не мешает уничтожать. Хочешь - уничтожай.
array[i] = 0
(или какой там синтаксис у джавы, забыл уже.)


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено vn971 , 11-Апр-14 11:59 
* я конкретно про приход gc.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 20:09 
> конкретно в этом вы не правы, кажется. Никто не мешает уничтожать. Хочешь - уничтожай.

Жабисты все время уповают что за них рантайм подумает и GC освободит. А с GC и прочим тут еще проблема в том как все это хранится внутри и что на самом деле будет сделано. В сях если мы записываем в array[i]=0, можно быть более-менее уверенным что это будет обращение в память и там это будет реально так (btw, еще и кэш процессора в этой механике может поднасpaть, прецеденты были). А чем сложнее рантайм - тем это менее очевидно и требует куда больше знаний о том как он там внутри это видит, чтобы не прострелить себе пятку совершенно неочевиднейшим образом. Если некто может мониторить обращения в массив и рубать оные, он, очевидно, что-то еще делает, потенциально имея дело с нашими данными. Насколько он там внутри себя параноидально относится к утечкам этих данных - очень отдельный такой вопрос. И я не думаю что типовой жабист вообще имеет хоть какое-то понятие как его жаба с массивами работает. Это делает схему в целом куда менее предсказуемой и стало быть чреватой самыми неожиданными прострелами пяток в самых разнообразных местах. Просто потому что например array[i]=0 не трансформировалось в физическую запись в память по нужному адресу и значение ключа там по факту допустим убито не было. Мало ли чего там мегаумный рантайм оптимизнуть решит, etc. Для этого надо очень хорошо знать как он работает и мониторить его развитие.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено vn971 , 11-Апр-14 20:25 
Да, тут с вами полностью согласен. Человек просто говорил именно о GC и сборке мусора (имея в виду, видимо, иммутабельные String-и). А между тем проблем куча, но таки они не в том как GC стринги чистит.

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 23:09 
> и сборке мусора (имея в виду, видимо, иммутабельные String-и).

Я в целом имел в виду мою возможность анализировать поведение получившейся конструкции и понимать что в какой момент времени она делает и является ли фактический результат работы тем чем было задумано в изначальной логики оной, что в криптографии важно. Чем сложнее конструкция, тем сложнее ее анализировать. Поэтому в жабе неизбежно будут кучи багов. И в реализациях SSL. Они просто навороченные до ж...ы. Так что кучи багов там обеспечены, независимо от ЯП. Некоторые баги будут проблемами безопасности. Так что в этом плане мне очень нравится тезис Берштейна: меньше кода - меньше багов. Проблема лишь в том что софт который ничего не умеет - никому и даром не сдался... :)


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено iZEN , 11-Апр-14 23:43 
>> и сборке мусора (имея в виду, видимо, иммутабельные String-и).
> Я в целом имел в виду мою возможность анализировать поведение получившейся конструкции
> и понимать что в какой момент времени она делает и является
> ли фактический результат работы тем чем было задумано в изначальной логики
> оной, что в криптографии важно. Чем сложнее конструкция, тем сложнее ее
> анализировать.

Анализу помогают модульные и другие виды тестов. В C/C++ это на зачаточном уровне (лишь недавно во FreeBSD добавили test framework базовой системы, что говорит о печальной ситуации с покрытием тестами и автоматизацией тестирования системного кода!).

> Поэтому в жабе неизбежно будут кучи багов. И в реализациях
> SSL. Они просто навороченные до ж...ы.

Микропроцессоры с каждым годом становятся всё сложнее и сложнее, однако старые программы спонтанно не вылетают, хотя по твоей идее о сложности ДОЛЖНЫ!

> Так что кучи багов там обеспечены, независимо от ЯП.

В любой программе, сложнее "Hello World", есть баги.

> Некоторые баги будут проблемами безопасности.

Так в C/C++ они расставлены на уровне ДНК ЯП, а не программиста.

> Так что в этом плане мне очень нравится тезис Берштейна: меньше кода - меньше багов.

Про это ещё Вирт писал, я помню: http://www.osp.ru/os/1996/06/179017/


Оттуда ещё:
///---
Методологии, связанные с языками программирования, до сих пор являются предметом дискуссий. В 1970-х было принято верить, что проектирование программ должно опираться на хорошо структурированные методы и слои абстракции с четко определенными спецификациями. Лучше всего эта мысль выразилась в концепции абстрактного типа данных, которая и нашла свое воплощение в новых тогда языках, прежде всего в Modula-2 и Ada. Сегодня программисты оставляют хорошо структурированные языки и мигрируют, в основном, к Си. Язык Си не позволяет компилятору даже выполнять контроль безопасности типов, а ведь именно эта функция в наибольшей степени полезна при разработке программ для локализации концептуальных ошибок уже на ранней стадии. Без контроля типов само понятие абстракции в языках программирования становится пустым и имеющим чисто академический интерес. Абстракция может работать только в языках, постулирующих строгий статический типовой контроль для каждой переменной и функции. В этом отношении Си несостоятелен и, в сущности, подобен ассемблерному коду, где, правда, "все работает".
Весьма примечательно, что абстрактный тип данных через 25 лет после своего изобретения появился вновь под названием "объектно-ориентированный". По своей сути этот современный концепт (принимаемый многими как панацея) более всего связан с построением иерархий классов или типов. Более старое понятие не было, в сущности, понято, пока не появился новый ярлык "объектно-ориентированный"; теперь же программисты признали присущую абстрактному типу данных мощь и обратились, наконец, к нему. Однако, чтобы об объектно-ориентированных языках можно было говорить всерьез, в них должна быть реализована строгая статическая типизация, которую нельзя было бы нарушить; это дало бы возможность программисту полагаться на компилятор в деле идентификации разного рода несогласованностей. К сожалению, наиболее популярный язык, С++, неудовлетворителен в этом отношении, потому что было изначально декларировано, что он должен быть совместим со своим предком - языком Си. Широкое принятие С++ подтверждает следующие "законы":
* прогресс приемлем, только если он совместим с текущим состоянием;
* приверженность стандарту - всегда безопаснее, чем даже мотивированный отход от него.
Принимая эту ситуацию как данную свыше, программисты вступают в борьбу с языком, который не поощряет структурное мышление и дисциплинированное построение программ, отрицая базовую поддержку компилятора. Они также прибегают к инструментам-паллиативам, которые еще более способствуют разрастанию размеров программ.
---///

> Проблема лишь в том что софт который ничего не умеет - никому и даром не сдался... :)

Проблема не в софте, а в программистах, которые ничего не ели слаще пареной репы.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Michael Shigorin , 12-Апр-14 23:52 
> В любой программе, сложнее "Hello World", есть баги.

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


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено iZEN , 13-Апр-14 00:27 
>> В любой программе, сложнее "Hello World", есть баги.
> Когда у человека обе запятые в предложении на предположительно родном языке являются
> лишними -- как-то страшненько даже думать про то, что он может
> накодить.

См. придаточные определительные. Союзное слово "которая", которым прикрепляется придаточное определительные к главному предложению, признаюсь, мне лень было писать (думал, не обратят внимание). Однако же на форуме интеллектуального бахвальства всё-таки нашёлся умник, который указал на ошибку пунктуации. :))


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Michael Shigorin , 13-Апр-14 01:03 
>>> В любой программе, сложнее "Hello World", есть баги.
>> Когда у человека обе запятые в предложении на предположительно родном языке
>> являются лишними -- как-то страшненько даже думать про то, что он может
>> накодить.
> См. придаточные определительные.

Изя, если человек допускает детские ошибки -- он неграмотен.  Если в них упорствует -- он глуп.

Пожалуйста, сходите в школу, проконсультируйтесь у профильного преподавателя и не глупите.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено iZEN , 13-Апр-14 20:18 
> Изя,

Давай я тебя Мичманом буду называть, хорошо?

> если человек допускает детские ошибки -- он неграмотен.  Если в них упорствует -- он глуп.

Если человек хочет, но по каким-то причинам не может аргументированно поддеть другого человека, то начинает "танцевать" от замечания в адрес его внешнего вида и манеры общения. Стиль дворовой шпаны (гопников, по-современному), но в ракурсе интеллигенции ("илиты" IT, по-современному).

> Пожалуйста, сходите в школу, проконсультируйтесь у профильного преподавателя и не глупите.

Начни с себя. ;)


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Michael Shigorin , 13-Апр-14 21:34 
>> если человек допускает детские ошибки -- он неграмотен.
>> Если в них упорствует -- он глуп.
> Если человек хочет, но по каким-то причинам не может аргументированно поддеть

Если "другого человека" не пнул аргументированно только ленивый из как минимум трёх, а то и четырёх местных "лагерей" (ссылки собирать лень, но если так хочется сесть в лужу по полной -- можно), то "поддевать" такого смысла особого нет даже любителям поглумиться.

Изя, пытаться в ответ на вполне конкретный и благожелательный PR (который problem report) объявлять багу фичей -- глупо.  Пытаться переспорить человека, который, скажем так, немного лучше понимает в вопросе -- глупо в квадрате.

На сем позвольте откланяться, желаю скорейшего прихода в разум.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено iZEN , 13-Апр-14 21:44 
>[оверквотинг удален]
>>> Если в них упорствует -- он глуп.
>> Если человек хочет, но по каким-то причинам не может аргументированно поддеть
> Если "другого человека" не пнул аргументированно только ленивый из как минимум трёх,
> а то и четырёх местных "лагерей" (ссылки собирать лень, но если
> так хочется сесть в лужу по полной -- можно), то "поддевать"
> такого смысла особого нет даже любителям поглумиться.
> Изя, пытаться в ответ на вполне конкретный и благожелательный PR (который problem
> report) объявлять багу фичей -- глупо.  Пытаться переспорить человека, который,
> скажем так, немного лучше понимает в вопросе -- глупо в квадрате.
> На сем позвольте откланяться, желаю скорейшего прихода в разум.

От себя лишь могу выразить сожаление о случившемся. Ты меня очень разочаровал, Миша.



"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено iZEN , 11-Апр-14 21:14 
>[оверквотинг удален]
> что-то еще делает, потенциально имея дело с нашими данными. Насколько он
> там внутри себя параноидально относится к утечкам этих данных - очень
> отдельный такой вопрос. И я не думаю что типовой жабист вообще
> имеет хоть какое-то понятие как его жаба с массивами работает. Это
> делает схему в целом куда менее предсказуемой и стало быть чреватой
> самыми неожиданными прострелами пяток в самых разнообразных местах. Просто потому что
> например array[i]=0 не трансформировалось в физическую запись в память по нужному
> адресу и значение ключа там по факту допустим убито не было.
> Мало ли чего там мегаумный рантайм оптимизнуть решит, etc. Для этого
> надо очень хорошо знать как он работает и мониторить его развитие.

Ты нам поведал историю о том, что должен делать рядовой программист на C/C++, разрабатывая свою либу. Однако ж, это же самое относится и к программистам JVM, которые должны следовать соглашениям по модели памяти Java. Хорошо, что это не входит в круг решаемых задач прикладных программистов на языках JVM, а то бы они как разработчики OpenSSL/GnuTLS всё время находились между двух огней — небезопасным инструментом разработки и лёгкостью его применения не по назначению. ;)


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено vn971 , 11-Апр-14 22:10 
> это же самое относится и к программистам JVM

щито?


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено iZEN , 11-Апр-14 23:00 
>> это же самое относится и к программистам JVM
> щито?

JVM написана на C++. OpenJDK7u51 для компиляции JVM нужен GCC 4.6+ (LLVM/Clang не по зубам).



"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 23:10 
> JVM написана на C++. OpenJDK7u51 для компиляции JVM нужен GCC 4.6+ (LLVM/Clang
> не по зубам).

Изя, попробуй поспорить с берштейновским определением проблем безопасности: проблема безопасности - частный случай багов в программе. Всего лишь. Баги можно сажать на любом ЯП. Ну и проблемы безопасности будут на любом ЯП, соответственно.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 23:11 
> щито?

Знакомьтесь, это - изен. Жабист. Я чертовски уверен что он не сможет написать безопасную программу ни на каком ЯП вообще.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 15:10 
Кто-нибудь подскажет, ошибка при apt-get update (с https://mirrors.kernel.org/):
GnuTLS recv error (-9): A TLS packet with unexpected length was received.
Из-за исправления этой уязвимости? Как исправляется?

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 11-Апр-14 15:26 
А не, не из-за этой, само исправилось..

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 13-Апр-14 08:14 
> Кто-нибудь подскажет, ошибка при apt-get update (с https://mirrors.kernel.org/):
> GnuTLS recv error (-9): A TLS packet with unexpected length was received.
> Из-за исправления этой уязвимости? Как исправляется?

что GNUTLS, что GNUPG - мало того что код, вежливо говоря - написан странно, так еще и бинарники себя чудно ведут. даже версию под оффтопик - не раз ловили за "лазанием не туда", как-бы.


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено V , 11-Апр-14 17:58 
http://istheinternetfixedyet.com/

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено t28 , 12-Апр-14 11:27 
> могла эксплуатироваться с ноября прошлого года

Не было ни единого разрыва! Не-бы-ло!


"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."
Отправлено Аноним , 12-Апр-14 14:35 
http://dlang.ru/211-heartbeat-cve-2014-0160