Стали появляться (http://arstechnica.com/security/2014/04/heartbleed-vulnerabi.../) свидетельства возможного применения Heartbeat-уязвимости (https://www.opennet.ru/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. Например, вслед за появлением (https://www.opennet.ru/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.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=39544
>а также многие банки и финансовые сервисыА как ругали карточки одноразовых кодов ВТБ-шные, а.
Как же, каменный век, Java, сертификаты, прогресс, СМС.
Карточки одноразовых кодов - это круто. А в почту тоже логиниться по карточке одноразовых кодов? И в жаббер? Слушай, а может проще тогда сообщения доставлять голубями? Впрочем, на этот случай есть граждане с рогатками. Хотя стоп, они уже давно проапгрейдились до пневматики с оптическим прицелом, так что перехватят ваши сообщения, как пить дать.
> Карточки одноразовых кодов - это круто. А в почту тоже логиниться по
> карточке одноразовых кодов? И в жаббер? Слушай, а может проще тогда
> сообщения доставлять голубями? Впрочем, на этот случай есть граждане с рогатками.
> Хотя стоп, они уже давно проапгрейдились до пневматики с оптическим прицелом,
> так что перехватят ваши сообщения, как пить дать.Не стоит передергивать.
Если когда-нибудь лишитесь 3700 евро со счета, поймете прелесть одноразовых паролей при работе с деньгами.
> Если когда-нибудь лишитесь 3700 евро со счета, поймете прелесть одноразовых паролей при
> работе с деньгами.Странно, ворочаю килобаксами/килоевро по счетам уже 7 лет. Как-то пока все ок (да, я очень внимательно изучаю все списки транзакций).
Ну если клобаксами, то, полагаю, можете чувствовать себя спокойно, изготовление копии сим-карты оценивается как раз примерно в килобакс. Когда дойдете до хотя бы десятков, чего я вам искренне желаю, а лучше - сотен, тогда советую задуматься.
> изготовление копии сим-карты оценивается как раз примерно в килобакс.Весьма зависит от симкарты. Старые можно дома, на коленке. Древняя атака с вычислением Ki по куче запросов. Сейчас вроде oпcocы перешли на другой алгоритм генерации ответа, как минимум кто-то из них, там этой проблемы нет. Но честно говоря не особо мониторил что там сейчас творится.
> Когда дойдете до хотя бы десятков, чего я вам искренне желаю,
> а лучше - сотен, тогда советую задуматься.Ну, знаешь, если ты сотнями ворочаешь - тут и охрана пригодится уже, etc.
> Древняя атака с вычислением Ki по куче запросовКакие ж вы, гики, предсказуемые. Килобакс - это верхняя граничная оценка оформления (как "потерянной") любым заинтересованным лицом новой сим-карты (с вашим номером) в салоне связи по "левым" документам с учетом материальной заинтересованности работника этого салона связи. Без всяких вычислений.
> Какие ж вы, гики, предсказуемые.Такие же как и вы. Люди вообще достаточно предсказуемы. Особенно глупые.
> (как "потерянной") любым заинтересованным лицом новой сим-карты (с вашим номером)
А тут у вас продолб в терминологии, по поводу чего вас и не поняли. Копия - то что совпадает с оригиналом. А это не "копия" сим карты, скорее "перевыпуск", в том плане что авторизация будет прописана заново, на новую симку. Содержимое SIM будет совершенно новым - wtf "копия"? При этом старая карта работать по идее перестанет, что будет весьма шустро обнаружено владельцем. И уж наверное те кто ворочает сотнями k$ может позволить себе отдельный мобильник и отдельный номер для вещей связанных с банковскими операциями. Хотя даже само по себе знание мобильника опять же не позволяет ничего умыкнуть.
А так то да, бывают странные люди разгуливающие с чемоданами денег по улице. И потом попадающие в сводки новостей - мол, отобрали чемодан и скрылись в неизвестном направлении. Ну пардон, если гуляешь с чемоданом бабла - надо соображать что это привлечет не самых лучших людей и ходить с охраной, чтоли. Ну и тут так же.
> Ну если клобаксами, то, полагаю, можете чувствовать себя спокойно, изготовление копии
> сим-карты оценивается как раз примерно в килобакс.Да каво, дешевле можно)
Но сейчас банки палят смену симкарты и не присылают смс на новую симку.
После замены надо позвонить в банк/зайти в отделение.
А там килобакса не хватит.
>> Если когда-нибудь лишитесь 3700 евро со счета, поймете прелесть одноразовых паролей при
>> работе с деньгами.
> Странно, ворочаю килобаксами/килоевро по счетам уже 7 лет. Как-то пока все ок
> (да, я очень внимательно изучаю все списки транзакций).Тю. Атаки уровня heartbleed тоже годами не было)
Анализа уже совершенных транзакций мало.
Если счет на физ лицо, можно очень быстро вывести деньги на только что созданный кошелек qiwi/yandex/etc, потом на другой, потом вывести на какую-нибудь не именную карточку, и снять.
>А в почту тоже логиниться по карточке одноразовых кодов?Если такая карточка будет реализована в отдельном чипе того устройства, с которого вы это делаете, с надежной защитой по, например, сканированию сетчатки вашего глаза, всё это будет работать прозрачно для вас, не требуя каких-то особых телодвижений и в то же время поддерживаться сервером - то почему бы и нет.
> почему бы и нет.Сканирование? Сетчатки глаза? Чипом с проприетарной фирмварой? Не-не-не, Дэвид Блейн, засуньте ваши зонды себе. А я такой системой пользоваться вообще не буду - целиком перейду на какой-нибудь биткоин и полностью возьму ответственность за их кражу у меня на самого себя.
> Сканирование? Сетчатки глаза? Чипом с проприетарной фирмварой? Не-не-не, Дэвид Блейн,
> засуньте ваши зонды себе. А я такой системой пользоваться вообще не
> будуКак тонка эта грань между паранойей и шизофренией.
Вы в чипе CCD-камеры не пробовали зонды искать? А в LM317?> целиком перейду на какой-нибудь биткоин и полностью возьму ответственность
> за их кражу у меня на самого себя.Непонятно что здесь меняет конечная цель аутентификации (биткойн, e-mail, пароль к сейфу с почтовыми голубями), если мы говорим о способах аутентификации.
А по большому счету ответственность и так на вас. Вы попробуйте как-нибудь на досуге оспорить транзакцию, проведенную вами через интернет-банкинг в российском банке, на практике. Узнаете много интересного.
> Как тонка эта грань между паранойей и шизофренией.
> Вы в чипе CCD-камеры не пробовали зонды искать? А в LM317?Маленький кусочек кремния может нынче содержать много вентилей. И реализовывать довольно сложную логику. Совсем не факт что работающую в мою пользу. Если что - я как раз отлично понимаю как работают микропроцессорные системы. Упомянутый вами девайс явно нуждается в логике которая будет фирмварой делаться, не говоря о том что несанкционированный доступ к такому девайсу позволит кому-то умыкнуть мою уникальную биометрию, чего мне совсем не хочется. И именно поэтому существуют некоторые границы того что я позволю микропроцессорным системам, а что нет. В отличие от большинства других людей я имею наглость использовать их как помощников, а не как электронный ошейник и троянскую конягу.
> Непонятно что здесь меняет конечная цель аутентификации (биткойн, e-mail, пароль к
> сейфу с почтовыми голубями), если мы говорим о способах аутентификации.Мне не придется мудохаться с всякими мегазондами претендующими на мою биометрию, несекурными протоколами, клиентами на всяком жаба-деpьме и прочими отходами мозговой деятельности. Оно не сольет логи в налоговую. И не заморозит счета при введении санкций. А где именно будут храниться фантики-циферки - мне если честно все-равно. Они один фиг абстракция. И так и эдак, в любой инкарнации. Биткоины использовать достаточно комфортно. И как их защищать с хорошим уровнем безопасности я более-менее понимаю. И не надо никаких почтовых голубей и прочих бумажек с одноразовыми паролями. Хватит оффлайнового кошелька, например. Отключенный оффлайн компьютер еще ни 1 хакер ломать не научился :)
> А по большому счету ответственность и так на вас. Вы попробуйте как-нибудь
> на досуге оспорить транзакцию, проведенную вами через интернет-банкинг
> в российском банке, на практике. Узнаете много интересного.Поэтому я на самом деле достаточно компетентно и осторожно пользуюсь онлайн оплатой, оценивая риски и лимитируя возможный урон. То-есть для всяких покупок и прочего я вообще visa virtual использую, там можно и назваться Mr. Cardholder'ом, и денег - только впритык на покупку, etc. Спирать нечего будет :)
Вы таки не поверите, но...
https://www.opennet.ru/opennews/art.shtml?num=38583
http://www.pvsm.ru/radiosvyaz/55388/print/
Это вообще к чему? Ну TCP/IP. Ну по побочному каналу. И что?
К тому, что машина, не имеющая доступ к сети, но стоящая в одном помещении с машиной, такой доступ имеющей - потенциально все равно уязвима. Поэтому "отправить машину в оффлайн" это не панацея, увы, в современном мире.
> потенциально все равно уязвима.Потенциально, вам завтра на голову может упасть метеорит. Ничему не противоречит. Ну вот вероятность этого - примерно такая же как машина с чистой операционкой станет обмениваться по воздуху данными с соседями через микрофон. И, кстати, у моего десктопа например чисто физически нет микрофона. Очень интересно, придет агент АНБ и с раздосадованной миной подарит мне микрофон, чтобы я его подключил? Или чего?
>> потенциально все равно уязвима.
> Потенциально, вам завтра на голову может упасть метеорит. Ничему не противоречит. Ну
> вот вероятность этого - примерно такая же как машина с чистой
> операционкой станет обмениваться по воздуху данными с соседями через микрофон. И,
> кстати, у моего десктопа например чисто физически нет микрофона. Очень интересно,
> придет агент АНБ и с раздосадованной миной подарит мне микрофон, чтобы
> я его подключил? Или чего?У ноутбуков есть микрофоны. И они практически всегда включены.
> У ноутбуков есть микрофоны. И они практически всегда включены.Ну а вот у моего десктопа микрофона нет. Если ты думал что меня интересует _твоя_ безопасность - зря, прежде всего меня интересует защита _моих_ компьютеров от внешних посягательств. А ты в этой схеме - "как получится".
Компьютеры в оффлайне, а сотовый наверняка с андроидом. И наверняка подключали его к компьютеру по usb (чтоб зарядить, например).. Лучше б подискутировали на тему, как можно передавать данные с Андроида, если в нём выключен интернет вообще. И как с помощью одной симки можно получить полный контроль над телефоном.
это чаще использется для сопоставления данных по мобильным устройствам и ноутам/настольным.
то есть, для связывания воедино и идентификации (и отслеживания его перемещения)пользователя, более надежной, нежели для пенетрации и/или коммуникации с зондами, в АНБ, ЦРУ и ко.
>>а также многие банки и финансовые сервисы
> А как ругали карточки одноразовых кодов ВТБ-шные, а.
> Как же, каменный век, Java, сертификаты, прогресс, СМС.Алексей Шипилёв — Прагматика Java Memory Model: http://www.youtube.com/watch?v=iB2N8aqwtxc
Столько паники из-за капли в океане. Про спецслужбы - вообще смешно. Они и без того обязаны следить за разработкой таких продуктов и проводить аудит всех патчей к ним. Думаю, они о ней знали (и эксплуатировали) уже через месяц - два после её появления.
>Думаю, они о ней знали (и эксплуатировали) уже через месяц - два после её появлениязря ты недооцениваешь спецслужбы... об уязвимости они знали (и эксплуатировали) за месяц-два то её появления
За десятки лет до появления OpenSSL спецслужбы уже написали инструментарий для эксплуатации её будущих уязвимостей. Срочно в номер.
<irony>
Были особые люди, которые решили создать спецслужбы для того, что бы они спроектировали и написали сам OpenSSL
</irony>
> За десятки лет до появления OpenSSL спецслужбы уже написали инструментарий для эксплуатацииВ каком-то роде. SSL и TLS наархитектили так, что секурно ими пользоваться почти невозможно. А навороченная либа неизбежно содержит 100500 багов.
>наархитектили так, что секурно ими пользоваться почти невозможноИ это вы тоже склонны приписать страшным спецслужбам?
> И это вы тоже склонны приписать страшным спецслужбам?Учитывая как NIST-у протолкали несекурный ГПСЧ, не удивлюсь если и протокол старались сделать так, чтобы секурно и без лажи его фиг с два получилось реализовать.
Сказано словно можно создать (и уже создано) что-то более простое и секьюрное.
Это вы шутите так или действительно видели человека, утверждающего что чего-то более простого и секьюрного чем OpenSSL создать невозможно, и он над вами не глумился в этом момент?
> Сказано словно можно создать (и уже создано) что-то более простое и секьюрное.Такого человека звали D.J. Berstein. И он таки сделал это - либу NaCl. У нее простое логичное апи, даже дуболому негде облажаться. А еще она может шифровать даже отдельные пакеты, не в пример меньше кластрефака чем в SSL.
Всё может быть. Только тогда это спецслужбы какой-то одной страны... с хорошим мозговым центром.
Да всё протроянено на высшем уровне. Вы как вчера родились.Как можно доверять секретную и конфиденциальную информацию иностранной операционной системе, которая подключена к их же сети?!
Это ты сам у себя спрашиваешь? ;)
> Это ты сам у себя спрашиваешь? ;)У голосов в голове. И они отвеча-а-ают...
> Да всё протроянено на высшем уровне. Вы как вчера родились.
> Как можно доверять секретную и конфиденциальную информацию иностранной операционной системе,
> которая подключена к их же сети?!Как вы можете пользоваться буржуйским браузером, который запущен во вражеской ОС, работающей на ПК, собранным потенциальным противником?
>> Да всё протроянено на высшем уровне. Вы как вчера родились.
>> Как можно доверять секретную и конфиденциальную информацию иностранной операционной системе,
>> которая подключена к их же сети?!
> Как вы можете пользоваться буржуйским браузером, который запущен во вражеской ОС, работающей на ПК, собранным потенциальным противником?Всё просто: все заинтересованные в обладании конфиденциальной информации юридические и физические лица действуют в правовом поле и подчиняются институтам права. Не будь этого, SSL/TLS ничего бы не стоило без сквозного контроля на каждом уровне представления информации. Другими словами, в беспределе нужно было бы каждой группировке/человеку разрабатывать собственное железо и ПО, как-то согласовывать протоколы обмена информацией с другими такими же лицами. При этом собеседники должны принимать ряд базовых вещей от простейших рефлексов до космических технологий, что невозможно в принципе в обществе, где никакие законы (кроме физической силы) не действуют. ;)
В АНБ могут в любой момент списать некую сумму с любой пластиковой карточки любого гражданина их или не их страны, но не делают этого. Вопрос: почему?
Думаю, понятно объяснил.
> карточки любого гражданина их или не их страны, но не делают
> этого. Вопрос: почему?Ну это еще вопрос. Вон нашим чиновникам после санкций гопстопнули карточки. Впрочем, там же и ответ почему: потому что это вызывает нехилый бугурт у клиентуры. Вот местные чиновники уже например всерьез взялись за национальную платежную систему. Которая оттянет на себя часть оборота бабла. А это означает что виза и мастеркард недополучат баблишка...
Насчет гопстопа. У нас на работе несколько человек получали з/п на карточки Собин-банка. Картой раплатиться они не могли, да, но снять с нее деньги в отделении банка - без проблем, ни одной копейки не потерялось.
> Картой раплатиться они не могли, да, но снять с нее деньги
> в отделении банка - без проблем, ни одной копейки не потерялось.И зачем нужна карточка, которой можно пользоваться только в отделении какого-то банка? Мне тогда проще получать сразу наликом - его в любом магазине принимают, минус время на посещение банка.
>> Картой раплатиться они не могли, да, но снять с нее деньги
>> в отделении банка - без проблем, ни одной копейки не потерялось.
> И зачем нужна карточка, которой можно пользоваться только в отделении какого-то банка?
> Мне тогда проще получать сразу наликом - его в любом магазине
> принимают, минус время на посещение банка.Получайте, разрешаю
> Получайте, разрешаюНу а вы оставьте такие карточки себе, для меня они ничего кроме дополнительного геморроя не дают.
Так уж и быть, можете не брать такие карточки.
> в беспределе нужно было бы каждой группировке/человеку разрабатывать
> собственное железо и ПО, как-то согласовывать протоколы обмена информацией
> с другими такими же лицами.Все эти механизмы, интерфейсы и протоколы были учтены и разработаны в CCITT при ООН ещё в 70-е—80-е годы. Стандарты открыты — бери и пользуйся. Только в этих ваших интернетах решили делать всё по-своему. В принципе, это очень хорошо, если бы также параллельно развивались ITU-T-шные концепции. Однако из-за фактического отсутствия альтернативы паре IEEE + The Internet имеем что имеем. Причём пропихнуть на внешний рынок что-то прогрессивное и хорошее, но несовместимое со стандартами IEEE сейчас просто невозможно. А в отличие от ITU, IEEE — частная американская конторка, куда вас могут и не принять по каким-нибудь идеологическим причинам.
А в роутерах на WRT прошивке или в серверных IMPI интерфейсах эта библиотека случайно не используется?
Совершенно случайно нет.
Уязвимостью чревата сама идея TLS Heartbeat. На уровне замысла.
И мы еще услышим.
Расскажите.
> Расскажите.Суть TLS Heartbeat, как следует из драфта
http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04есть «the usage of keep-alive functionality without performing a renegotiation».
Типа, если есть прокисшее SSL соединение, то «TLS Heartbeat»
будет позволять продолжать считать его доверенным на основании вот того
свободного размена данными, который происходит сейчас в атаке bleed.То есть поле для новых злоупотреблений просто непаханное.
И все это просто для того, чтобы не надо было жать кнопочку «Refresh»
после трех часов простоя окошка с данными кредитки, типа.Типа, страшно удобно. Данные формы можно держать, типа, восемь суток
и не забивать по новой номер кредитки, если соединение оторвется.Как без этого жили, да.
Хотя идея heartbeat довольно дурная сама по себе, сабж тут не виноват. В сабже довольно крутой баг с утеканием памяти в сеть. Это не было задумано. Это просто лютый баг в либе. Одной конкретной либе.
В сабже довольно крутой баг с утеканием памяти в сеть. Это не было задумано. Это просто лютый баг в либе. Одной конкретной либе....Одной конкретной либе.
...Одной конкретной либе.
...Одной конкретной либе.
...Одной конкретной либе.
...Одной конкретной либе.
...Одной конкретной либе.
и там до посинения. Может станет правдой )))
> и там до посинения. Может станет правдой )))В других либах именно этого бага - нет. Зато может быть куча иных, не менее веселых. Навороченному протоколу - куча багов, все честно.
Впрочем, вам с вашим ником простительно нести чушь.
да не, автор коммента - прав.
реально убогая идея для решения несуществующей проблемы.
та-же хрень с курисами в браузерах для аутентификации, благодаря чем - мы до сих пор не имеем нормальной авторизации в веб-е.
Для реализации heartbeat достаточно было бы определить пакеты для запроса и ответа. Они же там наворотили зачем-то "отправку запрошенного количества байтов". Ну и программер явно был в доле, потому что не специально отправить по запросу произвольное количество байт - очень сложно.
На OpenWRT какой-то свой шайтан-ssl-сервер писанный на LUA.
Сервер-то свой, а суть всё та же.http://luci.subsignal.org/trac/browser/luci/trunk/libs/nixio...
> На OpenWRT какой-то свой шайтан-ssl-сервер писанный на LUA.На LUA там написаны скрипты которые морду рисуют. Сервер там самопальный, uhttpd, но писан он таки на сях. А шифрование он таки из OpenSSL вроде как использует, так что если некто вывесил его в WAN или публично доступный LAN - ахтунг, ахтунг, ахтунг.
> А в роутерах на 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 рассказать )
У меня единственное место, где живет IPMI настолько древнее, что 1.0 openssl еще не написали тогда. И в инет не смотрит :)
> Да и gnutls-utils - 2.8.6-2 там есть.А при тем тут gnutls? В нем какие-то баги есть? В openssl баг специфичный для этой либы.
> А при тем тут gnutls? В нем какие-то баги есть?"Уязвимость оценивается как очень серьёзная и подрывающая доверие к проекту. Ховард Чу (Howard Chu), главный архитектор проекта OpenLDAP, ещё в 2008 году выступал с рекомендацией прекращения использования GnuTLS в связи с несоблюдением элементарных правил безопасности в кодовой базе GnuTLS, в частности, повсеместном использовании функций strlen и strcat. По мнению Ховарда, исправить ситуацию может только полный пересмотр API GnuTLS"
https://www.opennet.ru/opennews/art.shtml?num=39239
> "Уязвимость оценивается как очень серьёзная и подрывающая доверие к проекту.А, про это я уже забыл. Ну а что, нагородили меганавороченные протоколы с кучей фич - получите кучу багов в их реализациях. Вроде логично. Хорошие вещи должны быть простыми. Теперь вы понимаете почему мне нравится NaCl. Очень прикольно сделанный диффи-хеллман на эллиптических кривых с неплохой подборкой алгоритмов. И апи которым может пользоваться даже простой смертный, а не только супергуру.
Осталось ответить на вопрос почему им никто не пользуется.
> Осталось ответить на вопрос почему им никто не пользуется.Появился относительно недавно. И, кстати, кто сказал что им не пользуются? В последнее время NaCl/libsodium(более портабельный вариант) использует довольно много софта. Откуда я про них и узнал, собственно.
>> "Уязвимость оценивается как очень серьёзная и подрывающая доверие к проекту.
> А, про это я уже забыл. Ну а что, нагородили меганавороченные протоколы
> с кучей фич - получите кучу багов в их реализациях. Вроде
> логично. Хорошие вещи должны быть простыми. Теперь вы понимаете почему мне
> нравится NaCl. Очень прикольно сделанный диффи-хеллман на эллиптических кривых с неплохой
> подборкой алгоритмов. И апи которым может пользоваться даже простой смертный, а
> не только супергуру.Эллептические кривые - прямиком из лабораторий АНБ. Хрен знает что они там придумали.
> ЭллептическиеУ... я так смотрю, вы мегамозг. Только не спрашивайте как я это узнал :).
> кривые - прямиком из лабораторий АНБ.
Вы переоцениваете АНБ. Эллиптические кривые, FYI, придумали математики. А АНБ всего лишь вовремя подсуетилось, чтобы NIST подсунуть бажную реализацию ГПСЧ на их основе, не более. Вот кстати выбору кривых от NIST я бы доверять не стал. Но какой-нибудь Берштейн, его группа любителей криптографии и выбранные ими кривые - к NIST и АНБ относятся чуть менее чем никак. Ну нет у АНБ эксклюзивных прав на довольно базовые конструкции из области математики.
> Хрен знает что они там придумали.
С таким уровнем знаний лучше молчать в тряпочку и не высовываться. За умного сойдешь. А когда вы занимаетесь тем что распостраняете ламерский буллшит, абсолютно не разбираясь в вопросе и даже не зная как пишется слово "эллипс" - это пржде всего выставляет лично вас некомпетентным болваном, который, тем не менее, имеет мнение. То-есть, ламером.
Берштейну или какому-нибудь его помощнику АНБ просто заплатило немножко денег, чтобы направить его поиск в нужном направлении. Никто ж не заметит и все доверяют.
> Берштейну или какому-нибудь его помощнику АНБ просто заплатило немножко денег, чтобы направить
> его поиск в нужном направлении. Никто ж не заметит и все
> доверяют.про скандал с обоим закладками от АНБ, проплаченными RDA за миллионы баксов - читали ?
там в обоих случаях - так нефигово, в тысячи раз, была ослаблена реализация =)
мораль: имея физическую возможность давления на разработчика(не суть частное лицо или компанию, комьюнити) и/или mitm-интерференции с их работой - это не ахти какой сложности задача для Люьбой спецслужбы )
> сложности задача для Люьбой спецслужбы )ВСЕ «системы шифрования» уязвимы ПРИНЦИПИАЛЬНО.
На уровне ДИЗАЙНА, на уровне МАТ. МОДЕЛИ, положенной в их основу.
«Бекдоры», тривиальные состояния системы, существуют в них ПРИНЦИПИАЛЬНО.Ради того, чтобы банкомат хавал 4-х значный PIN.
С некоторой степенью надежности.Или носи с собой бумажку с набором одноразовых 108-буквенных паролей, или PIN,
но с возможностью обнаружения и утечки эксплойта.При этом, самый тупой «шифр» прошлого ТЫСЯЧЕЛЕТИЯ — НИКАК И НИЧЕМ НЕ ВСКРЫВАЕТСЯ.
Так что хорош пенить ситро.
>бумажку с набором одноразовыхВот видите, совсем не все "системы шифрования» уязвимы ПРИНЦИПИАЛЬНО"
>108-буквенных паролей
Пяти-шести-цифровых вполне достаточно IRL
Эллиптические кривые - прямиком из оснований математики, вообще-то.
> А в роутерах на WRT прошивкеТам по дефолту ничего SSLного в сеть не торчит вроде. Но если торчит - да, заапдейтить надо.
gmail, fb и vk попали под раздачу?
> gmail, fb и vk попали под раздачу?Вполне вероятно. Более того - баг вывешивает память процесса в сеть, так что даже приблизительно оценить масштабы пи...ца будет довольно сложно.
> что даже приблизительно оценить масштабы пи...ца будет довольно сложно.Шнайер облегчает наши сомнения: 11 из 10 баллов.
баг специально внесли из-за коммерческой выгоды, все попёрли менять ssl сертификаты - круто
> баг специально внесли из-за коммерческой выгоды, все попёрли менять ssl сертификаты -
> крутоДа ну?
>все попёрли менять ssl сертификатыпопёрли менять сертификаты только истерички, паникёры и лохи, которые начитались страшилок в интернетах и теперь жутко бояцца. на таких по жизни наживаются предприимчивые дельцы, баг в openssl - лишь очередной способ из подоить, не первый и не последний
Для "истеричек, паникёров и лохов..." ниже показал скриншот,
с реально рабочего сервера, с довольно полезной инфой для конкурентов.
> попёрли менять сертификаты только истерички, паникёры и лохи, которые...которые не хотят сливать свои пароли и приватные ключи всему миру. Только вот они то как раз не лохи. Лохи - те кто этого не сделал. По поводу чего в будущем их будет ждать мнооооого интересных поимений.
> предприимчивые дельцы, баг в openssl - лишь очередной способ из подоить,
> не первый и не последнийТо что PKI лохоразвод - вы, конечно, правы, но в данном случае пи...ц таки имеет место быть.
я бесплатно перевыпустил свои сертификаты. причем сроки сертификатов остались старыми.
Старые-то заэкспайрить не забыли? :)
Redmine тоже дырявый. http://i59.fastpic.ru/big/2014/0410/2e/9fd0122735fb7d475abc7...
Как данный скриншот указывает на дырявость Redmine?
> Как данный скриншот указывает на дырявость Redmine?Cookie: _redmine_session и далее по тексту ...assword=v_pupkin&login=Login+vasya
Для тех кто не в курсе: Redmine может работать как в режиме CGI, или как самостоятельный сервер.
> Для тех кто не в курсе: Redmine может работать как в режиме
> CGI, или как самостоятельный сервер.Но это не значит, что его надо так запускать.
Вообще, веб сервер на Ruby - не самый лучший фронтенд :)
Лучше спрячьте за nginx, мой вам совет.
nginx обновить может быть куда проще.
>> Как данный скриншот указывает на дырявость Redmine?
> Cookie: _redmine_session и далее по тексту ...assword=v_pupkin&login=Login+vasya
> Для тех кто не в курсе: Redmine может работать как в режиме
> CGI, или как самостоятельный сервер.А причём тут "дырявость" redmine-е, если данные получены через уязвимость libssl? (или может вообще обычным tcpdump - не знаю как были получены данные не screenshot-е).
> А причём тут "дырявость" redmine-е,При том что пароль в открытом виде фигачат, полагаясь на "защиту соединения", которая не очень то и защищает.
>> А причём тут "дырявость" redmine-е,
> При том что пароль в открытом виде фигачат, полагаясь на "защиту соединения",
> которая не очень то и защищает.А другие Web ITS как работают?
> А другие Web ITS как работают?Так же как и все остальное от веб хомячья, разумеется. Т.к. дыра на дыре и дырой погоняет.
>> А другие Web ITS как работают?
> Так же как и все остальное от веб хомячья, разумеется. Т.к. дыра
> на дыре и дырой погоняет.Ну, получается, что >95% сайтов с поддержкой аутентификации (включая www.opennet.ru) - дырьё.
Я согласен, что передавать plaintext пароли даже через SSL - моветон. Но "обычный пользователь" не способен освоить аутентификацию по сертификатам, а делать а-ля CHAP на базе JS - это изврат. А другие варианты не очень совместимы сквозь зоопарк браузеров.
В любом случае, вне зависимости от того, насколько это соответствует правилам хорошего тона, данная особенность Redmine не является дырой. Это просто известная особенность современных web-ресурсов и известными методами защиты, и с известными проблемами этих методов.
А потом все удивлялись, откуда такой ажиотаж вокруг сноудена, все же знали, что следят. Видимо, без капитана сноудена наивные обыватели не способны представить во что выливаются те или иные технические проколы. А как только посмотрят презентацию с надписью "собрано 2 миллиарда ключей" - так сразу начнут вопить как резанные.
мало того, некоторым и выступлений Сноудена недостаточно
> Redmine тоже дырявый.Ну что ты как маленький, скрипткидизы думали что мегалиба сделает им зашибись. Поэтому слали пароль открытым текстом, как есть. А теперь пора выкусить результаты.
> но не предусматривающими возможность автоматического обновления прошивки.А Столман давно говорит, что надо делать.
> А Столман давно говорит, что надо делать.Ну дык. Использовать девайсы где исходники прошивки есть.
Писали открытый ССЛь, скопипастили проприетарный код не глядя :)
причем наверняка АНБ :)
> причем наверняка АНБ :)Как будто список спецслужб мира состоит из одного АНБ. Все они одним миром мазаны.
> Как будто список спецслужб мира состоит из одного АНБ. Все они одним
> миром мазаны.может и не АНБ, но американская точно
>> Как будто список спецслужб мира состоит из одного АНБ. Все они одним
>> миром мазаны.
> может и не АНБ, но американская точноВы про русские спецслужбы вообще слышали? Нет? А ведь они есть. А ведь это наши занимают первые места на всяких хакерски-программерских олимпиадах. Есть над чем задуматься, правда? ;)
> над чем задуматься, правда? ;)Да, наши занимают первые места в олимпиадах. А потом они работают в их интелах, фэйсбуках, гуглах и прочих. Потому что там нормально платят и с управлением компаниями порядок.
ха, я был прав http://lenta.ru/news/2014/04/12/heartbleed/
Ловим гадов через 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: "
> "ScriptKiddy detected: "Действительно, detected: залоггил и забил. Ну а дропать пакет кто будет, Пушкин? :)
...и вместо 40 00 может быть нечто другое...
> ...и вместо 40 00 может быть нечто другое...Я знаю. Зато запись в логе понтовую - нарисовал. Вот как-то так скрипткидисы и детектируются :).
> ...и вместо 40 00 может быть нечто другое...И детектировать как string... ну в общем, намного более нормальный рецепт написан в советах: https://www.opennet.ru/tips/2830_openssl_block_iptables_heart...
Тут вам и логгинг, и удавка пакета, и, блин, ищется u32 а не string, что по идее заметно быстрее.
>> ...и вместо 40 00 может быть нечто другое...
> И детектировать как string... ну в общем, намного более нормальный рецепт написан
> в советах: https://www.opennet.ru/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
Появились сведения (http://techrights.org/2014/04/08/howard-schmidt-codenomicon/), что публикация данных о Heartbeat-уязвимости является манёвром Microsoft, отвлекающим от проблем, вызванных прекращением поддержки Windows XP, и направленным на будущую дискредитацию СПО в глазах потребителей.Уязвимость раскрыта в день прекращения поддержки Windows XP и активно продвигается с использованием ранее не применяемых в СПО PR-методов (например, был создан отдельный сайт heartbleed.com). Председателем совета директоров открывшей уязвимость компании Codenomicon является Howard Schmidt, бывший глава службы безопасности Microsoft.
Ну чо, спасибо посанам из маздайсофта, спалили бэкдор!!! Дайте иcчо! :)
А под Debian 6 и SLES нету? А то какбэ они не дырявые.> Уязвимость раскрыта в день прекращения поддержки Windows XP и активно продвигается
Google, Dropbox, Facebook уже бегут ставить на свои сервера Вантуз 8, ога.
всё может быть
И шо они скажут? В Windows Next самое неуязвимое шифрование? :) Кто им поверит? Не, ну конечно, те кто и раньше безропотно заглатывали их "продукты" и дальше глотать будут. Таких и убеждать не надо.
типа не переходите c XP на сторонние *nix-системы, там все плохо, вот например дыра в openssl. Но ведь стэк openssl используется и на винде и во многом входит/заимствован в составе инфраструктуры винды в части криптографии. Ибо как IE реализует https?
http://www.securitylab.ru/vulnerability/449697.php
дыра во всех виндах с 2001 года. им и без openssl хорошо.
> криптографии. Ибо как IE реализует https?Оффтоп - а почему IE не может пройти авторизацию, если пароль передается в виде хеша md5 ?
Просто тупо правильный пароль не подходит - во всех остальных браузерах все ок.
Возьми снифер да посмотри что там передается по факту. Может он digest авторизацию считать не умеет? Или что ты там используешь...
> Появились сведения (http://techrights.org/2014/04/08/howard-schmidt-codenomicon/),
> что публикация данных о Heartbeat-уязвимости является манёвром Microsoft, отвлекающим
> от проблем, вызванных прекращением поддержки Windows XP, и направленным на
> будущую дискредитацию СПО в глазах потребителей.а какое отношение имеет openssl к линуксу как таковому?
> а какое отношение имеет openssl к линуксу как таковому?А никакого. Чуть погодя юзеры виндов узнают сколько софта юзало статически влинкованную либу и по этому поводу бессовестно продалбывало их данные злонамеренным серверам.
> либу и по этому поводу бессовестно продалбывало их данные злонамеренным серверам.Ну, за здоровье IIS! Не чокаясь.
> Ну, за здоровье IIS! Не чокаясь.Ага, здоровый зомбяк. Все время из могилы вылезает, зараза.
>Все время из могилы вылезает, зараза.Спонсер-вурдалак-некромансер бдит и собирает opennet.ru/openforum/vsluhforumID3/81138.html#34 opennet.ru/openforum/vsluhforumID3/74800.html#285 жатву. [тёмный жнец]
> Спонсер-вурдалак-некромансер бздит//fixed.
> и собирает
И апачует.
> opennet.ru/openforum/vsluhforumID3/74800.html#285 жатву.
Что-то нет там ничего, видимо потерли.
У них там в загашниках типа еще есть гостинцы?
вангую появление новой библиотеки
> вангую появление новой библиотекиПопроси вангователь у анонима сверху. NaCl уже есть.
> ... NaCl уже есть.а PoCl и NeСl будут?
>> ... NaCl уже есть.
> а PoCl и NeСl будут?Не, не так. KCl и Na(OH)2
> Не, не так. KCl и Na(OH)2Выделил оценку по неорганике, если что.
Извиняюсь, перепутал валентность металлов.
Если так напишу:
Na(OH)2-
Ион сойдёт за оправдание? :)
> Ион сойдёт за оправдание? :)А что за ион такой странный? NaOH диссоциирует на Na+ и OH-. А это что за хрень?
Теоретически возможный в какой-либо момент времени. Разумеется, сразу распадётся, как образуется.
> Теоретически возможный в какой-либо момент времени. Разумеется, сразу распадётся, как
> образуется.полимеры Na[NN]OH[MM] тоже по броску кости могут образовываться!
Если и будут, то будет PoCl на всех 3х, ибо NeCl
> ибо NeClДа, удачи вам заставить неон провзаимодействовать с хлором...
>> ибо NeCl
> Да, удачи вам заставить неон провзаимодействовать с хлором...При помощи кувалды и такой-то матери...
> При помощи кувалды и такой-то матери...Сдается мне, тут даже термоядерная кувалда может спасовать.
>> При помощи кувалды и такой-то матери...
> Сдается мне, тут даже термоядерная кувалда может спасовать.Вдуваешь в баллон 50% неона, 50% хлора, взбалтываешь! Опа!
> Вдуваешь в баллон 50% неона, 50% хлора, взбалтываешь! Опа!Расслаивается и продолжает болтаться себе. Неон вообще-то инертен.
>> Вдуваешь в баллон 50% неона, 50% хлора, взбалтываешь! Опа!
> Расслаивается и продолжает болтаться себе.Надо было добавить, "Взболтать перед употреблением"
> Неон вообще-то инертен.
Ну это его проблемы, взболтать никогда не помешает (к инициирующим ВВ не относится)
> Надо было добавить, "Взболтать перед употреблением"Ну вот в сабже не добавили, видишь чего получилось?
> вангую появление новой библиотекидавно пора разнообразие, хотя на примере ffmpeg/libav особенного прогресса не наблюдается...
Да и ядро ОС неплохо бы, основанное не на идеях 50-летней давности.
А множатся что-то лишь нескучные хипстерские обои. Странно, да?
> Да и ядро ОС неплохо бы, основанное не на идеях 50-летней давности.А зачем чинить то что не сломано? А электродвигатели и трансформаторы работают уже пару столетий, с довольно небольшими усовершенствованиями.
>> Да и ядро ОС неплохо бы, основанное не на идеях 50-летней давности.
> А зачем чинить то что не сломано?Точно не сломано? Что ж тогда всё чинят и чинят, и всё костылями да костылями, один другого неприглядней.
> А электродвигатели и трансформаторы работают уже пару столетий, с довольно небольшими усовершенствованиями.
То-то у всех ваших гаджетов блоки питания линейные, с большими трансформаторами. Хотя постойте..
> Точно не сломано? Что ж тогда всё чинят и чинят, и всё
> костылями да костылями, один другого неприглядней.А это потому что симпатичные дизайны хорошо смотрятся как демонстрационная модель в кабинете физики, но для нормальной работы в реальном мире - приходится докостыливать по месту. Так что академически-симпатичные дизайны как-то все время в пролете оказываются. А все сколь-нибудь успешные операционки были гибридами или монолитами. С кучей костылей и "недостатков". Зато работали хорошо. Вон микроядра - как-то оказалось что ОС на их основе сделать сложнее, драйвера писать никто не хочет, работает тормознее. Так и осталось игрушкой академиков да системой для специальных применений.
> То-то у всех ваших гаджетов блоки питания линейные, с большими трансформаторами. Хотя
> постойте..То-есть, подъем частоты преобразования не меняет на фундаментальном уровне принцип его работы. Это лишь позволяет сделать трансформатор меньше по размеру.
Я всегда знал, что даже на Tor полностью надеяться нельзя.
В области распространения германских языков Тору посвящён день недели — четверг (англ. thursday, нем. Donnerstag). по четвергам можно пользоваться
> Я всегда знал, что даже на Tor полностью надеяться нельзя.В конструкции сети Tor есть минимум 2 серьезных упущения, вообще никак не связанных с SSL.
учитывая кем и для чего был разработан Тор, ваша ремарка - может лишь улыбку, вызвать )
>Другой вопрос, случайно или нет подобная уязвимость появилась в OpenSSL.Это вопрос не "другой", это вопрос самый главный.
Да, такого фейла ещё не было наверное в истории IT. А некоторые люди ещё и отказываются обновлять OpenSSL на своих серверах. Это было бы смешно, если не было бы так печально...
Debian oldstable спасает.
> Debian oldstable спасает.Совсем не включать компьютер - надежнее.
> люди ещё и отказываются обновлять OpenSSL на своих серверах.Не пользуйтесь такими серверами. Проипут они ваши данные и логины с паролями.
C/C++ всё погубил.
> C/C++ всё погубил.Но жабка мало чего годного из либ родила
> C/C++ всё погубил.Остальные облажались бы еще раньше, ибо GC и тому подобные - криптографии не друг и не товарищ: ключи из памяти требуется изничтожать предсказуемо, как только они перестали требоваться, затерев явным образом. А не "когда GC раздуплится" и "хрен его знает насколько он там почистит". На твоей жабе способов прострела себе пятки в криптографии в 100500 раз больше. И уж там дыр сроду было всех сортов и размеров. Их по 30 штук критикалов в каждом релизе давят. Просто все уже привыкли к тому что там постоянный п....ц и уже не обращают на него внимания.
>> C/C++ всё погубил.
> Остальные облажались бы еще раньше, ибо GC и тому подобные - криптографии
> не друг и не товарищ: ключи из памяти требуется изничтожать предсказуемо,
> как только они перестали требоваться, затерев явным образом. А не "когда
> GC раздуплится" и "хрен его знает насколько он там почистит". На
> твоей жабе способов прострела себе пятки в криптографии в 100500 раз
> больше. И уж там дыр сроду было всех сортов и размеров.
> Их по 30 штук критикалов в каждом релизе давят. Просто все
> уже привыкли к тому что там постоянный п....ц и уже не
> обращают на него внимания.Java написана на C/C++, поэтому в ней полно дыр. Очевидно и логично.
> Java написана на C/C++, поэтому в ней полно дыр. Очевидно и логично.Логика жабиста: во всем виноваты ... нет, не программисты. Си и плюсы во всем виноваты, о как. Вот это я понимаю, ламерство. Впрочем, в openssl есть ламерство и на уровне чистейшей алгоритмики, вообще без привязки к сям и плюсам. Ну вот например, почему криптографическая либа, поюзав память, вообще не чистит ее после юзежа? Ах, авторы раздолбаи и не парятся? Ах, еще и malloc перехватили, чтобы система на могла поумничать. Замечательно. Правда такое по смыслу долбоклюйство можно повторить на любом ЯП, а экспонаты с GC еще и помогут наступить на грабли дюжиной неочевидных способов, прихранив ключи в памяти еще на полчасика, хотя об этом никто не просил. Ведь GC лучше знает когда ключ протух, правда?
>> Java написана на C/C++, поэтому в ней полно дыр. Очевидно и логично.
> Логика жабиста: во всем виноваты ... нет, не программисты. Си и плюсы
> во всем виноваты, о как.Потому что ЯП C/C++ допускают использование памяти небезопасным способом даже из другого потока — что и продемонстрировано уже миллион раз. Это на уровне ДНК конкретного языка и лечится только сменой ЯП.
> Вот это я понимаю, ламерство.
Понимай как хочешь. Как был упёртным синюшником, так и проживёшь им до старости. А там уж маразм прихватит — не до других концепций программирования будет.
> Впрочем,
> в openssl есть ламерство и на уровне чистейшей алгоритмики, вообще без
> привязки к сям и плюсам. Ну вот например, почему криптографическая либа,
> поюзав память, вообще не чистит ее после юзежа?Наверно потому, что в C/C++ нет возможности определить, понадобится эта память ещё раз или нет — лучше перестраховаться, чем нарываться периодически на NullPointerException (или что там у вас обозначает NPE: Error, "сливай воду — программа выполнила недопустимую операцию и будет свалена в кору", "память не может быть Read"?).
> Ах, авторы раздолбаи и не парятся?
Да разработчики на C/C++ что и делают, так это парятся, как бы их поделия были устойчивыми и не ловили NPE на ровном месте — там, где другие языки давно ушли по эволюционной лестницы от смарт-поинтеров и null-терминейт массивов с алгоритмами Шлемиля к чётко определённым структурам данных заведомо известных типов без всяких оверхедов на RTTI.
> Ах, еще и malloc перехватили, чтобы система на
> могла поумничать. Замечательно. Правда такое по смыслу долбоклюйство можно повторить на
> любом ЯП, а экспонаты с GC еще и помогут наступить на
> грабли дюжиной неочевидных способов, прихранив ключи в памяти еще на полчасика,
> хотя об этом никто не просил. Ведь GC лучше знает когда
> ключ протух, правда?Ты Java Memory Model изучил, чтобы такую чепуху городить здесь?
>> Впрочем,
>> в openssl есть ламерство и на уровне чистейшей алгоритмики, вообще без
>> привязки к сям и плюсам. Ну вот например, почему криптографическая либа,
>> поюзав память, вообще не чистит ее после юзежа?
> Наверно потому, что в C/C++ нет возможности определить, понадобится эта память ещё
> раз или нет - лучше перестраховаться, чем нарываться периодически на NullPointerException
> (или что там у вас обозначает NPE: Error, "сливай воду -
> программа выполнила недопустимую операцию и будет свалена в кору", "память не
> может быть Read"?).Не де Билл ли? :-)
> Потому что ЯП 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 изучил, чтобы такую чепуху городить здесь?
О, ты кажется начинаешь понимать суть проблемы. Чем сложнее и навороченнее рантайм - тем сложнее из него выжать тот уровень предсказуемости, который необходим для реализации надежной криптографии.
Ругаетесь вы клёво, но всё-таки выход за рамки массива -- это таки то что хочется чтобы запрещал язык.
Я понимаю что всегда можно обвинить в тупизне разраба -- и так оно и есть. Но умных разрабов не бывает (имхо). Так что до тех пор пока мы не идеальны, а проги наши не верифаятся "математически" компьютером -- надо ожидать от себя ошибок. В частности, не говорить что без плохого менеджмента и руководства мы написали бы хороший софт. И признавать недостатки языка вместо оправдывания оного.
> Ругаетесь вы клёво, но всё-таки выход за рамки массива -- это таки
> то что хочется чтобы запрещал язык.По конкретно этому пункту - я даже согласен до некоторой степени. И сдается мне что проще это оформить как расширение си/си++ чем бодаться с мегасложным рантаймом, пытаясь из него предсказуемость нужную криптографам выжать.
> Я понимаю что всегда можно обвинить в тyпизне разраба -- и так
> оно и есть. Но умных разрабов не бывает (имхо).Не совсем так. Каждый должен заниматься своим делом. А если дворник поперся булки печь, получился какой-то трэш и хлебозавод несет адские убытки - человек занимался не своим делом, по поводу чего закономерно получился хреновый результат. Ну вот от тех кто лезет писать криптографическую либу ожидается некое понимание проблематики области и соответствюущее мышление и квалификация. Если этого не наблюдается - будет честно, если у него сольется репутация и он будет известен как БРАКОДЕЛ, продукцию которого использовать не стоит.
Ну так вот, посмотрим на уязвимость. Пароли, говорите, отсылаются? Из памяти? Ок! А какого, собственно, пароли в памяти забыли? Коли она не занята и вообще? Ах, пароли и ключи никто не чистил, после того как они перестали быть нужны? Воооооо! В этом месте мы начинаем догадываться: начальный источник проблем - это оно, а то что такая память так или иначе может утекать - СЛЕДСТВИЕ более фундаментальной проблемы: какие-то удоды не чистят за собой память с чувствительными данными. Заметьте, блок памяти может не только улететь в сеть из-за бага либы. Какая-нибудь программа в другом месте может выделить себе блок памяти. И если никто расчисткой не заморачивался - там ВНЕЗАПНО окажутся эти ключи и пароли. Круто, правда? А то что это другой пользователь и другой процесс - нууу... никто же не чистил память! По изначальной идее, пароли и ключи живут в памяти абсолютно минимально необходимое время и как только не требуются - явно затираются. Это нагибает такие векторы атак. Если бы это было сделано - утечка памяти, конечно, неприятно, но не была бы фатальной. А вот в таком виде - тут только остается гадать: где еще оно выстрелит в следующий раз? В многозадачной многопользовательской системе процесс для начала живет не один. И результаты его жизнедеятельности могут в принципе оказаться доступны другим, если они не озаботились этим вопросом.
> Так что до тех пор пока мы не идеальны, а проги наши не
> верифаятся "математически" компьютеромА тут нам Тюринг объяснил что нет в жизни счастья. Одна программа не может анализировать другую произвольную программу и выносить какой либо определенный вердикт. FAIL.
> не говорить что без плохого менеджмента и руководства мы написали бы
> хороший софт. И признавать недостатки языка вместо оправдывания оного.Хороший софт начинается с грамотного программиста. Если некто хочет что-то делать с криптографией, он для начала должен начать мыслить как криптограф. Вокруг враги. Враги хотят спереть наши данные. И придется параноидально защищать от них каждый бит. Тогда враг [может быть] не пройдет. А если оно как в openssl - там еще много интересных багов бомбанет, совершенно независимо от того, будет ли проверка диапазона массива. Замести мусор под ковер - это не фикс. Ведь намного более фундаментальная проблема "куча ценных данных болтается в памяти неопределенный срок и их никто не чистит" - никуда от проверки границ не делась. А если "мы, тут, типа, соединение защищаем", да еще с API как у OpenSSL, которое сколь-нибудь секурно использовать может только тот кто в криптографии уже неплохо разбирается - это примерно как дедушка-сторож, у которого из вооружения только клюка, против банды из десяти головорезов.
> А тут нам Тюринг объяснил что нет в жизни счастья. Одна программа не может анализировать другую произвольную программу и выносить какой либо определенный вердикт. 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]
> любой другой скажет остановится ли она. Но у нас _одна_ программа
> анализ которой нужно сделать.Во первых, если посмотреть на реальный мир, то у нас дофига программ. Во вторых, они еще и разные версии постоянно выпускают. Так что это как раз сильно ближе к случаю анализа произвольных программ. А какую практическую ценность несет анализ одной прибитой гвоздями версии одной программы?
Во вторых, простая логика подсказывает мне что у мало-мальски больших программ возможно такое большое число состояний, что анализ всех возможных вариантов работы программы займет столько, что рак на горе свистеть устанет, солнце превратится в красный карлик, ну и вообще, когда оно закончится - все это будет уже накому и даром не надо, так что радости то.
> В общем, я имею в виду вот эту технологию:
> 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.Да я тоже простейший тасксвичер напишу без багов. А кому он будет нужен? В общем то единственная проблема с микроядрами: там просто сложные вещи перепихнуты на чуть другие головы, поэтому те кто писал "тасксвичер" могут встать в позу Д'Артаньяна и гордо заявить что у них багов нет. Это вполне может быть правдой, в силу того что само микроядро мелкое. К сожалению это означает лишь то что сложные моменты перепихнули в иные компоненты. И, заметим, про их верификацию все технично молчат в тряпочку. Поэтому секурным оно будет в тепличных условиях, у академиков в лаборатории, где одно лысое ядро которое ничего не делает. А сделай из этого десктопник, с навороченными драйверами и софтом - и будет все как обычно.
Ээээ, я просто объяснял что значит компьютерно-верифицированная программа..И, кстати, как и в математике -- доказательства легко можно модифицировать в случае небольших изменений требований в задаче. То есть, версия никуда гвоздями не прибита. Модифицируешь код, модифицируешь доказательство кода -- всё ок.
На счёт времени верифицирования -- вы не правы, оно очень мало. Все возможные состояния никто не рассматривает, так же как не рассматривают все возможные состояния неупорядоченного массива когда доказывают корректность bubble sort (мелом на доске).
> Ну вот например, почему криптографическая либа,
> поюзав память, вообще не чистит ее после юзежа? Ах, авторы раздолбаи
> и не парятся? Ах, еще и malloc перехватили, чтобы система на
> могла поумничать.А зачем её чистить? Вся программа должна быть достаточно надёжной, в составе которой работает эта библиотека. И которой программе как-то все секретные пароли даются и она ими управляет... :-)
> А зачем её чистить?Чтобы врагам не досталось! Ну там другим процессам, другим юзерам, etc. Не айс будет если какой-то хмырь выделит себе блок памяти, а там бац - привкей от банка с миллионом лежит! Потому что его никто оттуда не снес, вы прикиньте?
> Вся программа должна быть достаточно надёжной,
И в рамках криптографии надежность кроме всего прочего подразумевает защиту ключей от утечки. Блокирование памяти от доступа другими процессами. Запрет выгрузки в своп. Затирание нулями как только ключ более не требуется, etc. Параноидальное отношение к самым базовым операциям, типа операций сравнения. Это отдельная тонкая механика. И ее проще всего реализовать на простом и предсказуемом рантайме. Потому что допинать сложный навороченный рантайм до кондиции когда его фичи не будут вызывать внезапный прострел пяток в самых непредсказуемых ситуациях - сложно, да.
>допинать сложный навороченный рантайм до кондиции когда его фичи не будут вызывать внезапный прострел пяток в самых непредсказуемых ситуациях - сложно, даНо заказчики хотят Java, так что будут допинывать.
Вот у low-latency лагеря те же проблемы - http://mechanical-sympathy.blogspot.ru/2012/03/fun-with-my-c...
А в real-time мире так и к С++ больше вопросов чем ответов.
http://www.embedded.com/design/programming-languages-and-too...
> А в real-time мире так и к С++ больше вопросов чем ответов.Меньше чем к яве. А так то да - чем проще некая конструкция, тем она предсказуемее. А в криптографии это далеко не последнее дело. Вон scrypt'у например припомнили что там время работы зависит от cache hit/cache miss. Вроде пустячок, а тайминг атаки потенциально позволяет. Так появились catena, sponge и т.п, время работы которых - более-менее постоянное, независимо от характера данных.
> Но заказчики хотят Java, так что будут допинывать.Ну, если заказчик просит веревку и мыло - надо ему их выдать. А если он в них повесится - это уже на его совести.
> Вот у low-latency лагеря те же проблемы
Насколько я помню, MS со своим дотнетом вылетел с LSE в том числе и за неспособность обеспечить обещанные времена задержек. Как зашел вопрос о бабле - они и на си++ софт переписали, и линух поставили. Потому что бабло побеждает зло.
>> А зачем её чистить?
> Чтобы врагам не досталось! Ну там другим процессам, другим юзерам, etc. Не
> айс будет если какой-то хмырь выделит себе блок памяти, а там
> бац - привкей от банка с миллионом лежит! Потому что его
> никто оттуда не снес, вы прикиньте?
>> Вся программа должна быть достаточно надёжной,
> И в рамках криптографии надежность кроме всего прочего подразумевает защиту ключей от
> утечки. Блокирование памяти от доступа другими процессами. Запрет выгрузки в своп.
> Затирание нулями как только ключ более не требуется, etc.Нельзя сказать, что UNIX не подразумевает...
Многие не верят, что кое у кого все программы на отдельных машинах. (при чём виртуальных) :-)
Но вообще OPENSSL_cleanse есть. И иногда используется... Затирает даже не нулями.
> Нельзя сказать, что UNIX не подразумевает...Сами по себе многозадачки общего назначения не страдают в общем случае такой паранойей, т.к. это сильно тормозило бы работу программ.
> Многие не верят, что кое у кого все программы на отдельных машинах.
> (при чём виртуальных) :-)Я верю, концепты типа "1 контейнер = 1 сервис" мне по вкусу. Но это никак не адресует тот факт, что если освобожденный блок памяти явно не протерт ровно в тот момент когда ключ/пароль/etc перестали требоваться - потенциально кто-то другой может его получить. На уровне физики процесса. Оно чисто физически лежит в ячейках RAM, покуда кто-то не запишет туда что-нибудь другое. По этой причине те кто не полный дятел в криптографии - сносят чувствительные данные из памяти и протирают этот регион бесполезными данными сразу как только ценные данные перестали быть нужны.
> Сами по себе многозадачки общего назначения не страдают в общем случае такой
> паранойей, т.к. это сильно тормозило бы работу программ....сказал Микрософт (вслед за кое кем вероятно) и выпустил DOS NIX.
>:-)
> выпустил DOS NIX.Нечто такое называлось DJGPP и было GCC для DOS и даже какие-то либы. Правда я не в курсе насколько там POSIX и стандартные вызовы всяких libc были реализованы :).
> Не
> айс будет если какой-то хмырь выделит себе блок памяти, а там
> бац - привкей от банка с миллионом лежит! Потому что его
> никто оттуда не снес, вы прикиньте?Много уже было украдено до нас...
Предлагаю сразу кремний.. да что там, просто физику во всём обвинять. Какие к нам вопросы, это всё Бор с Эйнштейном, да.
> Предлагаю сразу кремний.. да что там, просто физику во всём обвинять. Какие
> к нам вопросы, это всё Бор с Эйнштейном, да.Ну а что, это процессор во вем виноват! Он программу написанную лабухом выполняет! Вот детектировл бы он IQ автора программы и отказывался бы запускать код от изенов - сразу стало бы безопаснее в два раза.
> ключи из памяти требуется изничтожать предсказуемо, как только они перестали требоваться, затерев явным образомконкретно в этом вы не правы, кажется. Никто не мешает уничтожать. Хочешь - уничтожай.
array[i] = 0
(или какой там синтаксис у джавы, забыл уже.)
* я конкретно про приход gc.
> конкретно в этом вы не правы, кажется. Никто не мешает уничтожать. Хочешь - уничтожай.Жабисты все время уповают что за них рантайм подумает и GC освободит. А с GC и прочим тут еще проблема в том как все это хранится внутри и что на самом деле будет сделано. В сях если мы записываем в array[i]=0, можно быть более-менее уверенным что это будет обращение в память и там это будет реально так (btw, еще и кэш процессора в этой механике может поднасpaть, прецеденты были). А чем сложнее рантайм - тем это менее очевидно и требует куда больше знаний о том как он там внутри это видит, чтобы не прострелить себе пятку совершенно неочевиднейшим образом. Если некто может мониторить обращения в массив и рубать оные, он, очевидно, что-то еще делает, потенциально имея дело с нашими данными. Насколько он там внутри себя параноидально относится к утечкам этих данных - очень отдельный такой вопрос. И я не думаю что типовой жабист вообще имеет хоть какое-то понятие как его жаба с массивами работает. Это делает схему в целом куда менее предсказуемой и стало быть чреватой самыми неожиданными прострелами пяток в самых разнообразных местах. Просто потому что например array[i]=0 не трансформировалось в физическую запись в память по нужному адресу и значение ключа там по факту допустим убито не было. Мало ли чего там мегаумный рантайм оптимизнуть решит, etc. Для этого надо очень хорошо знать как он работает и мониторить его развитие.
Да, тут с вами полностью согласен. Человек просто говорил именно о GC и сборке мусора (имея в виду, видимо, иммутабельные String-и). А между тем проблем куча, но таки они не в том как GC стринги чистит.
> и сборке мусора (имея в виду, видимо, иммутабельные String-и).Я в целом имел в виду мою возможность анализировать поведение получившейся конструкции и понимать что в какой момент времени она делает и является ли фактический результат работы тем чем было задумано в изначальной логики оной, что в криптографии важно. Чем сложнее конструкция, тем сложнее ее анализировать. Поэтому в жабе неизбежно будут кучи багов. И в реализациях SSL. Они просто навороченные до ж...ы. Так что кучи багов там обеспечены, независимо от ЯП. Некоторые баги будут проблемами безопасности. Так что в этом плане мне очень нравится тезис Берштейна: меньше кода - меньше багов. Проблема лишь в том что софт который ничего не умеет - никому и даром не сдался... :)
>> и сборке мусора (имея в виду, видимо, иммутабельные String-и).
> Я в целом имел в виду мою возможность анализировать поведение получившейся конструкции
> и понимать что в какой момент времени она делает и является
> ли фактический результат работы тем чем было задумано в изначальной логики
> оной, что в криптографии важно. Чем сложнее конструкция, тем сложнее ее
> анализировать.Анализу помогают модульные и другие виды тестов. В C/C++ это на зачаточном уровне (лишь недавно во FreeBSD добавили test framework базовой системы, что говорит о печальной ситуации с покрытием тестами и автоматизацией тестирования системного кода!).
> Поэтому в жабе неизбежно будут кучи багов. И в реализациях
> SSL. Они просто навороченные до ж...ы.Микропроцессоры с каждым годом становятся всё сложнее и сложнее, однако старые программы спонтанно не вылетают, хотя по твоей идее о сложности ДОЛЖНЫ!
> Так что кучи багов там обеспечены, независимо от ЯП.
В любой программе, сложнее "Hello World", есть баги.
> Некоторые баги будут проблемами безопасности.
Так в C/C++ они расставлены на уровне ДНК ЯП, а не программиста.
> Так что в этом плане мне очень нравится тезис Берштейна: меньше кода - меньше багов.
Про это ещё Вирт писал, я помню: http://www.osp.ru/os/1996/06/179017/
Оттуда ещё:
///---
Методологии, связанные с языками программирования, до сих пор являются предметом дискуссий. В 1970-х было принято верить, что проектирование программ должно опираться на хорошо структурированные методы и слои абстракции с четко определенными спецификациями. Лучше всего эта мысль выразилась в концепции абстрактного типа данных, которая и нашла свое воплощение в новых тогда языках, прежде всего в Modula-2 и Ada. Сегодня программисты оставляют хорошо структурированные языки и мигрируют, в основном, к Си. Язык Си не позволяет компилятору даже выполнять контроль безопасности типов, а ведь именно эта функция в наибольшей степени полезна при разработке программ для локализации концептуальных ошибок уже на ранней стадии. Без контроля типов само понятие абстракции в языках программирования становится пустым и имеющим чисто академический интерес. Абстракция может работать только в языках, постулирующих строгий статический типовой контроль для каждой переменной и функции. В этом отношении Си несостоятелен и, в сущности, подобен ассемблерному коду, где, правда, "все работает".
Весьма примечательно, что абстрактный тип данных через 25 лет после своего изобретения появился вновь под названием "объектно-ориентированный". По своей сути этот современный концепт (принимаемый многими как панацея) более всего связан с построением иерархий классов или типов. Более старое понятие не было, в сущности, понято, пока не появился новый ярлык "объектно-ориентированный"; теперь же программисты признали присущую абстрактному типу данных мощь и обратились, наконец, к нему. Однако, чтобы об объектно-ориентированных языках можно было говорить всерьез, в них должна быть реализована строгая статическая типизация, которую нельзя было бы нарушить; это дало бы возможность программисту полагаться на компилятор в деле идентификации разного рода несогласованностей. К сожалению, наиболее популярный язык, С++, неудовлетворителен в этом отношении, потому что было изначально декларировано, что он должен быть совместим со своим предком - языком Си. Широкое принятие С++ подтверждает следующие "законы":
* прогресс приемлем, только если он совместим с текущим состоянием;
* приверженность стандарту - всегда безопаснее, чем даже мотивированный отход от него.
Принимая эту ситуацию как данную свыше, программисты вступают в борьбу с языком, который не поощряет структурное мышление и дисциплинированное построение программ, отрицая базовую поддержку компилятора. Они также прибегают к инструментам-паллиативам, которые еще более способствуют разрастанию размеров программ.
---///> Проблема лишь в том что софт который ничего не умеет - никому и даром не сдался... :)
Проблема не в софте, а в программистах, которые ничего не ели слаще пареной репы.
> В любой программе, сложнее "Hello World", есть баги.Когда у человека обе запятые в предложении на предположительно родном языке являются лишними -- как-то страшненько даже думать про то, что он может накодить.
>> В любой программе, сложнее "Hello World", есть баги.
> Когда у человека обе запятые в предложении на предположительно родном языке являются
> лишними -- как-то страшненько даже думать про то, что он может
> накодить.См. придаточные определительные. Союзное слово "которая", которым прикрепляется придаточное определительные к главному предложению, признаюсь, мне лень было писать (думал, не обратят внимание). Однако же на форуме интеллектуального бахвальства всё-таки нашёлся умник, который указал на ошибку пунктуации. :))
>>> В любой программе, сложнее "Hello World", есть баги.
>> Когда у человека обе запятые в предложении на предположительно родном языке
>> являются лишними -- как-то страшненько даже думать про то, что он может
>> накодить.
> См. придаточные определительные.Изя, если человек допускает детские ошибки -- он неграмотен. Если в них упорствует -- он глуп.
Пожалуйста, сходите в школу, проконсультируйтесь у профильного преподавателя и не глупите.
> Изя,Давай я тебя Мичманом буду называть, хорошо?
> если человек допускает детские ошибки -- он неграмотен. Если в них упорствует -- он глуп.
Если человек хочет, но по каким-то причинам не может аргументированно поддеть другого человека, то начинает "танцевать" от замечания в адрес его внешнего вида и манеры общения. Стиль дворовой шпаны (гопников, по-современному), но в ракурсе интеллигенции ("илиты" IT, по-современному).
> Пожалуйста, сходите в школу, проконсультируйтесь у профильного преподавателя и не глупите.
Начни с себя. ;)
>> если человек допускает детские ошибки -- он неграмотен.
>> Если в них упорствует -- он глуп.
> Если человек хочет, но по каким-то причинам не может аргументированно поддетьЕсли "другого человека" не пнул аргументированно только ленивый из как минимум трёх, а то и четырёх местных "лагерей" (ссылки собирать лень, но если так хочется сесть в лужу по полной -- можно), то "поддевать" такого смысла особого нет даже любителям поглумиться.
Изя, пытаться в ответ на вполне конкретный и благожелательный PR (который problem report) объявлять багу фичей -- глупо. Пытаться переспорить человека, который, скажем так, немного лучше понимает в вопросе -- глупо в квадрате.
На сем позвольте откланяться, желаю скорейшего прихода в разум.
>[оверквотинг удален]
>>> Если в них упорствует -- он глуп.
>> Если человек хочет, но по каким-то причинам не может аргументированно поддеть
> Если "другого человека" не пнул аргументированно только ленивый из как минимум трёх,
> а то и четырёх местных "лагерей" (ссылки собирать лень, но если
> так хочется сесть в лужу по полной -- можно), то "поддевать"
> такого смысла особого нет даже любителям поглумиться.
> Изя, пытаться в ответ на вполне конкретный и благожелательный PR (который problem
> report) объявлять багу фичей -- глупо. Пытаться переспорить человека, который,
> скажем так, немного лучше понимает в вопросе -- глупо в квадрате.
> На сем позвольте откланяться, желаю скорейшего прихода в разум.От себя лишь могу выразить сожаление о случившемся. Ты меня очень разочаровал, Миша.
>[оверквотинг удален]
> что-то еще делает, потенциально имея дело с нашими данными. Насколько он
> там внутри себя параноидально относится к утечкам этих данных - очень
> отдельный такой вопрос. И я не думаю что типовой жабист вообще
> имеет хоть какое-то понятие как его жаба с массивами работает. Это
> делает схему в целом куда менее предсказуемой и стало быть чреватой
> самыми неожиданными прострелами пяток в самых разнообразных местах. Просто потому что
> например array[i]=0 не трансформировалось в физическую запись в память по нужному
> адресу и значение ключа там по факту допустим убито не было.
> Мало ли чего там мегаумный рантайм оптимизнуть решит, etc. Для этого
> надо очень хорошо знать как он работает и мониторить его развитие.Ты нам поведал историю о том, что должен делать рядовой программист на C/C++, разрабатывая свою либу. Однако ж, это же самое относится и к программистам JVM, которые должны следовать соглашениям по модели памяти Java. Хорошо, что это не входит в круг решаемых задач прикладных программистов на языках JVM, а то бы они как разработчики OpenSSL/GnuTLS всё время находились между двух огней — небезопасным инструментом разработки и лёгкостью его применения не по назначению. ;)
> это же самое относится и к программистам JVMщито?
>> это же самое относится и к программистам JVM
> щито?JVM написана на C++. OpenJDK7u51 для компиляции JVM нужен GCC 4.6+ (LLVM/Clang не по зубам).
> JVM написана на C++. OpenJDK7u51 для компиляции JVM нужен GCC 4.6+ (LLVM/Clang
> не по зубам).Изя, попробуй поспорить с берштейновским определением проблем безопасности: проблема безопасности - частный случай багов в программе. Всего лишь. Баги можно сажать на любом ЯП. Ну и проблемы безопасности будут на любом ЯП, соответственно.
> щито?Знакомьтесь, это - изен. Жабист. Я чертовски уверен что он не сможет написать безопасную программу ни на каком ЯП вообще.
Кто-нибудь подскажет, ошибка при apt-get update (с https://mirrors.kernel.org/):
GnuTLS recv error (-9): A TLS packet with unexpected length was received.
Из-за исправления этой уязвимости? Как исправляется?
А не, не из-за этой, само исправилось..
> Кто-нибудь подскажет, ошибка при apt-get update (с https://mirrors.kernel.org/):
> GnuTLS recv error (-9): A TLS packet with unexpected length was received.
> Из-за исправления этой уязвимости? Как исправляется?что GNUTLS, что GNUPG - мало того что код, вежливо говоря - написан странно, так еще и бинарники себя чудно ведут. даже версию под оффтопик - не раз ловили за "лазанием не туда", как-бы.
http://istheinternetfixedyet.com/
> могла эксплуатироваться с ноября прошлого годаНе было ни единого разрыва! Не-бы-ло!
http://dlang.ru/211-heartbeat-cve-2014-0160