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

Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..., opennews (?), 10-Апр-14, (0) [смотреть все] А как ругали карточки одноразовых кодов ВТБ-шные, а Как же, каменный век, Java, , rob pike (?), 13:38 , 10-Апр-14, (1) +9 // Карточки одноразовых кодов - это круто А в почту тоже логиниться по карточке од, Аноним (-), 19:16 , 10-Апр-14, (47) –2 // Не стоит передергивать Если когда-нибудь лишитесь 3700 евро со счета, поймете пр, XoRe (ok), 22:26 , 10-Апр-14, (78) // Странно, ворочаю килобаксами килоевро по счетам уже 7 лет Как-то пока все ок д, Аноним (-), 23:17 , 10-Апр-14, (84) –1 Ну если клобаксами, то, полагаю, можете чувствовать себя спокойно, изготовление , rob pike (?), 23:59 , 10-Апр-14, (91) Весьма зависит от симкарты Старые можно дома, на коленке Древняя атака с вычис, Аноним (-), 02:15 , 11-Апр-14, (108) +1 Какие ж вы, гики, предсказуемые Килобакс - это верхняя граничная оценка оформле, rob pike (?), 02:26 , 11-Апр-14, (114) +1 Такие же как и вы Люди вообще достаточно предсказуемы Особенно глупые А тут у , Аноним (-), 02:59 , 11-Апр-14, (117) Да каво, дешевле можно Но сейчас банки палят смену симкарты и не присылают смс н, XoRe (ok), 23:59 , 12-Апр-14, (206) Тю Атаки уровня heartbleed тоже годами не было Анализа уже совершенных транзакц, XoRe (ok), 00:03 , 13-Апр-14, (207) Если такая карточка будет реализована в отдельном чипе того устройства, с которо, rob pike (?), 00:05 , 11-Апр-14, (92) // Сканирование Сетчатки глаза Чипом с проприетарной фирмварой Не-не-не, Дэвид Б, Аноним (-), 02:16 , 11-Апр-14, (109) Как тонка эта грань между паранойей и шизофренией Вы в чипе CCD-камеры не пробов, rob pike (?), 02:36 , 11-Апр-14, (115) –1 Маленький кусочек кремния может нынче содержать много вентилей И реализовывать , Аноним (-), 03:10 , 11-Апр-14, (118) Вы таки не поверите, но http www opennet ru opennews art shtml num 38583http, bugmenot (ok), 05:06 , 11-Апр-14, (124) –1 Это вообще к чему Ну TCP IP Ну по побочному каналу И что , Аноним (-), 10:32 , 11-Апр-14, (135) К тому, что машина, не имеющая доступ к сети, но стоящая в одном помещении с маш, bugmenot (ok), 17:43 , 11-Апр-14, (161) –1 Потенциально, вам завтра на голову может упасть метеорит Ничему не противоречит, Аноним (-), 20:59 , 11-Апр-14, (175) У ноутбуков есть микрофоны И они практически всегда включены , iZEN (ok), 21:17 , 11-Апр-14, (177) –1 Ну а вот у моего десктопа микрофона нет Если ты думал что меня интересует _твоя, Аноним (-), 22:31 , 11-Апр-14, (180) Компьютеры в оффлайне, а сотовый наверняка с андроидом И наверняка подключали е, Аноним (-), 00:08 , 12-Апр-14, (191) это чаще использется для сопоставления данных по мобильным устройствам и ноутам , Аноним (-), 08:29 , 12-Апр-14, (196) Алексей Шипилёв 8212 Прагматика Java Memory Model http www youtube com wat, iZEN (ok), 18:50 , 16-Апр-14, (215) Столько паники из-за капли в океане Про спецслужбы - вообще смешно Они и без т, Аноним (-), 13:46 , 10-Апр-14, (2) –12 // зря ты недооцениваешь спецслужбы об уязвимости они знали и эксплуатировали , Нанобот (ok), 14:55 , 10-Апр-14, (17) +8 // За десятки лет до появления OpenSSL спецслужбы уже написали инструментарий для э, rob pike (?), 15:17 , 10-Апр-14, (20) +4 // irony Были особые люди, которые решили создать спецслужбы для того, что бы они , EuPhobos (ok), 17:24 , 10-Апр-14, (38) В каком-то роде SSL и TLS наархитектили так, что секурно ими пользоваться почти, Аноним (-), 19:30 , 10-Апр-14, (50) И это вы тоже склонны приписать страшным спецслужбам , rob pike (?), 23:38 , 10-Апр-14, (85) Учитывая как NIST-у протолкали несекурный ГПСЧ, не удивлюсь если и протокол стар, Аноним (-), 14:09 , 11-Апр-14, (156) +1 Сказано словно можно создать и уже создано что-то более простое и секьюрное , Аноним (-), 00:24 , 11-Апр-14, (98) Это вы шутите так или действительно видели человека, утверждающего что чего-то б, rob pike (?), 01:33 , 11-Апр-14, (102) Такого человека звали D J Berstein И он таки сделал это - либу NaCl У нее про, Аноним (-), 02:18 , 11-Апр-14, (110) Всё может быть Только тогда это спецслужбы какой-то одной страны с хорошим м, Аноним (-), 19:15 , 10-Апр-14, (46) Да всё протроянено на высшем уровне Вы как вчера родились Как можно доверять се, iZEN (ok), 14:07 , 10-Апр-14, (3) –1 // Это ты сам у себя спрашиваешь , Аноним (-), 19:47 , 10-Апр-14, (54) +2 // У голосов в голове И они отвеча-а-ают , Andrey Mitrofanov (?), 09:44 , 11-Апр-14, (130) +2 Как вы можете пользоваться буржуйским браузером, который запущен во вражеской ОС, XoRe (ok), 22:32 , 10-Апр-14, (79) +1 // Всё просто все заинтересованные в обладании конфиденциальной информации юридиче, iZEN (ok), 22:47 , 10-Апр-14, (82) –2 // Ну это еще вопрос Вон нашим чиновникам после санкций гопстопнули карточки Впро, Аноним (-), 23:41 , 10-Апр-14, (86) Насчет гопстопа У нас на работе несколько человек получали з п на карточки Соби, user (??), 14:04 , 11-Апр-14, (153) –1 И зачем нужна карточка, которой можно пользоваться только в отделении какого-то , Аноним (-), 14:06 , 11-Апр-14, (155) Получайте, разрешаю, user (??), 16:36 , 11-Апр-14, (159) Ну а вы оставьте такие карточки себе, для меня они ничего кроме дополнительного , Аноним (-), 20:55 , 11-Апр-14, (174) Так уж и быть, можете не брать такие карточки , user (??), 23:16 , 11-Апр-14, (189) Все эти механизмы, интерфейсы и протоколы были учтены и разработаны в CCITT при , t28 (?), 12:00 , 12-Апр-14, (200) А в роутерах на WRT прошивке или в серверных IMPI интерфейсах эта библиотека слу, Андрей (??), 14:20 , 10-Апр-14, (4) // Совершенно случайно нет Уязвимостью чревата сама идея TLS Heartbeat На уровне , Sabakwaka (ok), 14:44 , 10-Апр-14, (9) –1 // Расскажите , Аноним (-), 15:40 , 10-Апр-14, (27) –1 // Суть TLS Heartbeat, как следует из драфтаhttp tools ietf org html draft-ietf-t, Sabakwaka (ok), 16:20 , 10-Апр-14, (31) +1 Хотя идея heartbeat довольно дурная сама по себе, сабж тут не виноват В сабже д, Аноним (-), 20:41 , 10-Апр-14, (60) В сабже довольно крутой баг с утеканием памяти в сеть Это не было задумано Это, balda (?), 06:26 , 11-Апр-14, (125) –1 В других либах именно этого бага - нет Зато может быть куча иных, не менее весе, Аноним (-), 10:34 , 11-Апр-14, (136) да не, автор коммента - прав реально убогая идея для решения несуществующей проб, Аноним (-), 04:56 , 12-Апр-14, (193) Для реализации heartbeat достаточно было бы определить пакеты для запроса и отве, Тампарам (?), 17:50 , 11-Апр-14, (162) На OpenWRT какой-то свой шайтан-ssl-сервер писанный на LUA , pavlinux (ok), 14:49 , 10-Апр-14, (12) // Сервер-то свой, а суть всё та же http luci subsignal org trac browser luci tru, rob pike (?), 15:36 , 10-Апр-14, (24) +1 На LUA там написаны скрипты которые морду рисуют Сервер там самопальный, uhttpd, Аноним (-), 20:43 , 10-Апр-14, (61) 1 ATTITUDE ADJUSTMENT 12 09, r36088 root OpenWrt opkg info libopensslPacka, Онаним (?), 16:01 , 10-Апр-14, (29) // У меня единственное место, где живет IPMI настолько древнее, что 1 0 openssl еще, mickvav (?), 16:19 , 10-Апр-14, (30) А при тем тут gnutls В нем какие-то баги есть В openssl баг специфичный для эт, Аноним (-), 20:44 , 10-Апр-14, (62) –1 // Уязвимость оценивается как очень серьёзная и подрывающая доверие к проекту Хов, rob pike (?), 00:07 , 11-Апр-14, (94) А, про это я уже забыл Ну а что, нагородили меганавороченные протоколы с кучей , Аноним (-), 02:22 , 11-Апр-14, (111) Осталось ответить на вопрос почему им никто не пользуется , rob pike (?), 02:40 , 11-Апр-14, (116) Появился относительно недавно И, кстати, кто сказал что им не пользуются В пос, Аноним (-), 03:15 , 11-Апр-14, (119) Эллептические кривые - прямиком из лабораторий АНБ Хрен знает что они там приду, Тампарам (?), 17:51 , 11-Апр-14, (163) –1 У я так смотрю, вы мегамозг Только не спрашивайте как я это узнал Вы пере, Аноним (-), 20:51 , 11-Апр-14, (173) +1 Берштейну или какому-нибудь его помощнику АНБ просто заплатило немножко денег, ч, Тампарам (?), 08:12 , 12-Апр-14, (195) про скандал с обоим закладками от АНБ, проплаченными RDA за миллионы баксов - чи, Аноним (-), 08:33 , 12-Апр-14, (197) ВСЕ 171 системы шифрования 187 уязвимы ПРИНЦИПИАЛЬНО На уровне ДИЗАЙНА, на у, Sabakwaka (ok), 13:26 , 12-Апр-14, (202) Вот видите, совсем не все системы шифрования 187 уязвимы ПРИНЦИПИАЛЬНО Пяти-ш, rob pike (?), 22:26 , 12-Апр-14, (204) Эллиптические кривые - прямиком из оснований математики, вообще-то , Sabakwaka (ok), 13:17 , 12-Апр-14, (201) –1 Там по дефолту ничего SSLного в сеть не торчит вроде Но если торчит - да, заапд, Аноним (-), 14:05 , 11-Апр-14, (154) gmail, fb и vk попали под раздачу , MPEG LA (ok), 14:25 , 10-Апр-14, (5) // Вполне вероятно Более того - баг вывешивает память процесса в сеть, так что даж, Аноним (-), 20:47 , 10-Апр-14, (63) // Шнайер облегчает наши сомнения 11 из 10 баллов , Andrey Mitrofanov (?), 09:47 , 11-Апр-14, (131) +1 баг специально внесли из-за коммерческой выгоды, все попёрли менять ssl сертифик, Sw00p aka Jerom (?), 14:36 , 10-Апр-14, (6) –1 // Да ну , Sabakwaka (ok), 14:44 , 10-Апр-14, (10) +1 попёрли менять сертификаты только истерички, паникёры и лохи, которые начитались, Нанобот (ok), 14:46 , 10-Апр-14, (11) –10 // Для истеричек, паникёров и лохов ниже показал скриншот, с реально рабочего , pavlinux (ok), 15:25 , 10-Апр-14, (22) +1 которые не хотят сливать свои пароли и приватные ключи всему миру Только вот, Аноним (-), 20:48 , 10-Апр-14, (65) я бесплатно перевыпустил свои сертификаты причем сроки сертификатов остались ст, serverX (??), 14:54 , 10-Апр-14, (16) // Старые-то заэкспайрить не забыли , Тампарам (?), 08:10 , 12-Апр-14, (194) Redmine тоже дырявый http i59 fastpic ru big 2014 0410 2e 9fd0122735fb7d475ab, pavlinux (ok), 14:36 , 10-Апр-14, (7) –1 // Как данный скриншот указывает на дырявость Redmine , Xaionaro (ok), 14:57 , 10-Апр-14, (18) –1 // Cookie _redmine_session и далее по тексту assword v_pupkin login Login vasya, pavlinux (ok), 15:01 , 10-Апр-14, (19) –1 // Но это не значит, что его надо так запускать Вообще, веб сервер на Ruby - не сам, XoRe (ok), 22:35 , 10-Апр-14, (80) А причём тут дырявость redmine-е, если данные получены через уязвимость libssl, Xaionaro (ok), 08:25 , 11-Апр-14, (128) +1 При том что пароль в открытом виде фигачат, полагаясь на защиту соединения , ко, Аноним (-), 10:37 , 11-Апр-14, (138) А другие Web ITS как работают , Xaionaro (ok), 22:01 , 11-Апр-14, (178) –1 Так же как и все остальное от веб хомячья, разумеется Т к дыра на дыре и дырой, Аноним (-), 22:34 , 11-Апр-14, (181) Ну, получается, что 95 сайтов с поддержкой аутентификации включая www opennet, Xaionaro (ok), 00:19 , 12-Апр-14, (192) А потом все удивлялись, откуда такой ажиотаж вокруг сноудена, все же знали, что , anonymus (?), 15:31 , 10-Апр-14, (23) +5 // мало того, некоторым и выступлений Сноудена недостаточно, Аноним (-), 17:58 , 10-Апр-14, (41) +1 Ну что ты как маленький, скрипткидизы думали что мегалиба сделает им зашибись П, Аноним (-), 20:50 , 10-Апр-14, (66) +1 А Столман давно говорит, что надо делать , Аноним (-), 15:20 , 10-Апр-14, (21) +1 // Ну дык Использовать девайсы где исходники прошивки есть , Аноним (-), 03:15 , 11-Апр-14, (120) Писали открытый ССЛь, скопипастили проприетарный код не глядя , Ansomgsom (?), 15:40 , 10-Апр-14, (26) –1 причем наверняка АНБ , Аноним (-), 16:32 , 10-Апр-14, (32) // Как будто список спецслужб мира состоит из одного АНБ Все они одним миром мазан, anonymous (??), 17:43 , 10-Апр-14, (39) // может и не АНБ, но американская точно, Аноним (-), 18:00 , 10-Апр-14, (42) // Вы про русские спецслужбы вообще слышали Нет А ведь они есть А ведь это наши , Аноним (-), 19:20 , 10-Апр-14, (48) +4 Да, наши занимают первые места в олимпиадах А потом они работают в их интелах, , Аноним (-), 21:54 , 10-Апр-14, (74) +1 ха, я был прав http lenta ru news 2014 04 12 heartbleed , Аноним (-), 09:09 , 12-Апр-14, (198) Ловим гадов через iptables code iptables -I INPUT -p tcp -m string --algo kmp , Аноним (-), 16:37 , 10-Апр-14, (33) // Действительно, detected залоггил и забил Ну а дропать пакет кто будет, Пушкин , Аноним (-), 20:51 , 10-Апр-14, (67) +2 // и вместо 40 00 может быть нечто другое , Аноним (-), 21:15 , 10-Апр-14, (69) // Я знаю Зато запись в логе понтовую - нарисовал Вот как-то так скрипткидисы и д, Аноним (-), 21:53 , 10-Апр-14, (73) И детектировать как string ну в общем, намного более нормальный рецепт написа, Аноним (-), 21:56 , 10-Апр-14, (75) То чудное правило, банит всех подряд кто пытается установить соединение с heatbe, pavlinux (ok), 12:30 , 11-Апр-14, (150) Появились сведения http techrights org 2014 04 08 howard-schmidt-codenomicon , Аноним (-), 16:37 , 10-Апр-14, (34) +5 // Ну чо, спасибо посанам из маздайсофта, спалили бэкдор Дайте иcчо А под De, pavlinux (ok), 16:40 , 10-Апр-14, (35) +1 всё может быть, Аноним (-), 18:02 , 10-Апр-14, (43) –1 И шо они скажут В Windows Next самое неуязвимое шифрование Кто им поверит , Аноним (-), 19:54 , 10-Апр-14, (55) типа не переходите c XP на сторонние nix-системы, там все плохо, вот например д, некто (ok), 22:03 , 10-Апр-14, (76) // http www securitylab ru vulnerability 449697 phpдыра во всех виндах с 2001 год, Волкот (?), 22:36 , 10-Апр-14, (81) Оффтоп - а почему IE не может пройти авторизацию, если пароль передается в виде , Адекват (ok), 08:15 , 11-Апр-14, (126) // Возьми снифер да посмотри что там передается по факту Может он digest авторизац, Аноним (-), 10:40 , 11-Апр-14, (139) а какое отношение имеет openssl к линуксу как таковому , ALex_hha (ok), 23:48 , 10-Апр-14, (89) // А никакого Чуть погодя юзеры виндов узнают сколько софта юзало статически влинк, Аноним (-), 03:17 , 11-Апр-14, (121) // Ну, за здоровье IIS Не чокаясь , Andrey Mitrofanov (?), 09:51 , 11-Апр-14, (132) Ага, здоровый зомбяк Все время из могилы вылезает, зараза , Аноним (-), 10:40 , 11-Апр-14, (140) Спонсер-вурдалак-некромансер бдит и собирает opennet ru openforum vsluhforumID3 , Andrey Mitrofanov (?), 10:49 , 11-Апр-14, (142) fixed И апачует Что-то нет там ничего, видимо потерли , Аноним (-), 17:31 , 11-Апр-14, (160) У них там в загашниках типа еще есть гостинцы , некто (ok), 16:47 , 10-Апр-14, (36) вангую появление новой библиотеки, axe (??), 16:56 , 10-Апр-14, (37) // Попроси вангователь у анонима сверху NaCl уже есть , anonymous (??), 17:44 , 10-Апр-14, (40) // а PoCl и NeСl будут , pavlinux (ok), 18:21 , 10-Апр-14, (44) –2 // Не, не так KCl и Na OH 2, Аноним (-), 19:23 , 10-Апр-14, (49) +1 Выделил оценку по неорганике, если что , Michael Shigorin (ok), 19:37 , 10-Апр-14, (52) +8 Извиняюсь, перепутал валентность металлов Если так напишу Na OH 2-Ион сойдёт за , Аноним (-), 00:06 , 11-Апр-14, (93) +1 А что за ион такой странный NaOH диссоциирует на Na и OH- А это что за хрень , Аноним (-), 02:24 , 11-Апр-14, (112) +1 Теоретически возможный в какой-либо момент времени Разумеется, сразу распадётся, Аноним (-), 08:53 , 11-Апр-14, (129) полимеры Na NN OH MM тоже по броску кости могут образовываться , Andrey Mitrofanov (?), 09:53 , 11-Апр-14, (133) Если и будут, то будет PoCl на всех 3х, ибо NeCl, Аноним (-), 20:38 , 10-Апр-14, (58) Да, удачи вам заставить неон провзаимодействовать с хлором , Аноним (-), 02:25 , 11-Апр-14, (113) При помощи кувалды и такой-то матери , Адекват (ok), 08:16 , 11-Апр-14, (127) Сдается мне, тут даже термоядерная кувалда может спасовать , Аноним (-), 10:45 , 11-Апр-14, (141) Вдуваешь в баллон 50 неона, 50 хлора, взбалтываешь Опа , pavlinux (ok), 12:24 , 11-Апр-14, (149) Расслаивается и продолжает болтаться себе Неон вообще-то инертен , Michael Shigorin (ok), 12:49 , 11-Апр-14, (151) Надо было добавить, Взболтать перед употреблением Ну это его проблемы, взболтат, pavlinux (ok), 13:17 , 11-Апр-14, (152) Ну вот в сабже не добавили, видишь чего получилось , Аноним (-), 22:37 , 11-Апр-14, (182) давно пора разнообразие, хотя на примере ffmpeg libav особенного прогресса не на, некто (ok), 18:28 , 10-Апр-14, (45) // Да и ядро ОС неплохо бы, основанное не на идеях 50-летней давности А множатся чт, rob pike (?), 23:42 , 10-Апр-14, (87) // А зачем чинить то что не сломано А электродвигатели и трансформаторы работают у, Аноним (-), 00:25 , 11-Апр-14, (99) Точно не сломано Что ж тогда всё чинят и чинят, и всё костылями да костылями, о, rob pike (?), 01:31 , 11-Апр-14, (101) А это потому что симпатичные дизайны хорошо смотрятся как демонстрационная модел, Аноним (-), 01:59 , 11-Апр-14, (104) Я всегда знал, что даже на Tor полностью надеяться нельзя , Аноним (-), 19:34 , 10-Апр-14, (51) –1 // В области распространения германских языков Тору посвящён день недели 8212 че, anonymous (??), 01:49 , 11-Апр-14, (103) –2 В конструкции сети Tor есть минимум 2 серьезных упущения, вообще никак не связан, Аноним (-), 11:07 , 11-Апр-14, (143) учитывая кем и для чего был разработан Тор, ваша ремарка - может лишь улыбку, вы, Аноним (-), 08:07 , 13-Апр-14, (210) Это вопрос не другой , это вопрос самый главный , Аноним (-), 19:42 , 10-Апр-14, (53) Да, такого фейла ещё не было наверное в истории IT А некоторые люди ещё и отказ, lucentcode (ok), 20:23 , 10-Апр-14, (56) +1 // Debian oldstable спасает , Oinari (ok), 20:47 , 10-Апр-14, (64) // Совсем не включать компьютер - надежнее , Аноним (-), 21:51 , 10-Апр-14, (72) Не пользуйтесь такими серверами Проипут они ваши данные и логины с паролями , Аноним (-), 20:26 , 11-Апр-14, (172) C C всё погубил , iZEN (ok), 20:24 , 10-Апр-14, (57) –2   // Но жабка мало чего годного из либ родила, Аноним (-), 20:40 , 10-Апр-14, (59)   Остальные облажались бы еще раньше, ибо GC и тому подобные - криптографии не дру, Аноним (-), 20:55 , 10-Апр-14, (68) +2   // Java написана на C C , поэтому в ней полно дыр Очевидно и логично , iZEN (ok), 21:25 , 10-Апр-14, (70) –2   // Логика жабиста во всем виноваты нет, не программисты Си и плюсы во всем ви, Аноним (-), 21:49 , 10-Апр-14, (71)   Потому что ЯП C C допускают использование памяти небезопасным способом даже из, iZEN (ok), 22:06 , 10-Апр-14, (77) –2   Не де Билл ли - , Anonym2 (?), 23:52 , 10-Апр-14, (90)   У криптографов свои, очень кастомные понятия отом что такое безопасность , чува, Аноним (-), 00:15 , 11-Апр-14, (95) +2   Ругаетесь вы клёво, но всё-таки выход за рамки массива -- это таки то что хочетс, vn971 (ok), 12:07 , 11-Апр-14, (148)   По конкретно этому пункту - я даже согласен до некоторой степени И сдается мне , Аноним (-), 18:46 , 11-Апр-14, (165)   Это хорошая и приятная теорема, да Но она на самом деле немного о другом Теоре, vn971 (ok), 20:21 , 11-Апр-14, (170)   Во первых, если посмотреть на реальный мир, то у нас дофига программ Во вторых,, Аноним (-), 22:56 , 11-Апр-14, (183)   Ээээ, я просто объяснял что значит компьютерно-верифицированная программа И, кс, vn971 (ok), 23:03 , 11-Апр-14, (185)   А зачем её чистить Вся программа должна быть достаточно надёжной, в составе кот, Anonym2 (?), 22:53 , 10-Апр-14, (83) –2   Чтобы врагам не досталось Ну там другим процессам, другим юзерам, etc Не айс б, Аноним (-), 00:21 , 11-Апр-14, (96) +1   Но заказчики хотят Java, так что будут допинывать Вот у low-latency лагеря те же, rob pike (?), 01:23 , 11-Апр-14, (100)   А в real-time мире так и к С больше вопросов чем ответов http www embedded c, rob pike (?), 02:04 , 11-Апр-14, (105)   Меньше чем к яве А так то да - чем проще некая конструкция, тем она предсказуем, Аноним (-), 02:10 , 11-Апр-14, (107)   Ну, если заказчик просит веревку и мыло - надо ему их выдать А если он в них по, Аноним (-), 02:04 , 11-Апр-14, (106)   Нельзя сказать, что UNIX не подразумевает Многие не верят, что кое у кого все , Anonym2 (?), 04:07 , 11-Апр-14, (122)   Сами по себе многозадачки общего назначения не страдают в общем случае такой пар, Аноним (-), 19:08 , 11-Апр-14, (166)   сказал Микрософт вслед за кое кем вероятно и выпустил DOS NIX , Anonym2 (?), 20:00 , 11-Апр-14, (167)   Нечто такое называлось DJGPP и было GCC для DOS и даже какие-то либы Правда я н, Аноним (-), 20:15 , 11-Апр-14, (169)   Много уже было украдено до нас , Anonym2 (?), 04:36 , 11-Апр-14, (123)   Предлагаю сразу кремний да что там, просто физику во всём обвинять Какие к на, rob pike (?), 23:46 , 10-Апр-14, (88)   Ну а что, это процессор во вем виноват Он программу написанную лабухом выполняе, Аноним (-), 00:22 , 11-Апр-14, (97) +1   конкретно в этом вы не правы, кажется Никто не мешает уничтожать Хочешь - унич, vn971 (ok), 11:54 , 11-Апр-14, (146)   // я конкретно про приход gc , vn971 (ok), 11:59 , 11-Апр-14, (147)   Жабисты все время уповают что за них рантайм подумает и GC освободит А с GC и п, Аноним (-), 20:09 , 11-Апр-14, (168)   Да, тут с вами полностью согласен Человек просто говорил именно о GC и сборке м, vn971 (ok), 20:25 , 11-Апр-14, (171)   Я в целом имел в виду мою возможность анализировать поведение получившейся конст, Аноним (-), 23:09 , 11-Апр-14, (186)   Анализу помогают модульные и другие виды тестов В C C это на зачаточном уровн, iZEN (ok), 23:43 , 11-Апр-14, (190)   Когда у человека обе запятые в предложении на предположительно родном языке явля, Michael Shigorin (ok), 23:52 , 12-Апр-14, (205)   См придаточные определительные Союзное слово которая , которым прикрепляется , iZEN (ok), 00:27 , 13-Апр-14, (208)   Изя, если человек допускает детские ошибки -- он неграмотен Если в них упорств, Michael Shigorin (ok), 01:03 , 13-Апр-14, (209)   Давай я тебя Мичманом буду называть, хорошо Если человек хочет, но по каким-то п, iZEN (ok), 20:18 , 13-Апр-14, (212)   Если другого человека не пнул аргументированно только ленивый из как минимум т, Michael Shigorin (ok), 21:34 , 13-Апр-14, (213)   gt оверквотинг удален От себя лишь могу выразить сожаление о случившемся Ты м, iZEN (ok), 21:44 , 13-Апр-14, (214)   gt оверквотинг удален Ты нам поведал историю о том, что должен делать рядовой , iZEN (ok), 21:14 , 11-Апр-14, (176) –1   щито , vn971 (ok), 22:10 , 11-Апр-14, (179)   JVM написана на C OpenJDK7u51 для компиляции JVM нужен GCC 4 6 LLVM Clang н, iZEN (ok), 23:00 , 11-Апр-14, (184) –1   Изя, попробуй поспорить с берштейновским определением проблем безопасности проб, Аноним (-), 23:10 , 11-Апр-14, (187)   Знакомьтесь, это - изен Жабист Я чертовски уверен что он не сможет написать бе, Аноним (-), 23:11 , 11-Апр-14, (188)   Кто-нибудь подскажет, ошибка при apt-get update с https mirrors kernel org , Аноним (-), 15:10 , 11-Апр-14, (157) // А не, не из-за этой, само исправилось , Аноним (-), 15:26 , 11-Апр-14, (158) что GNUTLS, что GNUPG - мало того что код, вежливо говоря - написан странно, так, Аноним (-), 08:14 , 13-Апр-14, (211) http istheinternetfixedyet com , V (??), 17:58 , 11-Апр-14, (164) Не было ни единого разрыва Не-бы-ло , t28 (?), 11:27 , 12-Апр-14, (199) +1 http dlang ru 211-heartbeat-cve-2014-0160, Аноним (-), 14:35 , 12-Апр-14, (203) 1,2,3,4,5,6,7,21,26,32,33,34,36,37,51,53,56,57,157,164,199,203

Сообщения

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

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

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

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

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

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

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

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

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

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

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

	183. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."	+/–
	Сообщение от Аноним (-), 11-Апр-14, 22:56
	> любой другой скажет остановится ли она. Но у нас _одна_ программа > анализ которой нужно сделать. Во первых, если посмотреть на реальный мир, то у нас дофига программ. Во вторых, они еще и разные версии постоянно выпускают. Так что это как раз сильно ближе к случаю анализа произвольных программ. А какую практическую ценность несет анализ одной прибитой гвоздями версии одной программы? Во вторых, простая логика подсказывает мне что у мало-мальски больших программ возможно такое большое число состояний, что анализ всех возможных вариантов работы программы займет столько, что рак на горе свистеть устанет, солнце превратится в красный карлик, ну и вообще, когда оно закончится - все это будет уже накому и даром не надо, так что радости то. > В общем, я имею в виду вот эту технологию: > https://en.wikipedia.org/wiki/L4_microkernel_family Ну понятно, очередной академик натирающий мозоли на микроядра. > (Current research and development) Посмотрите, это может быть интересно.:) Я уже забыл сколько лет я слышу эту фразу от любителей микроядер. Уже были minix и hurd, etc. У них всех было кое-что общее: они нафиг никому не уперлись на обычных серверах, десктопах и прочем. Знаете, называя вещи своими именами, я тоже могу написать простой тасквичер без багов. Ну это так, если идею микроядра довести до абсолюта. А на баги в остальных компонентах системы сделать козью морду - мол, не мои баги, "это все они". Правда вот поскольку оборудование, протоколы и софт проще не стали - нет никакого основания ожидать что багов станет меньше. И вообще, не очень понятно как микроядро может помочь в случае лажи в криптографической либе и софте который ей пользовался. Оно конечно замечательно - сватать таблетки от кашля при головной боли. Но эффективность этого метода подвергается сомнениям. > provides a guarantee that the kernel is free of implementation bugs such as deadlocks, > livelocks, buffer overflows, arithmetic exceptions or use of uninitialised variables. Да я тоже простейший тасксвичер напишу без багов. А кому он будет нужен? В общем то единственная проблема с микроядрами: там просто сложные вещи перепихнуты на чуть другие головы, поэтому те кто писал "тасксвичер" могут встать в позу Д'Артаньяна и гордо заявить что у них багов нет. Это вполне может быть правдой, в силу того что само микроядро мелкое. К сожалению это означает лишь то что сложные моменты перепихнули в иные компоненты. И, заметим, про их верификацию все технично молчат в тряпочку. Поэтому секурным оно будет в тепличных условиях, у академиков в лаборатории, где одно лысое ядро которое ничего не делает. А сделай из этого десктопник, с навороченными драйверами и софтом - и будет все как обычно.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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