The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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


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

Оглавление

Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..., opennews (?), 10-Апр-14, (0) [смотреть все]

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


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 Shigorinemail (ok), 12-Апр-14, 23:52 
> В любой программе, сложнее "Hello World", есть баги.

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

212. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."  +/–
Сообщение от iZEN (ok), 13-Апр-14, 20:18 
> Изя,

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

213. "Heartbeat-уязвимость в OpenSSL могла эксплуатироваться с ноя..."  +/–
Сообщение от Michael Shigorinemail (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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру