форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
Сообщение от opennews on 10-Апр-14, 13:38
Стали появляться (http://arstechnica.com/security/2014/04/heartbleed-vulnerabi.../) свидетельства возможного применения Heartbeat-уязвимости (http://www.opennet.dev/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.dev/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.dev/opennews/art.shtml?num=39544
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+9 +/–
Сообщение от rob pike on 10-Апр-14, 13:38
>а также многие банки и финансовые сервисы А как ругали карточки одноразовых кодов ВТБ-шные, а. Как же, каменный век, Java, сертификаты, прогресс, СМС.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	47. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	–2 +/–
	Сообщение от Аноним (??) on 10-Апр-14, 19:16
	Карточки одноразовых кодов - это круто. А в почту тоже логиниться по карточке одноразовых кодов? И в жаббер? Слушай, а может проще тогда сообщения доставлять голубями? Впрочем, на этот случай есть граждане с рогатками. Хотя стоп, они уже давно проапгрейдились до пневматики с оптическим прицелом, так что перехватят ваши сообщения, как пить дать.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	78. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от XoRe (ok) on 10-Апр-14, 22:26
	> Карточки одноразовых кодов - это круто. А в почту тоже логиниться по > карточке одноразовых кодов? И в жаббер? Слушай, а может проще тогда > сообщения доставлять голубями? Впрочем, на этот случай есть граждане с рогатками. > Хотя стоп, они уже давно проапгрейдились до пневматики с оптическим прицелом, > так что перехватят ваши сообщения, как пить дать. Не стоит передергивать. Если когда-нибудь лишитесь 3700 евро со счета, поймете прелесть одноразовых паролей при работе с деньгами.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	84. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от Аноним (??) on 10-Апр-14, 23:17
	> Если когда-нибудь лишитесь 3700 евро со счета, поймете прелесть одноразовых паролей при > работе с деньгами. Странно, ворочаю килобаксами/килоевро по счетам уже 7 лет. Как-то пока все ок (да, я очень внимательно изучаю все списки транзакций).
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	91. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от rob pike on 10-Апр-14, 23:59
	Ну если клобаксами, то, полагаю, можете чувствовать себя спокойно, изготовление копии  сим-карты оценивается как раз примерно в килобакс. Когда дойдете до хотя бы десятков, чего я вам искренне желаю, а лучше - сотен, тогда советую задуматься.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	108. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Аноним (??) on 11-Апр-14, 02:15
	>  изготовление копии  сим-карты оценивается как раз примерно в килобакс. Весьма зависит от симкарты. Старые можно дома, на коленке. Древняя атака с вычислением Ki по куче запросов. Сейчас вроде oпcocы перешли на другой алгоритм генерации ответа, как минимум кто-то из них, там этой проблемы нет. Но честно говоря не особо мониторил что там сейчас творится. > Когда дойдете до хотя бы десятков, чего я вам искренне желаю, > а лучше - сотен, тогда советую задуматься. Ну, знаешь, если ты сотнями ворочаешь - тут и охрана пригодится уже, etc.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	114. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от rob pike on 11-Апр-14, 02:26
	> Древняя атака с вычислением Ki по куче запросов Какие ж вы, гики, предсказуемые. Килобакс - это верхняя граничная оценка оформления (как "потерянной") любым заинтересованным лицом новой сим-карты (с вашим номером) в салоне связи по "левым" документам с учетом материальной заинтересованности работника этого салона связи. Без всяких вычислений.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	117. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 02:59
	> Какие ж вы, гики, предсказуемые. Такие же как и вы. Люди вообще достаточно предсказуемы. Особенно глупые. > (как "потерянной") любым заинтересованным лицом новой сим-карты (с вашим номером) А тут у вас продолб в терминологии, по поводу чего вас и не поняли. Копия - то что совпадает с оригиналом.  А это не "копия" сим карты, скорее "перевыпуск", в том плане что авторизация будет прописана заново, на новую симку. Содержимое SIM будет совершенно новым - wtf "копия"? При этом старая карта работать по идее перестанет, что будет весьма шустро обнаружено владельцем. И уж наверное те кто ворочает сотнями k$ может позволить себе отдельный мобильник и отдельный номер для вещей связанных с банковскими операциями. Хотя даже само по себе знание мобильника опять же не позволяет ничего умыкнуть. А так то да, бывают странные люди разгуливающие с чемоданами денег по улице. И потом попадающие в сводки новостей - мол, отобрали чемодан и скрылись в неизвестном направлении. Ну пардон, если гуляешь с чемоданом бабла - надо соображать что это привлечет не самых лучших людей и ходить с охраной, чтоли. Ну и тут так же.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	206. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от XoRe (ok) on 12-Апр-14, 23:59
	> Ну если клобаксами, то, полагаю, можете чувствовать себя спокойно, изготовление копии   > сим-карты оценивается как раз примерно в килобакс. Да каво, дешевле можно) Но сейчас банки палят смену симкарты и не присылают смс на новую симку. После замены надо позвонить в банк/зайти в отделение. А там килобакса не хватит.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	207. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от XoRe (ok) on 13-Апр-14, 00:03
	>> Если когда-нибудь лишитесь 3700 евро со счета, поймете прелесть одноразовых паролей при >> работе с деньгами. > Странно, ворочаю килобаксами/килоевро по счетам уже 7 лет. Как-то пока все ок > (да, я очень внимательно изучаю все списки транзакций). Тю. Атаки уровня heartbleed тоже годами не было) Анализа уже совершенных транзакций мало. Если счет на физ лицо, можно очень быстро вывести деньги на только что созданный кошелек qiwi/yandex/etc, потом на другой, потом вывести на какую-нибудь не именную карточку, и снять.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	92. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от rob pike on 11-Апр-14, 00:05
	>А в почту тоже логиниться по карточке одноразовых кодов? Если такая карточка будет реализована в отдельном чипе того устройства, с которого вы это делаете, с надежной защитой по, например, сканированию сетчатки вашего глаза, всё это будет работать прозрачно для вас, не требуя каких-то особых телодвижений и в то же время поддерживаться сервером - то почему бы и нет.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	109. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 02:16
	> почему бы и нет. Сканирование? Сетчатки глаза? Чипом с проприетарной фирмварой? Не-не-не, Дэвид Блейн, засуньте ваши зонды себе. А я такой системой пользоваться вообще не буду - целиком перейду на какой-нибудь биткоин и полностью возьму ответственность за их кражу у меня на самого себя.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	115. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от rob pike on 11-Апр-14, 02:36
	> Сканирование? Сетчатки глаза? Чипом с проприетарной фирмварой? Не-не-не, Дэвид Блейн, > засуньте ваши зонды себе. А я такой системой пользоваться вообще не > буду Как тонка эта грань между паранойей и шизофренией. Вы в чипе CCD-камеры не пробовали зонды искать? А в LM317? > целиком перейду на какой-нибудь биткоин и полностью возьму ответственность > за их кражу у меня на самого себя. Непонятно что здесь меняет конечная цель аутентификации (биткойн, e-mail, пароль к сейфу с почтовыми голубями), если мы говорим о способах аутентификации. А по большому счету ответственность и так на вас. Вы попробуйте как-нибудь на досуге оспорить транзакцию, проведенную вами через интернет-банкинг в российском банке, на практике. Узнаете много интересного.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	118. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 03:10
	> Как тонка эта грань между паранойей и шизофренией. > Вы в чипе CCD-камеры не пробовали зонды искать? А в LM317? Маленький кусочек кремния может нынче содержать много вентилей. И реализовывать довольно сложную логику. Совсем не факт что работающую в мою пользу. Если что - я как раз отлично понимаю как работают микропроцессорные системы. Упомянутый вами девайс явно нуждается в логике которая будет фирмварой делаться, не говоря о том что несанкционированный доступ к такому девайсу позволит кому-то умыкнуть мою уникальную биометрию, чего мне совсем не хочется. И именно поэтому существуют некоторые границы того что я позволю микропроцессорным системам, а что нет. В отличие от большинства других людей я имею наглость использовать их как помощников, а не как электронный ошейник и троянскую конягу. > Непонятно что здесь меняет конечная цель аутентификации (биткойн, e-mail, пароль к > сейфу с почтовыми голубями), если мы говорим о способах аутентификации. Мне не придется мудохаться с всякими мегазондами претендующими на мою биометрию, несекурными протоколами, клиентами на всяком жаба-деpьме и прочими отходами мозговой деятельности. Оно не сольет логи в налоговую. И не заморозит счета при введении санкций. А где именно будут храниться фантики-циферки - мне если честно все-равно. Они один фиг абстракция. И так и эдак, в любой инкарнации. Биткоины использовать достаточно комфортно. И как их защищать с хорошим уровнем безопасности я более-менее понимаю. И не надо никаких почтовых голубей и прочих бумажек с одноразовыми паролями. Хватит оффлайнового кошелька, например. Отключенный оффлайн компьютер еще ни 1 хакер ломать не научился :) > А по большому счету ответственность и так на вас. Вы попробуйте как-нибудь > на досуге оспорить транзакцию, проведенную вами через интернет-банкинг > в российском банке, на практике. Узнаете много интересного. Поэтому я на самом деле достаточно компетентно и осторожно пользуюсь онлайн оплатой, оценивая риски и лимитируя возможный урон. То-есть для всяких покупок и прочего я вообще visa virtual использую, там можно и назваться Mr. Cardholder'ом, и денег - только впритык на покупку, etc. Спирать нечего будет :)
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	124. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от bugmenot (ok) on 11-Апр-14, 05:06
	Вы таки не поверите, но... http://www.opennet.dev/opennews/art.shtml?num=38583 http://www.pvsm.ru/radiosvyaz/55388/print/
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	135. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 10:32
	Это вообще к чему? Ну TCP/IP. Ну по побочному каналу. И что?
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	161. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от bugmenot (ok) on 11-Апр-14, 17:43
	К тому, что машина, не имеющая доступ к сети, но стоящая в одном помещении с машиной, такой доступ имеющей - потенциально все равно уязвима. Поэтому "отправить машину в оффлайн" это не панацея, увы, в современном мире.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	175. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 20:59
	> потенциально все равно уязвима. Потенциально, вам завтра на голову может упасть метеорит. Ничему не противоречит. Ну вот вероятность этого - примерно такая же как машина с чистой операционкой станет обмениваться по воздуху данными с соседями через микрофон. И, кстати, у моего десктопа например чисто физически нет микрофона. Очень интересно, придет агент АНБ и с раздосадованной миной подарит мне микрофон, чтобы я его подключил? Или чего?
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	177. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от iZEN (ok) on 11-Апр-14, 21:17
	>> потенциально все равно уязвима. > Потенциально, вам завтра на голову может упасть метеорит. Ничему не противоречит. Ну > вот вероятность этого - примерно такая же как машина с чистой > операционкой станет обмениваться по воздуху данными с соседями через микрофон. И, > кстати, у моего десктопа например чисто физически нет микрофона. Очень интересно, > придет агент АНБ и с раздосадованной миной подарит мне микрофон, чтобы > я его подключил? Или чего? У ноутбуков есть микрофоны. И они практически всегда включены.
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

	180. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 22:31
	> У ноутбуков есть микрофоны. И они практически всегда включены. Ну а вот у моего десктопа микрофона нет. Если ты думал что меня интересует _твоя_ безопасность - зря, прежде всего меня интересует защита _моих_ компьютеров от внешних посягательств. А ты в этой схеме - "как получится".
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

	191. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 12-Апр-14, 00:08
	Компьютеры в оффлайне, а сотовый наверняка с андроидом. И наверняка подключали его к компьютеру по usb (чтоб зарядить, например).. Лучше б подискутировали на тему, как можно передавать данные с Андроида, если в нём выключен интернет вообще. И как с помощью одной симки можно получить полный контроль над телефоном.
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	196. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 12-Апр-14, 08:29
	это чаще использется для сопоставления данных по мобильным устройствам и ноутам/настольным. то есть, для связывания воедино и идентификации (и отслеживания его перемещения)пользователя, более надежной, нежели для пенетрации и/или коммуникации с зондами, в АНБ, ЦРУ и ко.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

	215. "Heartbeat-уязвимости в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от iZEN (ok) on 16-Апр-14, 18:50
	>>а также многие банки и финансовые сервисы > А как ругали карточки одноразовых кодов ВТБ-шные, а. > Как же, каменный век, Java, сертификаты, прогресс, СМС. Алексей Шипилёв — Прагматика Java Memory Model: http://www.youtube.com/watch?v=iB2N8aqwtxc
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–12 +/–
Сообщение от Аноним (??) on 10-Апр-14, 13:46
Столько паники из-за капли в океане. Про спецслужбы - вообще смешно. Они и без того обязаны следить за разработкой таких продуктов и проводить аудит всех патчей к ним. Думаю, они о ней знали (и эксплуатировали) уже через месяц - два после её появления.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+8 +/–
	Сообщение от Нанобот (ok) on 10-Апр-14, 14:55
	>Думаю, они о ней знали (и эксплуатировали) уже через месяц - два после её появления зря ты недооцениваешь спецслужбы... об уязвимости они знали (и эксплуатировали) за месяц-два то её появления
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	20. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+4 +/–
	Сообщение от rob pike on 10-Апр-14, 15:17
	За десятки лет до появления OpenSSL спецслужбы уже написали инструментарий для эксплуатации её будущих уязвимостей. Срочно в номер.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	38. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от EuPhobos (ok) on 10-Апр-14, 17:24
	<irony> Были особые люди, которые решили создать спецслужбы для того, что бы они спроектировали и написали сам OpenSSL </irony>
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	50. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 19:30
	> За десятки лет до появления OpenSSL спецслужбы уже написали инструментарий для эксплуатации В каком-то роде. SSL и TLS наархитектили так, что секурно ими пользоваться почти невозможно. А навороченная либа неизбежно содержит 100500 багов.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	85. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от rob pike on 10-Апр-14, 23:38
	>наархитектили так, что секурно ими пользоваться почти невозможно И это вы тоже склонны приписать страшным спецслужбам?
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	156. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Аноним (??) on 11-Апр-14, 14:09
	> И это вы тоже склонны приписать страшным спецслужбам? Учитывая как NIST-у протолкали несекурный ГПСЧ, не удивлюсь если и протокол старались сделать так, чтобы секурно и без лажи его фиг с два получилось реализовать.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	98. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 00:24
	Сказано словно можно создать (и уже создано) что-то более простое и секьюрное.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	102. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от rob pike on 11-Апр-14, 01:33
	Это вы шутите так или действительно видели человека, утверждающего что чего-то более простого и секьюрного чем OpenSSL создать невозможно, и он над вами не глумился в этом момент?
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	110. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 02:18
	> Сказано словно можно создать (и уже создано) что-то более простое и секьюрное. Такого человека звали D.J. Berstein. И он таки сделал это - либу NaCl. У нее простое логичное апи, даже дуболому негде облажаться. А еще она может шифровать даже отдельные пакеты, не в пример меньше кластрефака чем в SSL.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	46. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 19:15
	Всё может быть. Только тогда это спецслужбы какой-то одной страны... с хорошим мозговым центром.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

3. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
Сообщение от iZEN (ok) on 10-Апр-14, 14:07
Да всё протроянено на высшем уровне. Вы как вчера родились. Как можно доверять секретную и конфиденциальную информацию иностранной операционной системе, которая подключена к их же сети?!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	54. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+2 +/–
	Сообщение от Аноним (??) on 10-Апр-14, 19:47
	Это ты сам у себя спрашиваешь? ;)
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	130. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+2 +/–
	Сообщение от Andrey Mitrofanov on 11-Апр-14, 09:44
	> Это ты сам у себя спрашиваешь? ;) У голосов в голове. И они отвеча-а-ают...
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	79. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от XoRe (ok) on 10-Апр-14, 22:32
	> Да всё протроянено на высшем уровне. Вы как вчера родились. > Как можно доверять секретную и конфиденциальную информацию иностранной операционной системе, > которая подключена к их же сети?! Как вы можете пользоваться буржуйским браузером, который запущен во вражеской ОС, работающей на ПК, собранным потенциальным противником?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	82. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–2 +/–
	Сообщение от iZEN (ok) on 10-Апр-14, 22:47
	>> Да всё протроянено на высшем уровне. Вы как вчера родились. >> Как можно доверять секретную и конфиденциальную информацию иностранной операционной системе, >> которая подключена к их же сети?! > Как вы можете пользоваться буржуйским браузером, который запущен во вражеской ОС, работающей на ПК, собранным потенциальным противником? Всё просто: все заинтересованные в обладании конфиденциальной информации юридические и физические лица действуют в правовом поле и подчиняются институтам права. Не будь этого, SSL/TLS ничего бы не стоило без сквозного контроля на каждом уровне представления информации. Другими словами, в беспределе нужно было бы каждой группировке/человеку разрабатывать собственное железо и ПО, как-то согласовывать протоколы обмена информацией с другими такими же лицами. При этом собеседники должны принимать ряд базовых вещей от простейших рефлексов до космических технологий, что невозможно в принципе в обществе, где никакие законы (кроме физической силы) не действуют. ;) В АНБ могут в любой момент списать некую сумму с любой пластиковой карточки любого гражданина их или не их страны, но не делают этого. Вопрос: почему? Думаю, понятно объяснил.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	86. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 23:41
	> карточки любого гражданина их или не их страны, но не делают > этого. Вопрос: почему? Ну это еще вопрос. Вон нашим чиновникам после санкций гопстопнули карточки. Впрочем, там же и ответ почему: потому что это вызывает нехилый бугурт у клиентуры. Вот местные чиновники уже например всерьез взялись за национальную платежную систему. Которая оттянет на себя часть оборота бабла. А это означает что виза и мастеркард недополучат баблишка...
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	153. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от user (??) on 11-Апр-14, 14:04
	Насчет гопстопа. У нас на работе несколько человек получали з/п на карточки Собин-банка. Картой раплатиться они не могли, да, но снять с нее деньги в отделении банка - без проблем, ни одной копейки не потерялось.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	155. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 14:06
	> Картой раплатиться они не могли, да, но снять с нее деньги > в отделении банка - без проблем, ни одной копейки не потерялось. И зачем нужна карточка, которой можно пользоваться только в отделении какого-то банка? Мне тогда проще получать сразу наликом - его в любом магазине принимают, минус время на посещение банка.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	159. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от user (??) on 11-Апр-14, 16:36
	>> Картой раплатиться они не могли, да, но снять с нее деньги >> в отделении банка - без проблем, ни одной копейки не потерялось. > И зачем нужна карточка, которой можно пользоваться только в отделении какого-то банка? > Мне тогда проще получать сразу наликом - его в любом магазине > принимают, минус время на посещение банка. Получайте, разрешаю
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	174. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 20:55
	> Получайте, разрешаю Ну а вы оставьте такие карточки себе, для меня они ничего кроме дополнительного геморроя не дают.
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	189. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от user (??) on 11-Апр-14, 23:16
	Так уж и быть, можете не брать такие карточки.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	200. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от t28 on 12-Апр-14, 12:00
	> в беспределе нужно было бы каждой группировке/человеку разрабатывать > собственное железо и ПО, как-то согласовывать протоколы обмена информацией > с другими такими же лицами. Все эти механизмы, интерфейсы и протоколы были учтены и разработаны в CCITT при ООН ещё в 70-е—80-е годы. Стандарты открыты — бери и пользуйся. Только в этих ваших интернетах решили делать всё по-своему. В принципе, это очень хорошо, если бы также параллельно развивались ITU-T-шные концепции. Однако из-за фактического отсутствия альтернативы паре IEEE + The Internet имеем что имеем. Причём пропихнуть на внешний рынок что-то прогрессивное и хорошее, но несовместимое со стандартами IEEE сейчас просто невозможно. А в отличие от ITU, IEEE — частная американская конторка, куда вас могут и не принять по каким-нибудь идеологическим причинам.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

4. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
Сообщение от Андрей (??) on 10-Апр-14, 14:20
А в роутерах на WRT прошивке или в серверных IMPI интерфейсах эта библиотека случайно не используется?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от Sabakwaka (ok) on 10-Апр-14, 14:44
	Совершенно случайно нет. Уязвимостью чревата сама идея TLS Heartbeat. На уровне замысла. И мы еще услышим.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	27. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от Аноним (??) on 10-Апр-14, 15:40
	Расскажите.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	31. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Sabakwaka (ok) on 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» после трех часов простоя окошка с данными кредитки, типа. Типа, страшно удобно. Данные формы можно держать, типа, восемь суток и не забивать по новой номер кредитки, если соединение оторвется. Как без этого жили, да.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	60. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 20:41
	Хотя идея heartbeat довольно дурная сама по себе, сабж тут не виноват. В сабже довольно крутой баг с утеканием памяти в сеть. Это не было задумано. Это просто лютый баг в либе. Одной конкретной либе.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	125. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от balda on 11-Апр-14, 06:26
	В сабже довольно крутой баг с утеканием памяти в сеть. Это не было задумано. Это просто лютый баг в либе. Одной конкретной либе. ...Одной конкретной либе. ...Одной конкретной либе. ...Одной конкретной либе. ...Одной конкретной либе. ...Одной конкретной либе. ...Одной конкретной либе. и там до посинения. Может станет правдой )))
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	136. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 10:34
	> и там до посинения. Может станет правдой ))) В других либах именно этого бага - нет. Зато может быть куча иных, не менее веселых. Навороченному протоколу - куча багов, все честно. Впрочем, вам с вашим ником простительно нести чушь.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	193. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 12-Апр-14, 04:56
	да не, автор коммента - прав. реально убогая идея для решения несуществующей проблемы. та-же хрень с курисами в браузерах для аутентификации, благодаря чем - мы до сих пор не имеем нормальной авторизации в веб-е.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	162. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Тампарам on 11-Апр-14, 17:50
	Для реализации heartbeat достаточно было бы определить пакеты для запроса и ответа. Они же там наворотили зачем-то "отправку запрошенного количества байтов". Ну и программер явно был в доле, потому что не специально отправить по запросу произвольное количество байт - очень сложно.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	12. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от pavlinux (ok) on 10-Апр-14, 14:49
	На OpenWRT какой-то свой шайтан-ssl-сервер писанный на LUA.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	24. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от rob pike on 10-Апр-14, 15:36
	Сервер-то свой, а суть всё та же. http://luci.subsignal.org/trac/browser/luci/trunk/libs/nixio...
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	61. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 20:43
	> На OpenWRT какой-то свой шайтан-ssl-сервер писанный на LUA. На LUA там написаны скрипты которые морду рисуют. Сервер там самопальный, uhttpd, но писан он таки на сях. А шифрование он таки из OpenSSL вроде как использует, так что если некто вывесил его в WAN или публично доступный LAN - ахтунг, ахтунг, ахтунг.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	29. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Онаним on 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 рассказать )
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	30. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от mickvav on 10-Апр-14, 16:19
	У меня единственное место, где живет IPMI настолько древнее, что 1.0 openssl еще не написали тогда. И в инет не смотрит :)
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	62. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от Аноним (??) on 10-Апр-14, 20:44
	> Да и gnutls-utils - 2.8.6-2 там есть. А при тем тут gnutls? В нем какие-то баги есть? В openssl баг специфичный для этой либы.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	94. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от rob pike on 11-Апр-14, 00:07
	> А при тем тут gnutls? В нем какие-то баги есть? "Уязвимость оценивается как очень серьёзная и подрывающая доверие к проекту. Ховард Чу (Howard Chu), главный архитектор проекта OpenLDAP, ещё в 2008 году выступал с рекомендацией прекращения использования GnuTLS в связи с несоблюдением элементарных правил безопасности в кодовой базе GnuTLS, в частности, повсеместном использовании функций strlen и strcat. По мнению Ховарда, исправить ситуацию может только полный пересмотр API GnuTLS" http://www.opennet.dev/opennews/art.shtml?num=39239
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	111. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 02:22
	> "Уязвимость оценивается как очень серьёзная и подрывающая доверие к проекту. А, про это я уже забыл. Ну а что, нагородили меганавороченные протоколы с кучей фич - получите кучу багов в их реализациях. Вроде логично. Хорошие вещи должны быть простыми. Теперь вы понимаете почему мне нравится NaCl. Очень прикольно сделанный диффи-хеллман на эллиптических кривых с неплохой подборкой алгоритмов. И апи которым может пользоваться даже простой смертный, а не только супергуру.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	116. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от rob pike on 11-Апр-14, 02:40
	Осталось ответить на вопрос почему им никто не пользуется.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	119. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 03:15
	> Осталось ответить на вопрос почему им никто не пользуется. Появился относительно недавно. И, кстати, кто сказал что им не пользуются? В последнее время NaCl/libsodium(более портабельный вариант) использует довольно много софта. Откуда я про них и узнал, собственно.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	163. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от Тампарам on 11-Апр-14, 17:51
	>> "Уязвимость оценивается как очень серьёзная и подрывающая доверие к проекту. > А, про это я уже забыл. Ну а что, нагородили меганавороченные протоколы > с кучей фич - получите кучу багов в их реализациях. Вроде > логично. Хорошие вещи должны быть простыми. Теперь вы понимаете почему мне > нравится NaCl. Очень прикольно сделанный диффи-хеллман на эллиптических кривых с неплохой > подборкой алгоритмов. И апи которым может пользоваться даже простой смертный, а > не только супергуру. Эллептические кривые - прямиком из лабораторий АНБ. Хрен знает что они там придумали.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	173. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Аноним (??) on 11-Апр-14, 20:51
	> Эллептические У... я так смотрю, вы мегамозг. Только не спрашивайте как я это узнал :). > кривые - прямиком из лабораторий АНБ. Вы переоцениваете АНБ. Эллиптические кривые, FYI, придумали математики. А АНБ всего лишь вовремя подсуетилось, чтобы NIST подсунуть бажную реализацию ГПСЧ на их основе, не более. Вот кстати выбору кривых от NIST я бы доверять не стал. Но какой-нибудь Берштейн, его группа любителей криптографии и выбранные ими кривые - к NIST и АНБ относятся чуть менее чем никак. Ну нет у АНБ эксклюзивных прав на довольно базовые конструкции из области математики. > Хрен знает что они там придумали. С таким уровнем знаний лучше молчать в тряпочку и не высовываться. За умного сойдешь. А когда вы занимаетесь тем что распостраняете ламерский буллшит, абсолютно не разбираясь в вопросе и даже не зная как пишется слово "эллипс" - это пржде всего выставляет лично вас некомпетентным болваном, который, тем не менее, имеет мнение. То-есть, ламером.
	Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

	195. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Тампарам on 12-Апр-14, 08:12
	Берштейну или какому-нибудь его помощнику АНБ просто заплатило немножко денег, чтобы направить его поиск в нужном направлении. Никто ж не заметит и все доверяют.
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	197. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 12-Апр-14, 08:33
	> Берштейну или какому-нибудь его помощнику АНБ просто заплатило немножко денег, чтобы направить > его поиск в нужном направлении. Никто ж не заметит и все > доверяют. про скандал с обоим закладками от АНБ, проплаченными RDA за миллионы баксов - читали ? там в обоих случаях - так нефигово, в тысячи раз, была ослаблена реализация =) мораль: имея физическую возможность давления на разработчика(не суть частное лицо или компанию, комьюнити) и/или mitm-интерференции с их работой - это не ахти какой сложности задача для Люьбой спецслужбы )
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	202. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Sabakwaka (ok) on 12-Апр-14, 13:26
	> сложности задача для Люьбой спецслужбы ) ВСЕ «системы шифрования» уязвимы ПРИНЦИПИАЛЬНО. На уровне ДИЗАЙНА, на уровне МАТ. МОДЕЛИ, положенной в их основу. «Бекдоры», тривиальные состояния системы, существуют в них ПРИНЦИПИАЛЬНО. Ради того, чтобы банкомат хавал 4-х значный PIN. С некоторой степенью надежности. Или носи с собой бумажку с набором одноразовых 108-буквенных паролей, или PIN, но с возможностью обнаружения и утечки эксплойта. При этом, самый тупой «шифр» прошлого ТЫСЯЧЕЛЕТИЯ — НИКАК И НИЧЕМ НЕ ВСКРЫВАЕТСЯ. Так что хорош пенить ситро.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	204. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от rob pike on 12-Апр-14, 22:26
	>бумажку с набором одноразовых Вот видите, совсем не все "системы шифрования» уязвимы ПРИНЦИПИАЛЬНО" >108-буквенных паролей Пяти-шести-цифровых вполне достаточно IRL
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	201. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от Sabakwaka (ok) on 12-Апр-14, 13:17
	Эллиптические кривые - прямиком из оснований математики, вообще-то.
	Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

	154. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 14:05
	> А в роутерах на WRT прошивке Там по дефолту ничего SSLного в сеть не торчит вроде. Но если торчит - да, заапдейтить надо.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
Сообщение от MPEG LA (ok) on 10-Апр-14, 14:25
gmail, fb и vk попали под раздачу?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	63. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 20:47
	> gmail, fb и vk попали под раздачу? Вполне вероятно. Более того - баг вывешивает память процесса в сеть, так что даже приблизительно оценить масштабы пи...ца будет довольно сложно.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	131. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 11-Апр-14, 09:47
	> что даже приблизительно оценить масштабы пи...ца будет довольно сложно. Шнайер облегчает наши сомнения: 11 из 10 баллов.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

6. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
Сообщение от Sw00p aka Jerom on 10-Апр-14, 14:36
баг специально внесли из-за коммерческой выгоды, все попёрли менять ssl сертификаты - круто
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Sabakwaka (ok) on 10-Апр-14, 14:44
	> баг специально внесли из-за коммерческой выгоды, все попёрли менять ssl сертификаты - > круто Да ну?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	11. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–10 +/–
	Сообщение от Нанобот (ok) on 10-Апр-14, 14:46
	>все попёрли менять ssl сертификаты попёрли менять сертификаты только истерички, паникёры и лохи, которые начитались страшилок в интернетах и теперь жутко бояцца. на таких по жизни наживаются предприимчивые дельцы, баг в openssl - лишь очередной способ из подоить, не первый и не последний
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	22. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от pavlinux (ok) on 10-Апр-14, 15:25
	Для "истеричек, паникёров и лохов..." ниже показал скриншот, с реально рабочего сервера, с довольно полезной инфой для конкурентов.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	65. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 20:48
	> попёрли менять сертификаты только истерички, паникёры и лохи, которые ...которые не хотят сливать свои пароли и приватные ключи всему миру. Только вот они то как раз не лохи. Лохи - те кто этого не сделал. По поводу чего в будущем их будет ждать мнооооого интересных поимений. > предприимчивые дельцы, баг в openssl - лишь очередной способ из подоить, > не первый и не последний То что PKI лохоразвод - вы, конечно, правы, но в данном случае пи...ц таки имеет место быть.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	16. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от serverX (??) on 10-Апр-14, 14:54
	я бесплатно перевыпустил свои сертификаты. причем сроки сертификатов остались старыми.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	194. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Тампарам on 12-Апр-14, 08:10
	Старые-то заэкспайрить не забыли? :)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

7. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
Сообщение от pavlinux (ok) on 10-Апр-14, 14:36
Redmine тоже дырявый. http://i59.fastpic.ru/big/2014/0410/2e/9fd0122735fb7d475abc7...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от Xaionaro (ok) on 10-Апр-14, 14:57
	Как данный скриншот указывает на дырявость Redmine?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	19. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от pavlinux (ok) on 10-Апр-14, 15:01
	> Как данный скриншот указывает на дырявость Redmine? Cookie: _redmine_session и далее по тексту ...assword=v_pupkin&login=Login+vasya Для тех кто не в курсе: Redmine может работать как в режиме CGI, или как самостоятельный сервер.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	80. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от XoRe (ok) on 10-Апр-14, 22:35
	> Для тех кто не в курсе: Redmine может работать как в режиме > CGI, или как самостоятельный сервер. Но это не значит, что его надо так запускать. Вообще, веб сервер на Ruby - не самый лучший фронтенд :) Лучше спрячьте за nginx, мой вам совет. nginx обновить может быть куда проще.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	128. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Xaionaro (ok) on 11-Апр-14, 08:25
	>> Как данный скриншот указывает на дырявость Redmine? > Cookie: _redmine_session и далее по тексту ...assword=v_pupkin&login=Login+vasya > Для тех кто не в курсе: Redmine может работать как в режиме > CGI, или как самостоятельный сервер. А причём тут "дырявость" redmine-е, если данные получены через уязвимость libssl? (или может вообще обычным tcpdump - не знаю как были получены данные не screenshot-е).
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	138. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 10:37
	> А причём тут "дырявость" redmine-е, При том что пароль в открытом виде фигачат, полагаясь на "защиту соединения", которая не очень то и защищает.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	178. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от Xaionaro (ok) on 11-Апр-14, 22:01
	>> А причём тут "дырявость" redmine-е, > При том что пароль в открытом виде фигачат, полагаясь на "защиту соединения", > которая не очень то и защищает. А другие Web ITS как работают?
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	181. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 22:34
	> А другие Web ITS как работают? Так же как и все остальное от веб хомячья, разумеется. Т.к. дыра на дыре и дырой погоняет.
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	192. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Xaionaro (ok) on 12-Апр-14, 00:19
	>> А другие Web ITS как работают? > Так же как и все остальное от веб хомячья, разумеется. Т.к. дыра > на дыре и дырой погоняет. Ну, получается, что >95% сайтов с поддержкой аутентификации (включая www.opennet.ru) - дырьё. Я согласен, что передавать plaintext пароли даже через SSL - моветон. Но "обычный пользователь" не способен освоить аутентификацию по сертификатам, а делать а-ля CHAP на базе JS - это изврат. А другие варианты не очень совместимы сквозь зоопарк браузеров. В любом случае, вне зависимости от того, насколько это соответствует правилам хорошего тона, данная особенность Redmine не является дырой. Это просто известная особенность современных web-ресурсов и известными методами защиты, и с известными проблемами этих методов.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	23. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+5 +/–
	Сообщение от anonymus on 10-Апр-14, 15:31
	А потом все удивлялись, откуда такой ажиотаж вокруг сноудена, все же знали, что следят. Видимо, без капитана сноудена наивные обыватели не способны представить во что выливаются те или иные технические проколы. А как только посмотрят презентацию с надписью "собрано 2 миллиарда ключей" - так сразу начнут вопить как резанные.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	41. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Аноним (??) on 10-Апр-14, 17:58
	мало того, некоторым и выступлений Сноудена недостаточно
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	66. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Аноним (??) on 10-Апр-14, 20:50
	> Redmine тоже дырявый. Ну что ты как маленький, скрипткидизы думали что мегалиба сделает им зашибись. Поэтому слали пароль открытым текстом, как есть. А теперь пора выкусить результаты.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

21. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
Сообщение от Аноним (??) on 10-Апр-14, 15:20
> но не предусматривающими возможность автоматического обновления прошивки. А Столман давно говорит, что надо делать.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	120. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 03:15
	> А Столман давно говорит, что надо делать. Ну дык. Использовать девайсы где исходники прошивки есть.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

26. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
Сообщение от Ansomgsom on 10-Апр-14, 15:40
Писали открытый ССЛь, скопипастили проприетарный код не глядя :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

32. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
Сообщение от Аноним (??) on 10-Апр-14, 16:32
причем наверняка АНБ :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	39. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от anonymous (??) on 10-Апр-14, 17:43
	> причем наверняка АНБ :) Как будто список спецслужб мира состоит из одного АНБ. Все они одним миром мазаны.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	42. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 18:00
	> Как будто список спецслужб мира состоит из одного АНБ. Все они одним > миром мазаны. может и не АНБ, но американская точно
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	48. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+4 +/–
	Сообщение от Аноним (??) on 10-Апр-14, 19:20
	>> Как будто список спецслужб мира состоит из одного АНБ. Все они одним >> миром мазаны. > может и не АНБ, но американская точно Вы про русские спецслужбы вообще слышали? Нет? А ведь они есть. А ведь это наши занимают первые места на всяких хакерски-программерских олимпиадах. Есть над чем задуматься, правда? ;)
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	74. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Аноним (??) on 10-Апр-14, 21:54
	> над чем задуматься, правда? ;) Да, наши занимают первые места в олимпиадах. А потом они работают в их интелах, фэйсбуках, гуглах и прочих. Потому что там нормально платят и с управлением компаниями порядок.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	198. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 12-Апр-14, 09:09
	ха, я был прав http://lenta.ru/news/2014/04/12/heartbleed/
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

33. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
Сообщение от Аноним (??) on 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: "
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	67. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+2 +/–
	Сообщение от Аноним (??) on 10-Апр-14, 20:51
	> "ScriptKiddy detected: " Действительно, detected: залоггил и забил. Ну а дропать пакет кто будет, Пушкин? :)
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	69. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 21:15
	...и вместо 40 00 может быть нечто другое...
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	73. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 21:53
	> ...и вместо 40 00 может быть нечто другое... Я знаю. Зато запись в логе понтовую - нарисовал. Вот как-то так скрипткидисы и детектируются :).
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	75. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 21:56
	> ...и вместо 40 00 может быть нечто другое... И детектировать как string... ну в общем, намного более нормальный рецепт написан в советах: http://www.opennet.dev/tips/2830_openssl_block_iptables_heart... Тут вам и логгинг, и удавка пакета, и, блин, ищется u32 а не string, что по идее заметно быстрее.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	150. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от pavlinux (ok) on 11-Апр-14, 12:30
	>> ...и вместо 40 00 может быть нечто другое... > И детектировать как string... ну в общем, намного более нормальный рецепт написан > в советах: http://www.opennet.dev/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
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

34. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+5 +/–
Сообщение от Аноним (??) on 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.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	35. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от pavlinux (ok) on 10-Апр-14, 16:40
	Ну чо, спасибо посанам из маздайсофта, спалили бэкдор!!! Дайте иcчо! :) А под Debian 6 и SLES нету? А то какбэ они не дырявые.   > Уязвимость раскрыта в день прекращения поддержки Windows XP и активно продвигается Google, Dropbox, Facebook уже бегут ставить на свои сервера Вантуз 8, ога.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	43. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от Аноним (??) on 10-Апр-14, 18:02
	всё может быть
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	55. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 19:54
	И шо они скажут? В Windows Next самое неуязвимое шифрование? :) Кто им поверит? Не, ну конечно, те кто и раньше безропотно заглатывали их "продукты" и дальше глотать будут. Таких и убеждать не надо.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	76. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от некто (ok) on 10-Апр-14, 22:03
	типа не переходите c XP на сторонние *nix-системы, там все плохо, вот например дыра в openssl. Но ведь стэк openssl используется и на винде и во многом входит/заимствован в составе инфраструктуры винды в части криптографии. Ибо как IE реализует https?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	81. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Волкот on 10-Апр-14, 22:36
	http://www.securitylab.ru/vulnerability/449697.php дыра во всех виндах с 2001 года. им и без openssl хорошо.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	126. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Адекват (ok) on 11-Апр-14, 08:15
	> криптографии. Ибо как IE реализует https? Оффтоп - а почему IE не может пройти авторизацию, если пароль передается в виде хеша md5 ? Просто тупо правильный пароль не подходит - во всех остальных браузерах все ок.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	139. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 10:40
	Возьми снифер да посмотри что там передается по факту. Может он digest авторизацию считать не умеет? Или что ты там используешь...
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

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

	121. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 03:17
	> а какое отношение имеет openssl к линуксу как таковому? А никакого. Чуть погодя юзеры виндов узнают сколько софта юзало статически влинкованную либу и по этому поводу бессовестно продалбывало их данные злонамеренным серверам.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	132. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Andrey Mitrofanov on 11-Апр-14, 09:51
	> либу и по этому поводу бессовестно продалбывало их данные злонамеренным серверам. Ну, за здоровье IIS! Не чокаясь.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	140. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 10:40
	> Ну, за здоровье IIS! Не чокаясь. Ага, здоровый зомбяк. Все время из могилы вылезает, зараза.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	142. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Andrey Mitrofanov on 11-Апр-14, 10:49
	>Все время из могилы вылезает, зараза. Спонсер-вурдалак-некромансер бдит и собирает opennet.ru/openforum/vsluhforumID3/81138.html#34 opennet.ru/openforum/vsluhforumID3/74800.html#285 жатву. [тёмный жнец]
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	160. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 17:31
	> Спонсер-вурдалак-некромансер бздит //fixed. > и собирает И апачует. > opennet.ru/openforum/vsluhforumID3/74800.html#285 жатву. Что-то нет там ничего, видимо потерли.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

36. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
Сообщение от некто (ok) on 10-Апр-14, 16:47
У них там в загашниках типа еще есть гостинцы?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

37. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
Сообщение от axe (??) on 10-Апр-14, 16:56
вангую появление новой библиотеки
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	40. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от anonymous (??) on 10-Апр-14, 17:44
	> вангую появление новой библиотеки Попроси вангователь у анонима сверху. NaCl уже есть.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	44. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–2 +/–
	Сообщение от pavlinux (ok) on 10-Апр-14, 18:21
	> ... NaCl уже есть. а PoCl и NeСl будут?
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	49. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Аноним (??) on 10-Апр-14, 19:23
	>> ... NaCl уже есть. > а PoCl и NeСl будут? Не, не так. KCl и Na(OH)2
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	52. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+8 +/–
	Сообщение от Michael Shigorin (ok) on 10-Апр-14, 19:37
	> Не, не так. KCl и Na(OH)2 Выделил оценку по неорганике, если что.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	93. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Аноним (??) on 11-Апр-14, 00:06
	Извиняюсь, перепутал валентность металлов. Если так напишу: Na(OH)2- Ион сойдёт за оправдание? :)
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	112. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Аноним (??) on 11-Апр-14, 02:24
	> Ион сойдёт за оправдание? :) А что за ион такой странный? NaOH диссоциирует на Na+ и OH-. А это что за хрень?
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	129. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 08:53
	Теоретически возможный в какой-либо момент времени. Разумеется, сразу распадётся, как образуется.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	133. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Andrey Mitrofanov on 11-Апр-14, 09:53
	> Теоретически возможный в какой-либо момент времени. Разумеется, сразу распадётся, как > образуется. полимеры Na[NN]OH[MM] тоже по броску кости могут образовываться!
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	58. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 20:38
	Если и будут, то будет PoCl на всех 3х, ибо NeCl
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	113. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 02:25
	> ибо NeCl Да, удачи вам заставить неон провзаимодействовать с хлором...
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	127. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Адекват (ok) on 11-Апр-14, 08:16
	>> ибо NeCl > Да, удачи вам заставить неон провзаимодействовать с хлором... При помощи кувалды и такой-то матери...
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	141. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 10:45
	> При помощи кувалды и такой-то матери... Сдается мне, тут даже термоядерная кувалда может спасовать.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	149. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от pavlinux (ok) on 11-Апр-14, 12:24
	>> При помощи кувалды и такой-то матери... > Сдается мне, тут даже термоядерная кувалда может спасовать. Вдуваешь в баллон 50% неона, 50% хлора, взбалтываешь! Опа!
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	151. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Michael Shigorin (ok) on 11-Апр-14, 12:49
	> Вдуваешь в баллон 50% неона, 50% хлора, взбалтываешь! Опа! Расслаивается и продолжает болтаться себе.  Неон вообще-то инертен.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	152. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от pavlinux (ok) on 11-Апр-14, 13:17
	>> Вдуваешь в баллон 50% неона, 50% хлора, взбалтываешь! Опа! > Расслаивается и продолжает болтаться себе. Надо было добавить, "Взболтать перед употреблением" >   Неон вообще-то инертен. Ну это его проблемы, взболтать никогда не помешает (к инициирующим ВВ не относится)
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	182. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 22:37
	> Надо было добавить, "Взболтать перед употреблением" Ну вот в сабже не добавили, видишь чего получилось?
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	45. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от некто (ok) on 10-Апр-14, 18:28
	> вангую появление новой библиотеки давно пора разнообразие, хотя на примере ffmpeg/libav особенного прогресса не наблюдается...
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	87. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от rob pike on 10-Апр-14, 23:42
	Да и ядро ОС неплохо бы, основанное не на идеях 50-летней давности. А множатся что-то лишь нескучные хипстерские обои. Странно, да?
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	99. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 00:25
	> Да и ядро ОС неплохо бы, основанное не на идеях 50-летней давности. А зачем чинить то что не сломано? А электродвигатели и трансформаторы работают уже пару столетий, с довольно небольшими усовершенствованиями.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	101. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от rob pike on 11-Апр-14, 01:31
	>> Да и ядро ОС неплохо бы, основанное не на идеях 50-летней давности. > А зачем чинить то что не сломано? Точно не сломано? Что ж тогда всё чинят и чинят, и всё костылями да костылями, один другого неприглядней. > А электродвигатели и трансформаторы работают уже пару столетий, с довольно небольшими усовершенствованиями. То-то у всех ваших гаджетов блоки питания линейные, с большими трансформаторами. Хотя постойте..
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	104. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 01:59
	> Точно не сломано? Что ж тогда всё чинят и чинят, и всё > костылями да костылями, один другого неприглядней. А это потому что симпатичные дизайны хорошо смотрятся как демонстрационная модель в кабинете физики, но для нормальной работы в реальном мире - приходится докостыливать по месту. Так что академически-симпатичные дизайны как-то все время в пролете оказываются. А все сколь-нибудь успешные операционки были гибридами или монолитами. С кучей костылей и "недостатков". Зато работали хорошо. Вон микроядра - как-то оказалось что ОС на их основе сделать сложнее, драйвера писать никто не хочет, работает тормознее. Так и осталось игрушкой академиков да системой для специальных применений. > То-то у всех ваших гаджетов блоки питания линейные, с большими трансформаторами. Хотя > постойте.. То-есть, подъем частоты преобразования не меняет на фундаментальном уровне принцип его работы. Это лишь позволяет сделать трансформатор меньше по размеру.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

51. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
Сообщение от Аноним (??) on 10-Апр-14, 19:34
Я всегда знал, что даже на Tor полностью надеяться нельзя.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	103. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–2 +/–
	Сообщение от anonymous (??) on 11-Апр-14, 01:49
	В области распространения германских языков Тору посвящён день недели — четверг (англ. thursday, нем. Donnerstag). по четвергам можно пользоваться
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	143. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 11:07
	> Я всегда знал, что даже на Tor полностью надеяться нельзя. В конструкции сети Tor есть минимум 2 серьезных упущения, вообще никак не связанных с SSL.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	210. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 13-Апр-14, 08:07
	учитывая кем и для чего был разработан Тор, ваша ремарка - может лишь улыбку, вызвать )
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

53. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
Сообщение от Аноним (??) on 10-Апр-14, 19:42
>Другой вопрос, случайно или нет подобная уязвимость появилась в OpenSSL. Это вопрос не "другой", это вопрос самый главный.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

56. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
Сообщение от lucentcode (ok) on 10-Апр-14, 20:23
Да, такого фейла ещё не было наверное в истории IT. А некоторые люди ещё и отказываются обновлять OpenSSL на своих серверах. Это было бы смешно, если не было бы так печально...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	64. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Oinari (ok) on 10-Апр-14, 20:47
	Debian oldstable спасает.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	72. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 21:51
	> Debian oldstable спасает. Совсем не включать компьютер - надежнее.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	172. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 20:26
	> люди ещё и отказываются обновлять OpenSSL на своих серверах. Не пользуйтесь такими серверами. Проипут они ваши данные и логины с паролями.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

57. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–2 +/–
Сообщение от iZEN (ok) on 10-Апр-14, 20:24
C/C++ всё погубил.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	59. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 20:40
	> C/C++ всё погубил. Но жабка мало чего годного из либ родила
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	68. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+2 +/–
	Сообщение от Аноним (??) on 10-Апр-14, 20:55
	> C/C++ всё погубил. Остальные облажались бы еще раньше, ибо GC и тому подобные - криптографии не друг и не товарищ: ключи из памяти требуется изничтожать предсказуемо, как только они перестали требоваться, затерев явным образом. А не "когда GC раздуплится" и "хрен его знает насколько он там почистит". На твоей жабе способов прострела себе пятки в криптографии в 100500 раз больше. И уж там дыр сроду было всех сортов и размеров. Их по 30 штук критикалов в каждом релизе давят. Просто все уже привыкли к тому что там постоянный п....ц и уже не обращают на него внимания.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

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

	71. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 10-Апр-14, 21:49
	> Java написана на C/C++, поэтому в ней полно дыр. Очевидно и логично. Логика жабиста: во всем виноваты ... нет, не программисты. Си и плюсы во всем виноваты, о как. Вот это я понимаю, ламерство. Впрочем, в openssl есть ламерство и на уровне чистейшей алгоритмики, вообще без привязки к сям и плюсам. Ну вот например, почему криптографическая либа, поюзав память, вообще не чистит ее после юзежа? Ах, авторы раздолбаи и не парятся? Ах, еще и malloc перехватили, чтобы система на могла поумничать. Замечательно. Правда такое по смыслу долбоклюйство можно повторить на любом ЯП, а экспонаты с GC еще и помогут наступить на грабли дюжиной неочевидных способов, прихранив ключи в памяти еще на полчасика, хотя об этом никто не просил. Ведь GC лучше знает когда ключ протух, правда?
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	77. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–2 +/–
	Сообщение от iZEN (ok) on 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 изучил, чтобы такую чепуху городить здесь?
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

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

	95. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+2 +/–
	Сообщение от Аноним (??) on 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 изучил, чтобы такую чепуху городить здесь? О, ты кажется начинаешь понимать суть проблемы. Чем сложнее и навороченнее рантайм - тем сложнее из него выжать тот уровень предсказуемости, который необходим для реализации надежной криптографии.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

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

	165. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 18:46
	> Ругаетесь вы клёво, но всё-таки выход за рамки массива -- это таки > то что хочется чтобы запрещал язык. По конкретно этому пункту - я даже согласен до некоторой степени. И сдается мне что проще это оформить как расширение си/си++ чем бодаться с мегасложным рантаймом, пытаясь из него предсказуемость нужную криптографам выжать. > Я понимаю что всегда можно обвинить в тyпизне разраба -- и так > оно и есть. Но умных разрабов не бывает (имхо). Не совсем так. Каждый должен заниматься своим делом. А если дворник поперся булки печь, получился какой-то трэш и хлебозавод несет адские убытки - человек занимался не своим делом, по поводу чего закономерно получился хреновый результат. Ну вот от тех кто лезет писать криптографическую либу ожидается некое понимание проблематики области и соответствюущее мышление и квалификация. Если этого не наблюдается - будет честно, если у него сольется репутация и он будет известен как БРАКОДЕЛ, продукцию которого использовать не стоит. Ну так вот, посмотрим на уязвимость. Пароли, говорите, отсылаются? Из памяти? Ок! А какого, собственно, пароли в памяти забыли? Коли она не занята и вообще? Ах, пароли и ключи никто не чистил, после того как они перестали быть нужны? Воооооо! В этом месте мы начинаем догадываться: начальный источник проблем - это оно, а то что такая память так или иначе может утекать - СЛЕДСТВИЕ более фундаментальной проблемы: какие-то удоды не чистят за собой память с чувствительными данными. Заметьте, блок памяти может не только улететь в сеть из-за бага либы. Какая-нибудь программа в другом месте может выделить себе блок памяти. И если никто расчисткой не заморачивался - там ВНЕЗАПНО окажутся эти ключи и пароли. Круто, правда? А то что это другой пользователь и другой процесс - нууу... никто же не чистил память! По изначальной идее, пароли и ключи живут в памяти абсолютно минимально необходимое время и как только не требуются - явно затираются. Это нагибает такие векторы атак. Если бы это было сделано - утечка памяти, конечно, неприятно, но не была бы фатальной. А вот в таком виде - тут только остается гадать: где еще оно выстрелит в следующий раз? В многозадачной многопользовательской системе процесс для начала живет не один. И результаты его жизнедеятельности могут в принципе оказаться доступны другим, если они не озаботились этим вопросом. > Так что до тех пор пока мы не идеальны, а проги наши не > верифаятся "математически" компьютером А тут нам Тюринг объяснил что нет в жизни счастья. Одна программа не может анализировать другую произвольную программу и выносить какой либо определенный вердикт. FAIL. > не говорить что без плохого менеджмента и руководства мы написали бы > хороший софт. И признавать недостатки языка вместо оправдывания оного. Хороший софт начинается с грамотного программиста. Если некто хочет что-то делать с криптографией, он для начала должен начать мыслить как криптограф. Вокруг враги. Враги хотят спереть наши данные. И придется параноидально защищать от них каждый бит. Тогда враг [может быть] не пройдет. А если оно как в openssl - там еще много интересных багов бомбанет, совершенно независимо от того, будет ли проверка диапазона массива. Замести мусор под ковер - это не фикс. Ведь намного более фундаментальная проблема "куча ценных данных болтается в памяти неопределенный срок и их никто не чистит" - никуда от проверки границ не делась. А если "мы, тут, типа, соединение защищаем", да еще с API как у OpenSSL, которое сколь-нибудь секурно использовать может только тот кто в криптографии уже неплохо разбирается - это примерно как дедушка-сторож, у которого из вооружения только клюка, против банды из десяти головорезов.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	170. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от vn971 (ok) on 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]
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	183. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 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. Да я тоже простейший тасксвичер напишу без багов. А кому он будет нужен? В общем то единственная проблема с микроядрами: там просто сложные вещи перепихнуты на чуть другие головы, поэтому те кто писал "тасксвичер" могут встать в позу Д'Артаньяна и гордо заявить что у них багов нет. Это вполне может быть правдой, в силу того что само микроядро мелкое. К сожалению это означает лишь то что сложные моменты перепихнули в иные компоненты. И, заметим, про их верификацию все технично молчат в тряпочку. Поэтому секурным оно будет в тепличных условиях, у академиков в лаборатории, где одно лысое ядро которое ничего не делает. А сделай из этого десктопник, с навороченными драйверами и софтом - и будет все как обычно.
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	185. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от vn971 (ok) on 11-Апр-14, 23:03
	Ээээ, я просто объяснял что значит компьютерно-верифицированная программа.. И, кстати, как и в математике -- доказательства легко можно модифицировать в случае небольших изменений требований в задаче. То есть, версия никуда гвоздями не прибита. Модифицируешь код, модифицируешь доказательство кода -- всё ок. На счёт времени верифицирования -- вы не правы, оно очень мало. Все возможные состояния никто не рассматривает, так же как не рассматривают все возможные состояния неупорядоченного массива когда доказывают корректность bubble sort (мелом на доске).
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	83. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–2 +/–
	Сообщение от Anonym2 on 10-Апр-14, 22:53
	> Ну вот например, почему криптографическая либа, > поюзав память, вообще не чистит ее после юзежа? Ах, авторы раздолбаи > и не парятся? Ах, еще и malloc перехватили, чтобы система на > могла поумничать. А зачем её чистить? Вся программа должна быть достаточно надёжной, в составе которой работает эта библиотека. И которой программе как-то все секретные пароли даются и она ими управляет... :-)
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	96. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Аноним (??) on 11-Апр-14, 00:21
	> А зачем её чистить? Чтобы врагам не досталось! Ну там другим процессам, другим юзерам, etc. Не айс будет если какой-то хмырь выделит себе блок памяти, а там бац - привкей от банка с миллионом лежит! Потому что его никто оттуда не снес, вы прикиньте? > Вся программа должна быть достаточно надёжной, И в рамках криптографии надежность кроме всего прочего подразумевает защиту ключей от утечки. Блокирование памяти от доступа другими процессами. Запрет выгрузки в своп. Затирание нулями как только ключ более не требуется, etc. Параноидальное отношение к самым базовым операциям, типа операций сравнения. Это отдельная тонкая механика. И ее проще всего реализовать на простом и предсказуемом рантайме. Потому что допинать сложный навороченный рантайм до кондиции когда его фичи не будут вызывать внезапный прострел пяток в самых непредсказуемых ситуациях - сложно, да.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	100. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от rob pike on 11-Апр-14, 01:23
	>допинать сложный навороченный рантайм до кондиции когда его фичи не будут вызывать внезапный прострел пяток в самых непредсказуемых ситуациях - сложно, да Но заказчики хотят Java, так что будут допинывать. Вот у low-latency лагеря те же проблемы - http://mechanical-sympathy.blogspot.ru/2012/03/fun-with-my-c...
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	105. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от rob pike on 11-Апр-14, 02:04
	А в real-time мире так и к С++ больше вопросов чем ответов. http://www.embedded.com/design/programming-languages-and-too...
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	107. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 02:10
	> А в real-time мире так и к С++ больше вопросов чем ответов. Меньше чем к яве. А так то да - чем проще некая конструкция, тем она предсказуемее. А в криптографии это далеко не последнее дело. Вон scrypt'у например припомнили что там время работы зависит от cache hit/cache miss. Вроде пустячок, а тайминг атаки потенциально позволяет. Так появились catena, sponge и т.п, время работы которых - более-менее постоянное, независимо от характера данных.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	106. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 02:04
	> Но заказчики хотят Java, так что будут допинывать. Ну, если заказчик просит веревку и мыло - надо ему их выдать. А если он в них повесится - это уже на его совести. > Вот у low-latency лагеря те же проблемы Насколько я помню, MS со своим дотнетом вылетел с LSE в том числе и за неспособность обеспечить обещанные времена задержек. Как зашел вопрос о бабле - они и на си++ софт переписали, и линух поставили. Потому что бабло побеждает зло.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	122. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Anonym2 on 11-Апр-14, 04:07
	>> А зачем её чистить? > Чтобы врагам не досталось! Ну там другим процессам, другим юзерам, etc. Не > айс будет если какой-то хмырь выделит себе блок памяти, а там > бац - привкей от банка с миллионом лежит! Потому что его > никто оттуда не снес, вы прикиньте? >> Вся программа должна быть достаточно надёжной, > И в рамках криптографии надежность кроме всего прочего подразумевает защиту ключей от > утечки. Блокирование памяти от доступа другими процессами. Запрет выгрузки в своп. > Затирание нулями как только ключ более не требуется, etc. Нельзя сказать, что UNIX не подразумевает... Многие не верят, что кое у кого все программы на отдельных машинах. (при чём виртуальных) :-) Но вообще OPENSSL_cleanse есть. И иногда используется... Затирает даже не нулями.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	166. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 19:08
	> Нельзя сказать, что UNIX не подразумевает... Сами по себе многозадачки общего назначения не страдают в общем случае такой паранойей, т.к. это сильно тормозило бы работу программ. > Многие не верят, что кое у кого все программы на отдельных машинах. > (при чём виртуальных) :-) Я верю, концепты типа "1 контейнер = 1 сервис" мне по вкусу. Но это никак не адресует тот факт, что если освобожденный блок памяти явно не протерт ровно в тот момент когда ключ/пароль/etc перестали требоваться - потенциально кто-то другой может его получить. На уровне физики процесса. Оно чисто физически лежит в ячейках RAM, покуда кто-то не запишет туда что-нибудь другое. По этой причине те кто не полный дятел в криптографии - сносят чувствительные данные из памяти и протирают этот регион бесполезными данными сразу как только ценные данные перестали быть нужны.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	167. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Anonym2 on 11-Апр-14, 20:00
	> Сами по себе многозадачки общего назначения не страдают в общем случае такой > паранойей, т.к. это сильно тормозило бы работу программ. ...сказал Микрософт (вслед за кое кем вероятно) и выпустил DOS NIX. >:-)
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	169. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 20:15
	> выпустил DOS NIX. Нечто такое называлось DJGPP и было GCC для DOS и даже какие-то либы. Правда я не в курсе насколько там POSIX и стандартные вызовы всяких libc были реализованы :).
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	123. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Anonym2 on 11-Апр-14, 04:36
	> Не > айс будет если какой-то хмырь выделит себе блок памяти, а там > бац - привкей от банка с миллионом лежит! Потому что его > никто оттуда не снес, вы прикиньте? Много уже было украдено до нас...
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	88. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от rob pike on 10-Апр-14, 23:46
	Предлагаю сразу кремний.. да что там, просто физику во всём обвинять. Какие к нам вопросы, это всё Бор с Эйнштейном, да.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	97. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
	Сообщение от Аноним (??) on 11-Апр-14, 00:22
	> Предлагаю сразу кремний.. да что там, просто физику во всём обвинять. Какие > к нам вопросы, это всё Бор с Эйнштейном, да. Ну а что, это процессор во вем виноват! Он программу написанную лабухом выполняет! Вот детектировл бы он IQ автора программы и отказывался бы запускать код от изенов - сразу стало бы безопаснее в два раза.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	146. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от vn971 (ok) on 11-Апр-14, 11:54
	> ключи из памяти требуется изничтожать предсказуемо, как только они перестали требоваться, затерев явным образом конкретно в этом вы не правы, кажется. Никто не мешает уничтожать. Хочешь - уничтожай. array[i] = 0 (или какой там синтаксис у джавы, забыл уже.)
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	147. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от vn971 (ok) on 11-Апр-14, 11:59
	* я конкретно про приход gc.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	168. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 20:09
	> конкретно в этом вы не правы, кажется. Никто не мешает уничтожать. Хочешь - уничтожай. Жабисты все время уповают что за них рантайм подумает и GC освободит. А с GC и прочим тут еще проблема в том как все это хранится внутри и что на самом деле будет сделано. В сях если мы записываем в array[i]=0, можно быть более-менее уверенным что это будет обращение в память и там это будет реально так (btw, еще и кэш процессора в этой механике может поднасpaть, прецеденты были). А чем сложнее рантайм - тем это менее очевидно и требует куда больше знаний о том как он там внутри это видит, чтобы не прострелить себе пятку совершенно неочевиднейшим образом. Если некто может мониторить обращения в массив и рубать оные, он, очевидно, что-то еще делает, потенциально имея дело с нашими данными. Насколько он там внутри себя параноидально относится к утечкам этих данных - очень отдельный такой вопрос. И я не думаю что типовой жабист вообще имеет хоть какое-то понятие как его жаба с массивами работает. Это делает схему в целом куда менее предсказуемой и стало быть чреватой самыми неожиданными прострелами пяток в самых разнообразных местах. Просто потому что например array[i]=0 не трансформировалось в физическую запись в память по нужному адресу и значение ключа там по факту допустим убито не было. Мало ли чего там мегаумный рантайм оптимизнуть решит, etc. Для этого надо очень хорошо знать как он работает и мониторить его развитие.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	171. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от vn971 (ok) on 11-Апр-14, 20:25
	Да, тут с вами полностью согласен. Человек просто говорил именно о GC и сборке мусора (имея в виду, видимо, иммутабельные String-и). А между тем проблем куча, но таки они не в том как GC стринги чистит.
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	186. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 23:09
	> и сборке мусора (имея в виду, видимо, иммутабельные String-и). Я в целом имел в виду мою возможность анализировать поведение получившейся конструкции и понимать что в какой момент времени она делает и является ли фактический результат работы тем чем было задумано в изначальной логики оной, что в криптографии важно. Чем сложнее конструкция, тем сложнее ее анализировать. Поэтому в жабе неизбежно будут кучи багов. И в реализациях SSL. Они просто навороченные до ж...ы. Так что кучи багов там обеспечены, независимо от ЯП. Некоторые баги будут проблемами безопасности. Так что в этом плане мне очень нравится тезис Берштейна: меньше кода - меньше багов. Проблема лишь в том что софт который ничего не умеет - никому и даром не сдался... :)
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	190. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от iZEN (ok) on 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 лет после своего изобретения появился вновь под названием "объектно-ориентированный". По своей сути этот современный концепт (принимаемый многими как панацея) более всего связан с построением иерархий классов или типов. Более старое понятие не было, в сущности, понято, пока не появился новый ярлык "объектно-ориентированный"; теперь же программисты признали присущую абстрактному типу данных мощь и обратились, наконец, к нему. Однако, чтобы об объектно-ориентированных языках можно было говорить всерьез, в них должна быть реализована строгая статическая типизация, которую нельзя было бы нарушить; это дало бы возможность программисту полагаться на компилятор в деле идентификации разного рода несогласованностей. К сожалению, наиболее популярный язык, С++, неудовлетворителен в этом отношении, потому что было изначально декларировано, что он должен быть совместим со своим предком - языком Си. Широкое принятие С++ подтверждает следующие "законы": * прогресс приемлем, только если он совместим с текущим состоянием; * приверженность стандарту - всегда безопаснее, чем даже мотивированный отход от него. Принимая эту ситуацию как данную свыше, программисты вступают в борьбу с языком, который не поощряет структурное мышление и дисциплинированное построение программ, отрицая базовую поддержку компилятора. Они также прибегают к инструментам-паллиативам, которые еще более способствуют разрастанию размеров программ. ---/// > Проблема лишь в том что софт который ничего не умеет - никому и даром не сдался... :) Проблема не в софте, а в программистах, которые ничего не ели слаще пареной репы.
	Ответить | Правка | ^ к родителю #186 | Наверх | Cообщить модератору

	205. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Michael Shigorin (ok) on 12-Апр-14, 23:52
	> В любой программе, сложнее "Hello World", есть баги. Когда у человека обе запятые в предложении на предположительно родном языке являются лишними -- как-то страшненько даже думать про то, что он может накодить.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	208. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от iZEN (ok) on 13-Апр-14, 00:27
	>> В любой программе, сложнее "Hello World", есть баги. > Когда у человека обе запятые в предложении на предположительно родном языке являются > лишними -- как-то страшненько даже думать про то, что он может > накодить. См. придаточные определительные. Союзное слово "которая", которым прикрепляется придаточное определительные к главному предложению, признаюсь, мне лень было писать (думал, не обратят внимание). Однако же на форуме интеллектуального бахвальства всё-таки нашёлся умник, который указал на ошибку пунктуации. :))
	Ответить | Правка | ^ к родителю #205 | Наверх | Cообщить модератору

	209. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Michael Shigorin (ok) on 13-Апр-14, 01:03
	>>> В любой программе, сложнее "Hello World", есть баги. >> Когда у человека обе запятые в предложении на предположительно родном языке >> являются лишними -- как-то страшненько даже думать про то, что он может >> накодить. > См. придаточные определительные. Изя, если человек допускает детские ошибки -- он неграмотен.  Если в них упорствует -- он глуп. Пожалуйста, сходите в школу, проконсультируйтесь у профильного преподавателя и не глупите.
	Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

	212. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от iZEN (ok) on 13-Апр-14, 20:18
	> Изя, Давай я тебя Мичманом буду называть, хорошо? > если человек допускает детские ошибки -- он неграмотен.  Если в них упорствует -- он глуп. Если человек хочет, но по каким-то причинам не может аргументированно поддеть другого человека, то начинает "танцевать" от замечания в адрес его внешнего вида и манеры общения. Стиль дворовой шпаны (гопников, по-современному), но в ракурсе интеллигенции ("илиты" IT, по-современному). > Пожалуйста, сходите в школу, проконсультируйтесь у профильного преподавателя и не глупите. Начни с себя. ;)
	Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

	213. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Michael Shigorin (ok) on 13-Апр-14, 21:34
	>> если человек допускает детские ошибки -- он неграмотен. >> Если в них упорствует -- он глуп. > Если человек хочет, но по каким-то причинам не может аргументированно поддеть Если "другого человека" не пнул аргументированно только ленивый из как минимум трёх, а то и четырёх местных "лагерей" (ссылки собирать лень, но если так хочется сесть в лужу по полной -- можно), то "поддевать" такого смысла особого нет даже любителям поглумиться. Изя, пытаться в ответ на вполне конкретный и благожелательный PR (который problem report) объявлять багу фичей -- глупо.  Пытаться переспорить человека, который, скажем так, немного лучше понимает в вопросе -- глупо в квадрате. На сем позвольте откланяться, желаю скорейшего прихода в разум.
	Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

	214. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от iZEN (ok) on 13-Апр-14, 21:44
	>[оверквотинг удален] >>> Если в них упорствует -- он глуп. >> Если человек хочет, но по каким-то причинам не может аргументированно поддеть > Если "другого человека" не пнул аргументированно только ленивый из как минимум трёх, > а то и четырёх местных "лагерей" (ссылки собирать лень, но если > так хочется сесть в лужу по полной -- можно), то "поддевать" > такого смысла особого нет даже любителям поглумиться. > Изя, пытаться в ответ на вполне конкретный и благожелательный PR (который problem > report) объявлять багу фичей -- глупо.  Пытаться переспорить человека, который, > скажем так, немного лучше понимает в вопросе -- глупо в квадрате. > На сем позвольте откланяться, желаю скорейшего прихода в разум. От себя лишь могу выразить сожаление о случившемся. Ты меня очень разочаровал, Миша.
	Ответить | Правка | ^ к родителю #213 | Наверх | Cообщить модератору

	176. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от iZEN (ok) on 11-Апр-14, 21:14
	>[оверквотинг удален] > что-то еще делает, потенциально имея дело с нашими данными. Насколько он > там внутри себя параноидально относится к утечкам этих данных - очень > отдельный такой вопрос. И я не думаю что типовой жабист вообще > имеет хоть какое-то понятие как его жаба с массивами работает. Это > делает схему в целом куда менее предсказуемой и стало быть чреватой > самыми неожиданными прострелами пяток в самых разнообразных местах. Просто потому что > например array[i]=0 не трансформировалось в физическую запись в память по нужному > адресу и значение ключа там по факту допустим убито не было. > Мало ли чего там мегаумный рантайм оптимизнуть решит, etc. Для этого > надо очень хорошо знать как он работает и мониторить его развитие. Ты нам поведал историю о том, что должен делать рядовой программист на C/C++, разрабатывая свою либу. Однако ж, это же самое относится и к программистам JVM, которые должны следовать соглашениям по модели памяти Java. Хорошо, что это не входит в круг решаемых задач прикладных программистов на языках JVM, а то бы они как разработчики OpenSSL/GnuTLS всё время находились между двух огней — небезопасным инструментом разработки и лёгкостью его применения не по назначению. ;)
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	179. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от vn971 (ok) on 11-Апр-14, 22:10
	> это же самое относится и к программистам JVM щито?
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	184. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	–1 +/–
	Сообщение от iZEN (ok) on 11-Апр-14, 23:00
	>> это же самое относится и к программистам JVM > щито? JVM написана на C++. OpenJDK7u51 для компиляции JVM нужен GCC 4.6+ (LLVM/Clang не по зубам).
	Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

	187. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 23:10
	> JVM написана на C++. OpenJDK7u51 для компиляции JVM нужен GCC 4.6+ (LLVM/Clang > не по зубам). Изя, попробуй поспорить с берштейновским определением проблем безопасности: проблема безопасности - частный случай багов в программе. Всего лишь. Баги можно сажать на любом ЯП. Ну и проблемы безопасности будут на любом ЯП, соответственно.
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	188. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 23:11
	> щито? Знакомьтесь, это - изен. Жабист. Я чертовски уверен что он не сможет написать безопасную программу ни на каком ЯП вообще.
	Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

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

	158. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 11-Апр-14, 15:26
	А не, не из-за этой, само исправилось..
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	211. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (??) on 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 - мало того что код, вежливо говоря - написан странно, так еще и бинарники себя чудно ведут. даже версию под оффтопик - не раз ловили за "лазанием не туда", как-бы.
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

164. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
Сообщение от V (??) on 11-Апр-14, 17:58
http://istheinternetfixedyet.com/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

199. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+1 +/–
Сообщение от t28 on 12-Апр-14, 11:27
> могла эксплуатироваться с ноября прошлого года Не было ни единого разрыва! Не-бы-ло!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

203. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
Сообщение от Аноним (??) on 12-Апр-14, 14:35
http://dlang.ru/211-heartbeat-cve-2014-0160
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема