AVK Selected
Показавшиеся интересными, на мой вкус, посты
И снова к вопросу о защищенности открытого кода
09.01.2014
|
kochetkov.vladimir
 |
Один весьма известный и уважаемый в узких кругах исследователь взял на себя труд глянуть по диагонали отдельные части реализации иксов и подготовить об этом презенташку для очередной конференции по новым компьютерным технологиям и защите компьютерных программ: http://media.ccc.de/browse/congress/2013/30C3_-_5499_-_en_-_saal_1_-_201312291830_-_x_security_-_ilja_van_sprundel.html
Для тех, кому лень смотреть и делать выводы... Пара цитат из презентации:
и
речь о 120 security багах, если кто не понял. После такой внезапности, xorg-разрабы решили (видимо впервые за все время существования проекта) просканить свой код хоть каким-нибудь статанализатором. Им под руку попался http://cppcheck.sourceforge.net/ , который не менее внезапно наанализировал security баг (переполнение буфера) 23-х летней (!!!) давности: http://lists.x.org/archives/xorg-announce/2014-January/002389.html . Сколько там еще подобных скелетов, не поддающихся статанализу в силу объективных причин и до которых еще не дошли руки у Ильи — остается только гадать
Для тех, кому лень смотреть и делать выводы... Пара цитат из презентации:
"GLX is a horrible demotivator! 80,000 lines of sheer terror."
и
"In the past
couple of months I've found 120 bugs there, and I'm not close to done."
речь о 120 security багах, если кто не понял. После такой внезапности, xorg-разрабы решили (видимо впервые за все время существования проекта) просканить свой код хоть каким-нибудь статанализатором. Им под руку попался http://cppcheck.sourceforge.net/ , который не менее внезапно наанализировал security баг (переполнение буфера) 23-х летней (!!!) давности: http://lists.x.org/archives/xorg-announce/2014-January/002389.html . Сколько там еще подобных скелетов, не поддающихся статанализу в силу объективных причин и до которых еще не дошли руки у Ильи — остается только гадать
... << RSDN@Home 1.2.0 alpha 5 rev. 75>>
| 09.01.2014 118 комментариев |
S>
Есть небольшой, но шанс, что ты сам сможешь спросить это у него на PHDays IV в мае
KV>Есть небольшой, но шанс, что ты сам сможешь спросить это у него на PHDays IV в мае
Вот так ненавязчиво Владимир начал рекламную кампанию очередных PHDays
KV>Один весьма известный и уважаемый в узких кругах исследователь
KV>речь о 120 security багах, если кто не понял.
А сказать-то ты что хотел?
А так понимаю ты о том, что если бы это был закрытый код его бы никто и не анализировал бы и баги не правил?
V>А сказать-то ты что хотел?
V>А так понимаю ты о том, что если бы это был закрытый код его бы никто и не анализировал бы и баги не правил?
Сорри, забыл сразу пояснить в теме: это дополнение к контексту обсуждения тут К спору о закрытом ПО (в частности, к этому сообщению: Re[9]: К спору о закрытом ПО).
KV>Сорри, забыл сразу пояснить в теме: это дополнение к контексту обсуждения тут К спору о закрытом ПО (в частности, к этому сообщению: Re[9]: К спору о закрытом ПО).
Я не склонен вычитывать тонны бреда в поисках крупинок разумных высказываний. Так что, при открытии темы мог изложить тезисно свои мысли, чтобы было понятно, что ты имеешь в виду и имеешь ли что в виду.
V>Я не склонен вычитывать тонны бреда в поисках крупинок разумных высказываний.
Думаю, что будет справедливее, если это доставит неудобства тебе, а не мне. Не находишь?
V>Так что, при открытии темы мог изложить тезисно свои мысли, чтобы было понятно, что ты имеешь в виду и имеешь ли что в виду.
Я не склонен копипастить то, что уже написал ранее. Ссылки на мое сообщение было более чем достаточно, на мой скромный взгляд.
KV>Думаю, что будет справедливее, если это доставит неудобства тебе, а не мне. Не находишь?
При чем тут справедливость? Бред какой-то нечсешь.
Ты постишь тему, что тебе интересна и логично предположить, что ожидаешь некие отклики ну и также логично предположить, что для откликов нужно изложить свои тезисы относительно темы.
Но возможно с логичностью в твоем случае я ошибаюсь, так что извини, больше не буду про логику упоминать.
Видишь ли, твое мнение (как обо мне, так и о данной теме) не представляет для меня ни малейшего интереса. И, судя по десятку-другому из твоих последних постов, пробудить его ты абсолютно неспособен, как в силу своего воспитания, так и в силу уровня осведомленности в тех предметных областях, которые мне интересны.
Надеюсь, с другими участниками форумов тебе повезет больше
KV>Видишь ли, твое мнение (как обо мне, так и о данной теме) не представляет для меня ни малейшего интереса. И, судя по десятку-другому из твоих последних постов, пробудить его ты абсолютно неспособен, как в силу своего воспитания, так и в силу уровня осведомленности в тех предметных областях, которые мне интересны.
Да не, я всего-лишь послушать умных людей хотел, а оказалось, как всегда.
KV>Видишь ли, твое мнение (как обо мне, так и о данной теме) не представляет для меня ни малейшего интереса. И, судя по десятку-другому из твоих последних постов, пробудить его ты абсолютно неспособен, как в силу своего воспитания, так и в силу уровня осведомленности в тех предметных областях, которые мне интересны.
Ога, целых три или четыре сообщения что бы объяснить, что тебя не интересует мнение Вжика
Сообщение, очевидно, оформлено чисто ради флейма, самый минимум информации, и дальше разные намёки, так бы сразу и сказал, тем более что это КСВ.
Я например в закрытом коде крупной американской конторый, чьими продуктами пользуется прямо или косвенно примерно 80% американцев, за один день нашел 40 багов, когда хотел пофиксить всего один небольшой бажок. Все из багов крайне критичны как для бизнеса, так и для конечных потребителей. Все баги были найдены в отрезке кода примерно в 10 тыс строк.
Итого — couple of months vs один день, 80К строк vs 10К строк мягко говоря не в пользу glx
P.S. "прямо или косвенно" означает следующее — считаешь деньги сам или считают деньги для тебя. Другие варианты, типа "считают деньги для тех кто считает деньги для тебя" даже не рассматриваются, а то будет 100%.
KV>>Один весьма известный и уважаемый в узких кругах исследователь
KV>>речь о 120 security багах, если кто не понял.
V>А сказать-то ты что хотел?
V>А так понимаю ты о том, что если бы это был закрытый код его бы никто и не анализировал бы и баги не правил?
Закрытый код обычно тестирует целая бригада тестировщиков. У них работа такая — гонять тесты, пускать анализаторы. Багфиксом же занимаются девелоперы на постоянной основе. Здесь можно четко разделять разработку на фазы, межу которыми регрессионные тесты и определенный багфикс.
С опенсорсом такой подход смысла не имеет, потому что орава майнтейнеров не управляется.
I>Закрытый код обычно тестирует целая бригада тестировщиков. У них работа такая — гонять тесты, пускать анализаторы. Багфиксом же занимаются девелоперы на постоянной основе. Здесь можно четко разделять разработку на фазы, межу которыми регрессионные тесты и определенный багфикс.
Обычно считается что тестирует. Но вот в реальности часто там тестирования 0. А так как код закрытый, то проверить мы ничего не можем, только верить продажникам той фирмы.
То бишь в теории все хорошо, а на практике все плохо.
С открытым кодом все проще, ты сам можешь посмотреть и проверить его. Но это потребует и тебя затрат времени и денег. Но ты сам уже принимаешь решение верить или проверить.
В случае закрытого варианта проверить у тебя нет.
V>С открытым кодом все проще, ты сам можешь посмотреть и проверить его. Но это потребует и тебя затрат времени и денег. Но ты сам уже принимаешь решение верить или проверить.
V>В случае закрытого варианта проверить у тебя нет.
Это условно. Тескейсы надо подготовить, прогнать — это вагон времени даже для простецкой UI аппликачки. Если это сетевая или клиент-серверная аппликачка, то сам уже ничего не сделаешь.
I>Это условно. Тескейсы надо подготовить, прогнать — это вагон времени даже для простецкой UI аппликачки.
Да. Только в одном случае ты имеешь выбор, а в другом нет.
Ну и еще нюанс, открытый код любят смотреть разные люди, как в примере ТС и постить свое мнение о нем. А с закрытым это невозможно.
V>С открытым кодом все проще, ты сам можешь посмотреть и проверить его. Но это потребует и тебя затрат времени и денег. Но ты сам уже принимаешь решение верить или проверить.
Как следует оттестировать код — по затратам сравнимо с разработкой с нуля, а для говнокода — обойдется даже дороже разработки.
S>Как следует оттестировать код — по затратам сравнимо с разработкой с нуля, а для говнокода — обойдется даже дороже разработки.
Вообще говоря дешевле, но не суть важно.
В случае открытого кода ты видишь говнокод это или нет, а в случае закрытого ничего сказать не можешь и вынужден верить продажникам той конторы. А продажники это самые честные люди и они честно тебе все покажут и расскажут, какое говно их продукт.
V>В случае открытого кода ты видишь говнокод это или нет, а в случае закрытого ничего сказать не можешь и вынужден верить продажникам той конторы. А продажники это самые честные люди и они честно тебе все покажут и расскажут, какое говно их продукт.
Ну вот в X-сервере говнокод. И чо? Как будто у тебя есть выбор.
S>Ну вот в X-сервере говнокод. И чо? Как будто у тебя есть выбор.
Как бы есть вот http://en.wikipedia.org/wiki/Display_server, плюс Windows, плюс Мас. Наверное еще что-то есть, я не в курсе.
Если меня волнует некая проблема в Иксах, то я могу выбрать из списка выше где сей проблемы нет.
V>То бишь в теории все хорошо, а на практике все плохо.
Ваша неправда. Где/когда есть стимул (денежный, юридический) блюсти качество — оно соблюдается, ого-го как!
I>Закрытый код обычно тестирует целая бригада тестировщиков. У них работа такая — гонять тесты, пускать анализаторы. Багфиксом же занимаются девелоперы на постоянной основе. Здесь можно четко разделять разработку на фазы, межу которыми регрессионные тесты и определенный багфикс.
I>С опенсорсом такой подход смысла не имеет, потому что орава майнтейнеров не управляется.
Открытость/закрытость кода и зрелость процесса разработки вещи слабо коррелирующие.
Кроме того, не надо забывать, что много Open Source'а — это вполне себе коммерческие проекты и основная команда разработчиков там точно такие же наемные работники.
I>Закрытый код обычно тестирует целая бригада тестировщиков.
ROTFL!
Ну Xorg это вообще вещь в себе. Свой вариант make'а. Структура такая, что собрать его из исходников сложнее, чем собрать Linux from Scratch. Куча унаследованного добра со времен МИТовских разработок 70-ых и прочее.
DOO>Здравствуйте, kochetkov.vladimir, Вы писали:
DOO>Ну Xorg это вообще вещь в себе. Свой вариант make'а. Структура такая, что собрать его из исходников сложнее, чем собрать Linux from Scratch. Куча унаследованного добра со времен МИТовских разработок 70-ых и прочее.
Абсолютно верно. Помнится я его собирал еще до кромсания на подпроекты с выносом этих подпроектов в отдельные пакеты. Ад и холокост. Отдельного упоминания заслуживает то, как ко мне попали этисамые исходники. Тогда трафик был поголовно платный, а adsl до домашнего использоания у меня в регионе еще не дошол. Если мне не изменила память, исходники весили чтото около 70 Мб, на модеме с нестабильными 24к скачать это было почти нереально. Но руки чесались. В итоге получилось договориться с админом одного из провайдеров, он скачал мне сии сорцы, соорудив dns-тунель, причем это емуаукнулось через месяц, когда ктото заинтересовался скачком потребления. Впрочем обошлось все строгим взглядом.
А потом, когда на пакеты разбили, все стало на порядки проще.
S>Здравствуйте, DOOM, Вы писали:
DOO>>Здравствуйте, kochetkov.vladimir, Вы писали:
DOO>>Ну Xorg это вообще вещь в себе. Свой вариант make'а. Структура такая, что собрать его из исходников сложнее, чем собрать Linux from Scratch. Куча унаследованного добра со времен МИТовских разработок 70-ых и прочее.
S>Абсолютно верно. Помнится я его собирал еще до кромсания на подпроекты с выносом этих подпроектов в отдельные пакеты. Ад и холокост. Отдельного упоминания заслуживает то, как ко мне попали этисамые исходники. Тогда трафик был поголовно платный, а adsl до домашнего использоания у меня в регионе еще не дошол. Если мне не изменила память, исходники весили чтото около 70 Мб, на модеме с нестабильными 24к скачать это было почти нереально. Но руки чесались. В итоге получилось договориться с админом одного из провайдеров, он скачал мне сии сорцы, соорудив dns-тунель, причем это емуаукнулось через месяц, когда ктото заинтересовался скачком потребления. Впрочем обошлось все строгим взглядом.
S>А потом, когда на пакеты разбили, все стало на порядки проще.
Лично я с 2006 года не испытывал каких-то проблем со сборкой xorg-6.9-7.x из портов (с исходниками) во FreeBSD. Поначалу дистфайлы (исходники) скачивал по диалапу, потом появился ADSL...
Xorg 6.x был монолитным и компактным в отличие от модульного Xorg 7.x. Монолит собирался гораздо быстрее. Ад начался, когда его начали разделять на так называемые "модули". С тех пор пользуюсь xorg-minimal.
ZEN>
ZEN>Лично я с 2006 года не испытывал каких-то проблем со сборкой xorg-6.9-7.x из портов (с исходниками) во FreeBSD. Поначалу дистфайлы (исходники) скачивал по диалапу, потом появился ADSL...
Из портов. Угу. Фигли там разбираться, все уже готово. А вот когда без портов, имея на руках только исходники — это реальный ад был. Слава бг, что свой компилятор умудрились не написать...
ZEN>Xorg 6.x был монолитным и компактным в отличие от модульного Xorg 7.x. Монолит собирался гораздо быстрее. Ад начался, когда его начали разделять на так называемые "модули". С тех пор пользуюсь xorg-minimal.
После монолита, с модульным ксоргом я разобрался в один глоток, хотя приготовил заранее два литра. Ибо уже был обычный конфигуре с обычным мэйком и вполне просматриваемыми невооруженным взглядом зависимостями.
Повторяю — собирал я без пакетов, голые исходники. На федоре 3. Да, можно было не заниматься странным, а установить готовое, но скилл требовал прокачки. Я тогда таким образом пересобрал половину федоры, попутно недописав два пакетных менеджера.
Тут ещё стоит отметить, что на серверах как правило иксов нет (у разумных админов).
KV>И снова к вопросу о защищенности открытого кода
В открытом коде ты хотя-бы можешь вот так сам поискать баги.
О багах в закрытом коде тебе остается только догадываться
KV>>И снова к вопросу о защищенности открытого кода
3V>В открытом коде ты хотя-бы можешь вот так сам поискать баги.
3V>О багах в закрытом коде тебе остается только догадываться
Меньше знаешь — крепче спишь.
3V>В открытом коде ты хотя-бы можешь вот так сам поискать баги.
Я могу их и в закрытом поискать
KV>Я могу их и в закрытом поискать
Однако.
KV>Я могу их и в закрытом поискать
Т.е. вы утверждаете, что анализ бинарников более качественен и при этом требует меньше трудозатрат, чем анализ сорцев ?
3V>Здравствуйте, kochetkov.vladimir, Вы писали:
3V>Т.е. вы утверждаете, что анализ бинарников более качественен и при этом требует меньше трудозатрат, чем анализ сорцев ?
Я утверждаю обратное, но смысл предыдущего сообщения был не в этом, а в том, что насколько качественнее бы не был анализ исходного кода, в жестокой реальности это не дает ему никаких _практических_ преимуществ перед закрытым
KV>в жестокой реальности это не дает ему никаких _практических_ преимуществ перед закрытым
Ну от чего же!
Конечно даёт. Я могу оттуда, например, копипастить — закрытый код мне не даёт таких преимуществ.
Ф>Конечно даёт. Я могу оттуда, например, копипастить — закрытый код мне не даёт таких преимуществ.
KV>Здравствуйте, Философ, Вы писали:
Ф>>Конечно даёт. Я могу оттуда, например, копипастить — закрытый код мне не даёт таких преимуществ.
KV>
Владимир, я всё понимаю, но пока существуют такие преимущества, я придумаю миллион причин по которым открытый код более защищён, более желателен.
Выгода, которую я получаю, выдавая чужую работу за свою перевешивает всё, и защищённость в том числе — это просто становится неинтересным.
Кому-то что-то доказывать, анализировать защищённость, забагованность и прочие метрики бессмысленно, пока существует такая халява.
3V>Т.е. вы утверждаете, что анализ бинарников более качественен и при этом требует меньше трудозатрат, чем анализ сорцев ?
Искать баги в бинарниках сложнее как тому, кто защищается, так и тому, кто атакует. Так что полный паритет.
просто есть код который нормально разрабатывают и прочее непонятно что.
вот над chromium'ом работает толпа народа, с нормальным процессом разработки, тестированием и т.п.
а там где работает непонятно кто и непонятно как — там и баги.
открытость/закрытость тут ни при чем.
A>открытость/закрытость тут ни при чем.
+1
Закрытость/открытость ПО — суть лишь факт доступности сорцев.
Есть закрытое ПО. Опубликовал сорцы — уже открытое. И что изменится в самом ПО от факта публикации ?
3V>Закрытость/открытость ПО — суть лишь факт доступности сорцев.
3V>Есть закрытое ПО. Опубликовал сорцы — уже открытое. И что изменится в самом ПО от факта публикации ?
Если внутри говнокод, то ты перестанешь покупать сей продукт.
V>Если внутри говнокод, то ты перестанешь покупать сей продукт.
Ты, после этой темы, уже отказался от иксов?
Ops>Ты, после этой темы, уже отказался от иксов?
А я их не покупал.
Ops>>Ты, после этой темы, уже отказался от иксов?
V>А я их не покупал.
Тогда, наверное, тем более отказался, раз жалеть не о чем?
V>>А я их не покупал.
Ops>Тогда, наверное, тем более отказался, раз жалеть не о чем?
Ничего не понял, поясни что ты сказать хотел.
V>Здравствуйте, 3V, Вы писали:
3V>>Закрытость/открытость ПО — суть лишь факт доступности сорцев.
3V>>Есть закрытое ПО. Опубликовал сорцы — уже открытое. И что изменится в самом ПО от факта публикации ?
V>Если внутри говнокод, то ты перестанешь покупать сей продукт.
Странное утверждение. Пользователю пофик на то, какой внутри код.
Пользователю нужен функционал и эксплуатационные характеристики.
В плане защищенности все просто. Если код открыть — можно анализировать сорцы. Если нет — нет.
3V>Пользователю нужен функционал и эксплуатационные характеристики.
Ну так что с эксплуатационными характеристиками?
V>Ну так что с эксплуатационными характеристиками?
А что там ?
Качество ПО и факт его открытости никак не связаны.
См. пример выше. Есть закрытое ПО. Публикуем сорцы (открываем) — качество не меняется.
По эксплуатационным характеристикам.
Пользователю нужно, чтобы реализованный в ПО функционал обладал некими характеристиками (обычно оговаривается в ТЗ на разработку). Абстрактный пользователь, выбирающий ПО либо согласен с конкретными характеристиками конкретного изделия, либо нет. Вот и все. Ему без разницы открытое оно или нет. Ему решать задачи нужно, автоматизировать свою деятельность.
З.Ы. Пример хорошего сложного открытого ПО — PostgreSQL.
3V>Качество ПО и факт его открытости никак не связаны.
3V>См. пример выше. Есть закрытое ПО. Публикуем сорцы (открываем) — качество не меняется.
А ветер дует, потому что деревья качаются. Все, добили алогичностью, я на такую не способен.
A>открытость/закрытость тут ни при чем.
Именно так. Просто здесь есть несколько участников, считающих опенсорс де-факто более защищенным, нежели закрытый. Тема — очередной контрпример для них, не более.
A>>открытость/закрытость тут ни при чем.
KV>Именно так. Просто здесь есть несколько участников, считающих опенсорс де-факто более защищенным, нежели закрытый. Тема — очередной контрпример для них, не более.
Любой эксперт по безопасности linux-систем, даже просто пользователь без всяких известных в узких кругах специалистов знает, что иксы — это дыра и не только в безопасности. Но от этой "дыры" можно отказаться. В чем смысл искать дырки в дыре? Дешевый пиар?
Открытость исходников на порядки упрощает анализ защищенности.
Более интересно как отключить и удалить графическую систему (он же "дыра") в некоторых системах с закрытым кодом? Думаю, это не знают даже сами разработчики.
_>Более интересно как отключить и удалить графическую систему (он же "дыра") в некоторых системах с закрытым кодом? Думаю, это не знают даже сами разработчики.
А там нет ни багов, ни дыр.
V>Здравствуйте, fin_81, Вы писали:
_>>Более интересно как отключить и удалить графическую систему (он же "дыра") в некоторых системах с закрытым кодом? Думаю, это не знают даже сами разработчики.
V>А там нет ни багов, ни дыр.
как категорично!
Ф>как категорично!
Ф>
А иначе быть не может. Большой и сложный процесс разработки, полноценное тестирование, что-то там еще, что тут писали, дает им гарантию.
_>>Более интересно как отключить и удалить графическую систему (он же "дыра") в некоторых системах с закрытым кодом? Думаю, это не знают даже сами разработчики.
V>А там нет ни багов, ни дыр.
Но меня напрягает графический терминал по центру экрана в некоторых системах с закрытым кодом. Напряжение способствует быстрому накоплению усталости у оператора, а это потенциальная дыра в защищнности.
_>>Более интересно как отключить и удалить графическую систему (он же "дыра") в некоторых системах с закрытым кодом? Думаю, это не знают даже сами разработчики.
V>А там нет ни багов, ни дыр.
http://en.wikipedia.org/wiki/Windows_Metafile_vulnerability
просуществовало с конца 80-х. По времени жизни и по потенциальным последствиям аналогично дыре в bfdread, но, в отличие от последней, сначала начали эксплуатировать.
_>Открытость исходников на порядки упрощает анализ защищенности.
В разы, в лучшем случае, о чем я уже писал выше.
_>Более интересно как отключить и удалить графическую систему (он же "дыра") в некоторых системах с закрытым кодом? Думаю, это не знают даже сами разработчики.
А причем тут закрытые системы? Я же не утверждаю, что они более защищены, чем открытые. Я утверждаю, что в общем случае, открытые защищены не более, чем закрытые. Разница между этими двумя утверждениями очевидна или необходимы пояснения?
KV>Здравствуйте, fin_81, Вы писали:
_>>Открытость исходников на порядки упрощает анализ защищенности.
KV>В разы, в лучшем случае, о чем я уже писал выше.
Порядки, разы — экспертные оценки такие оценки. Нужна реальная статистика независимых экспертов. Даже если пустят экспертов в закрытый код, то трудно будет проверить правдивость и полноту исследований этих "независимых" экспертов.
_>>Более интересно как отключить и удалить графическую систему (он же "дыра") в некоторых системах с закрытым кодом? Думаю, это не знают даже сами разработчики.
KV>А причем тут закрытые системы? Я же не утверждаю, что они более защищены, чем открытые. Я утверждаю, что в общем случае, открытые защищены не более, чем закрытые. Разница между этими двумя утверждениями очевидна или необходимы пояснения?
Я утверждаю что в общем случае защищенность всех систем трудно оценить, вплоть до полной бессмысленности этой оценки. Поэтому я бы не согласился быть экспертом в оценке всех существующих систем или определенной части систем.
_>То трудно будет проверить правдивость и полноту исследований этих "независимых" экспертов.
Анализ защищенности — это обоснование защищенности системы, а не поиск в ней уязвимостей. Разница в том, что во втором случае, отчет может состоять из одной строчки "уязвимостей не выявлено", в то время, как в первом, отчет будет содержать обоснование эксперта, почему он считает систему защищенной от того или иного класса угроз. Т.е. и правдивость и полноту сможет проверить любой сторонний эксперт.
Просто ради любопытства: что в твоем понимании есть "зависимый" эксперт?
_>Я утверждаю что в общем случае защищенность всех систем трудно оценить
Именно так. Но почему-то при этом имеют место периодические категоричные утверждения о том, что опенсорс защищеннее. Парадокс?
_>>То трудно будет проверить правдивость и полноту исследований этих "независимых" экспертов.
KV>Анализ защищенности — это обоснование защищенности системы, а не поиск в ней уязвимостей. Разница в том, что во втором случае, отчет может состоять из одной строчки "уязвимостей не выявлено", в то время, как в первом, отчет будет содержать обоснование эксперта, почему он считает систему защищенной от того или иного класса угроз. Т.е. и правдивость и полноту сможет проверить любой сторонний эксперт.
Анализы, сделанные по разным методикам при этом еще разных систем бессмысленно сравнивать. Это практически независимые события, любые совпадения и несовпадения случайны.
KV>Просто ради любопытства: что в твоем понимании есть "зависимый" эксперт?
Зависимый — это когда методика анализа зависит от анализируемой системы. Открытый код и белый ящик против закрытого кода и черного ящика.
_>>Я утверждаю что в общем случае защищенность всех систем трудно оценить
KV>Именно так. Но почему-то при этом имеют место периодические категоричные утверждения о том, что опенсорс защищеннее. Парадокс?
Мне просто интересно, зачем специалисту по безопасности вбрасывать категоричные противоположные утверждения, которые мне кажутся очень сомнительными.
k> Именно так. Просто здесь есть несколько участников, считающих опенсорс де-факто более защищенным, нежели закрытый. Тема — очередной контрпример для них, не более.
А почему "контр"? По мне так как раз наглядно демонстрирует, что люди таки смотрят и изучают открытый код и те самые пресловутые "тысячи глаз" в нем иногда что-нибудь да находят в результате чего продукт на каждой подобной итерации становится более защищенным.
AB>Здравствуйте, kochetkov.vladimir, Вы писали:
k>> Именно так. Просто здесь есть несколько участников, считающих опенсорс де-факто более защищенным, нежели закрытый. Тема — очередной контрпример для них, не более.
AB>А почему "контр"? По мне так как раз наглядно демонстрирует, что люди таки смотрят и изучают открытый код и те самые пресловутые "тысячи глаз" в нем иногда что-нибудь да находят
Потому что, судя по результатам работы того парня, он был первым реально квалифицированным экспертом, кто взглянул на этот код за все время существования проекта. А, судя по результатам работы статанализатора, его натравили на код впервые за 20 с лишним лет. И это для популярного проекта с четверть-вековой историей.
Если это теоретически и можно назвать преимуществом опенсорса, то на практике им не пользуются в мере, достаточной для того, чтобы называть это преимуществом. От того, что тысячи глаз _могут_ посмотреть на код проекта, он еще не становится более защищенным. А по факту получается, что код X.Org (а ранее, и XFree86) оказалось просто некому смотреть на протяжении весьма немаленького промежутка времени.
AB>в результате чего продукт на каждой подобной итерации становится более защищенным.
Ну, если считать два десятка лет приемлемым интервалом между итерациями, то да
KV>Если это теоретически и можно назвать преимуществом опенсорса, то на практике им не пользуются в мере, достаточной для того, чтобы называть это преимуществом. От того, что тысячи глаз _могут_ посмотреть на код проекта, он еще не становится более защищенным. А по факту получается, что код X.Org (а ранее, и XFree86) оказалось просто некому смотреть на протяжении весьма немаленького промежутка времени.
Возможно просто потому, что никому это не надо было, кроме вот этого парня за все 20 лет.
KV>Ну, если считать два десятка лет приемлемым интервалом между итерациями, то да
Да хоть 100 лет, если продукт удовлетворяет всех, кто им пользуется.
AB>в результате чего продукт на каждой подобной итерации становится более защищенным.
Это недоказуемо в общем случае.
Ровно как и с обычными ошибками — исправление одной может порождать 10 новых.
Все зависит от процесса, если процесс поставлен, то есть какая-никакая гарантия того, что рано или поздно продукт станет в достаточной степени защищенный.
DOO>Все зависит от процесса, если процесс поставлен, то есть какая-никакая гарантия того, что рано или поздно продукт станет в достаточной степени защищенный.
ISO9000 и все их стадо тебя опровергает.
DOO>>Все зависит от процесса, если процесс поставлен, то есть какая-никакая гарантия того, что рано или поздно продукт станет в достаточной степени защищенный.
V>ISO9000 и все их стадо тебя опровергает.
не понял, что ты сказать хотел...
DOO>не понял, что ты сказать хотел...
Мдас. Это был пример того, что процесс имеет отношение только к процессу, а только очень опосредованное к результату.
KV>речь о 120 security багах, если кто не понял.
напоминает анекдот про продажу всей россии и поиск причитающейся мне доли. и что эти дыры означают в практическом плане? например, если сходить на вирус-тотал, то можно обнаружить нескончаемый поток пдф. акробат оказался самой дырявой программой, однако, если обратится к логам ids (при наличии доступа -- не у всех он есть), то наибольший процент успешных атак через наиболее защищенную платформу, защищенность которой обосновали при ее создании (жаба).
дыры сами по себе интересны разве что для конференции и как способ освоения бюджета и обоснования собственной значимости и необходимости. но давайте мы вместе с вами произведем достойный и объективный комплексный анализ. если повезет, то мы даже сможем реализовать одну из этих угроз в лабораторных условиях.
кстати, если компилировать лиса, то гнусь будет ругаться на ошибки переполнения буфера. причем именно тот гнусь, который ставится копипастой командной строки с инстукциями по сборки из официального сайта лиса. зашибись какой уровень безопасности. я так понимаю, что я далеко не один, кто тут же ринулся с отладчиком, ибо дырявый лис входит в штатную поставку многих дистров. да, конечно, это исправили. причем даже исправили в старых версиях (для тех, кто не хочет переходить на новые) и лис найдет и скачает обновления если дадут.
одного понять не могу. почему хакеры обошли это стороной? на паблике сплоитов нету. а дыры есть. компилятор ругается, что тут переполнение. смотрим в исходный код (благо он открытый) и понимаем, что оно эксплуатируемое. многие дистры никсов включают лиса в виде бинарника, то есть эксплуатация проблемой не является. но... никто не атакует. и кого не спросишь "почему не бросишь все и не напишешь сплоит" отвечают: тебе надо -- ты и пиши. а я дурак что ли писать?
скажем так: открытый код намного более открыт для контрибьюции, а потому когда кого-то серьезно беспокоит гондурас, то его либо перестают чесать, либо исправляют проблему. вот только проблема безопасности для подавляющего большинства это ни разу не проблема. даже для тех немногих (типа нас с вами) она чисто формальная проблема. например, меня больше волнует, что в лисе опять поломали жабаскрипт и он проваливает свои же собственные тесты, в результате чего мой код перестает работать на чужих компьютерах.
как вообще можно серьезно обсуждать проблемы белого человека в нигере, если в нигере белый человек это деликатес? нет, ну в принципе. безотносительно открытости/закрытости кода его безопасности очень мало кого волнует. даже там, где создается видимость волнения -- эти волны гасит ветер и до берега они не докатываются. на примере тех же браузеров... ХТМЛ5 это огромная радость для хакеров. это как коррупция. бесполезно обсуждать насколько прозрачность власти или демократия или религия соотносится с коррупцией. "бороться или победить" (с).
М>кстати, если компилировать лиса, то гнусь будет ругаться на ошибки переполнения буфера.
Да фиг с ними. Хоть бы течь меньше стал.
V>Здравствуйте, мыщъх, Вы писали:
М>>кстати, если компилировать лиса, то гнусь будет ругаться на ошибки переполнения буфера.
V>Да фиг с ними. Хоть бы течь меньше стал.
с учетом агрессивной оптимизации сейчас такая каша творится. цикл из нескольких строк при определенных обстоятельствах разворачивается на много метров в памяти. это называется адаптивной компиляцией, зависящей от входных данных, что действительно в теории способно порвать даже нативно компилируемые языки, но на практике остается нерешенной проблема освобождения адаптино нагенерированного кода. в версии до 3х там было все просто. там можно было выбросить все что мы только что оттранслировали. сейчас это не так. и потому память сильно течет на сгенерированном коде, который на самом деле не код, а данные, но все-таки и код тоже. а потому уборщик мусора под него только в проекте и даже надежного теоритического обоснования все еще нету.
у лиса была мега цель -- порвать всех на тестах, что он и сделал. а теперь несколько лет будут соображать как открутить то, что они накрутили.
ЗЫ. у меня лис сильно кастомизированный. вот я думаю -- мне одному это интересно или есть смысл выложить это в бинарном или исходном виде? у меня можно задать макс. потребляемой памяти при запуске лиса в виде аргумента командной строки. разумеется, производительность страдает, т.к. алгоритм выгрузки загруженных ресурсов у меня простой как шланг и потому чем больше вы открываете вкладок при фиксированном потреблении памяти, тем больше высвобождается ресурсов и при переключении взад их приходится загружать обратно (с диска, с кэша). при открытии очень большого кол-ва вкладок (сотни) при небольшом заданном буфере -- памяти просто не хватает и новые вкладки перестают открываться. т.к. пока я являюсь практически единственным пользователем своей кастомной версии, то я просто знаю, что нужно соизмерять одно с другим. а если выкладывать на паблик, то, вероятно, нужно какой-то механизм предупреждений еще докручивать о том, что память заканчивается. как вы думаете?
М>ЗЫ. у меня лис сильно кастомизированный. вот я думаю -- мне одному это интересно или есть смысл выложить это в бинарном или исходном виде? у меня можно задать макс. потребляемой памяти при запуске лиса в виде аргумента командной строки. разумеется, производительность страдает, т.к. алгоритм выгрузки загруженных ресурсов у меня простой как шланг и потому чем больше вы открываете вкладок при фиксированном потреблении памяти, тем больше высвобождается ресурсов и при переключении взад их приходится загружать обратно (с диска, с кэша). при открытии очень большого кол-ва вкладок (сотни) при небольшом заданном буфере -- памяти просто не хватает и новые вкладки перестают открываться. т.к. пока я являюсь практически единственным пользователем своей кастомной версии, то я просто знаю, что нужно соизмерять одно с другим. а если выкладывать на паблик, то, вероятно, нужно какой-то механизм предупреждений еще докручивать о том, что память заканчивается. как вы думаете?
Выкладывай. Почему-то мне кажется, что не тебе одному, по крайней мере пользоваться им. Конечно большинство не будет лишний раз само пересобирать, но поставить Лиса, что меньше течет — это толпы захотят.
Лично я попробую твою сборку сразу, как ты выложишь ее где.
Для начала внятного текста хватит об особенности, а там отзывы и пожелания понесутся толпой.
V>Здравствуйте, мыщъх, Вы писали:
V>Лично я попробую твою сборку сразу, как ты выложишь ее где.
а под какую ось вам интересно? инстала, впрочем, у меня нет ни под одну из осей, как и цифровой подписи исполняемого файла. оригинального логотипа тоже нет (лис его никому не отдает). обновлений тоже нет, т.к. они бы откатили все изменения.
V>Для начала внятного текста хватит об особенности, а там отзывы и пожелания понесутся толпой.
вообще-то самой главной фичей ради которой я форкнул лиса стал богатый по возможностям отладчик скриптов, нацеленный на работу с обфусцироваными зловредными скриптами. но эта фича уж точно большинству не нужна особенно с учетом, что отладчик работает на уровне байт-кода с которым даже жабаскрипт девы навряд ли захотят знакомиться. оптимизация работы с ресурсами это продолжение борьбы с малварью, т.к. для динамического сканера главное иметь возможность загрузить как можно больше уролов в один инстанс и не позволять отдельным слишком умным страницам отжирать память гигабайтами.
от публичного распростанения меня пока что останавливает отсутствие времени на своевременные мержи новых версий лиса и обновлений безопасности. кому нужен браузер, который обновляется только когда меня сильно пнут?
М>от публичного распростанения меня пока что останавливает отсутствие времени на своевременные мержи новых версий лиса и обновлений безопасности. кому нужен браузер, который обновляется только когда меня сильно пнут?
Тогда понятно.
М>Здравствуйте, kochetkov.vladimir, Вы писали:
М>то наибольший процент успешных атак через наиболее защищенную платформу, защищенность которой обосновали при ее создании (жаба).
Строгое обоснование защищенности любой вычислительной системы, полной по Тьюрингу — неразрешимая задача (давно доказано, же). Да и type-safety это еще не защищенность. Там больше маркетологи постарались, когда расписывали преимущества новой платформы. Кстати, что касается Java, то тут возникает закономерный вопрос: почему подавляющее большинство успешных атак на закрытую реализацию Java было актуально (на момент атаки) и для ее открытой реализации?
М>дыры сами по себе интересны разве что для конференции и как способ освоения бюджета и обоснования собственной значимости и необходимости. но давайте мы вместе с вами произведем достойный и объективный комплексный анализ. если повезет, то мы даже сможем реализовать одну из этих угроз в лабораторных условиях.
Тут интересны не сами эти дыры и даже не их количество, а тот временной интервал, который потребовался "тысячам глаз", чтобы таки-найти их в открытом коде.
М>отвечают: тебе надо -- ты и пиши. а я дурак что ли писать?
JFYI: за каждую уязвимость лиса нынче платят по 3 килобакса, уже несколько лет как (http://www.mozilla.org/security/bug-bounty.html), рабочие сплоиты при этом не требуют)
М>это как коррупция. бесполезно обсуждать насколько прозрачность власти или демократия или религия соотносится с коррупцией. "бороться или победить" (с).
Дык в этом-то я и пытаюсь убедить местных сторонников тезиса о защищенности опенсорса)
KV>Дык в этом-то я и пытаюсь убедить местных сторонников тезиса о защищенности опенсорса)
Странный способ.
Логично было бы сначала определить что ты понимаешь под защищенностью.
Потом показать, что закрытый софт в соответствии с твоим определением лучше защищен, чем открытый.
Возможнооказалось бы что то, что ты понимаешь под защищенностью нужно только тебе.
V>Логично было бы сначала определить что ты понимаешь под защищенностью.
http://www.slideshare.net/kochetkov.vladimir/hdswasm-webinar/10 и следующие за ним два слайда.
V>Потом показать, что закрытый софт в соответствии с твоим определением лучше защищен, чем открытый.
Разумеется не лучше. Из факта доступности исходного кода нельзя делать выводы о его защищенности — это все, что я пытаюсь показать
V>Возможнооказалось бы что то, что ты понимаешь под защищенностью нужно только тебе.
Количество клиентов нашей компании и динамика продаж разрабатываемых нами продуктов говорят об обратном уже 11-ый год
KV>http://www.slideshare.net/kochetkov.vladimir/hdswasm-webinar/10 и следующие за ним два слайда.
Ненавижу видео смотреть. Жуткая новая мода. Неужели так сложно в 3-4 тезисах мысль выразить в письменном виде.
Ну и по тем слайдам, имхо, вода и ничего более — 0 сути. Извини, но я так вижу.
KV>Разумеется не лучше. Из факта доступности исходного кода нельзя делать выводы о его защищенности — это все, что я пытаюсь показать
Конечно нет. Но открытый код ты можешь проанализировать с точки зрения твоих критериев, а закрытый не можешь. А дальше уже или сам исправить, или попросить разработчиков. В случае закрытого ты этого ничего не можешь.
KV>Количество клиентов нашей компании и динамика продаж разрабатываемых нами продуктов говорят об обратном уже 11-ый год
Ясно. Ты крут и согласен с этим. Я так понимаю, что этот вопрос тебя волновал больше всего.
V>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>http://www.slideshare.net/kochetkov.vladimir/hdswasm-webinar/10 и следующие за ним два слайда.
V>Ненавижу видео смотреть. Жуткая новая мода. Неужели так сложно в 3-4 тезисах мысль выразить в письменном виде.
Там не видео
V>Ну и по тем слайдам, имхо, вода и ничего более — 0 сути. Извини, но я так вижу.
Там дана одна из формулировок общепринятого определения защищенности ИС, которое знакомо любому мало-мальски знакомому с данной предметной областью специалисту
KV>>Разумеется не лучше. Из факта доступности исходного кода нельзя делать выводы о его защищенности — это все, что я пытаюсь показать
V>Конечно нет. Но открытый код ты можешь проанализировать с точки зрения твоих критериев, а закрытый не можешь. А дальше уже или сам исправить, или попросить разработчиков. В случае закрытого ты этого ничего не можешь.
Я (и любой другой специалист из этой области) могу провести анализ защищенности продукта с закрытым кодом, ни имея его исходников. Но это также не говорит о защищенности открытого либо закрытого кода. Что касается исправления уязвимости, то без исходника это конечно практически нереально. Но вот _противодействовать_ ей в рамках конкретной системы — практически всегда возможно безотносительно наличия исходников уязвимого приложения.
KV>>Количество клиентов нашей компании и динамика продаж разрабатываемых нами продуктов говорят об обратном уже 11-ый год
V>Ясно. Ты крут и согласен с этим. Я так понимаю, что этот вопрос тебя волновал больше всего.
Я не понимаю, откуда у тебя берется столь непреодолимое желание обсудить мою скромную персону. Ну заводи отдельную тему, в "О жизни" там или еще где — обсудим, че. Мне не жалко
k> Что касается исправления уязвимости, то без исходника это конечно практически нереально. Но вот _противодействовать_ ей в рамках конкретной системы — практически всегда возможно безотносительно наличия исходников уязвимого приложения.
А как же то, что на слайдах написано "Бороться необходимо с причинами, а не со следствиями"? А то ведь противодействие может сводиться к анекдотичному: "Надеть один презерватив, забинтовать; надеть другой, намазать йодом; надеть третий, зацементировать... и никаких половых связей!", но разве это
защищенностьжизнь?KV>Здравствуйте, мыщъх, Вы писали:
М>> то наибольший процент успешных атак через наиболее защищенную платформу,
М>> защищенность которой обосновали при ее создании (жаба).
KV> Строгое обоснование защищенности любой вычислительной системы,
KV> полной по Тьюрингу — неразрешимая задача (давно доказано, же).
так ведь никто не говорит, что жабу нельзя атаковать в принципе. можно. но разработчики предусмотрели глубоко эшелонированную линию обороны на всех уровнях. ваша позиция мне понятна, но она непродуктивна. кстати сказать в движках жаба _скриптов_ так и не нашлось ошибок, ставших популярным вектором атак. вполне безопасный язык жабаскрипт. а с учетом последних оптимизирующих движков даже не слишком тормозной.
KV> Да и type-safety это еще не защищенность.
так ведь в жабе не только это... кстати, какой такой type-safety? на уровне байт кода есть куча "ручек" для обхода системы типов, а именно на таком уровне скорее всего будет работать злоумышленник.
KV> Кстати, что касается Java, то тут возникает закономерный вопрос:
KV> почему подавляющее большинство успешных атак на закрытую реализацию
KV> Java было актуально (на момент атаки) и для ее открытой реализации?
общая база кода. вы посмотрите на разработчиков открытой и закрытой реализаций. вам не кажется, что это одни и те же лица? и код они не писали с нуля, а открыли закрытый. надеюсь, что вы согласитесь -- допустить одинаковую ошибку в одном и том же месте при независимых реализациях маловероятно. а успех атакующих объясняется природой жабы. никаких тебе тут шелл-кодов. в основной массе работает сценарий -- найти библиотечный код, работающий в обход системы безопасности и допускающий выполнение хакерского кода в его контексте. а хакерский код обычно представляет собой тупое скачать исполняемый файл и запустить. "пробивная" способность сплоитов сильно повышается. да вы и сами знаете...
KV> Тут интересны не сами эти дыры и даже не их количество, а тот временной интервал,
KV> который потребовался "тысячам глаз", чтобы таки-найти их в открытом коде.
если бы я стал искать дыры в открытом коде, то иксы были бы последнее на что я обратил внимание. давайте все-таки обсудим возможность реализации угроз (если они, действительно, есть). а вот вам мой пример: алгоритм мд5 открытый. и его хакнули, хотя и с большим опозданием. но все-таки хакнули, т.к. на него обрушился мозговой штурм специалистов со всех стран мира. был бы он закрытым... тогда бы он продержался намного дольше.
М>>отвечают: тебе надо -- ты и пиши. а я дурак что ли писать?
KV>JFYI: за каждую уязвимость лиса нынче платят по 3 килобакса,
это же маркетинг. уязвимость есть. ее показывает компилятор, выдающий ругательства и даже (о боги!) детектирующий переполнение в рантайме и прерывающий работу браузера, в результате его становится невозомжно запустить без изменения либо маке файла, либо фикса дыры. (либо установки старого компилятора). кстати, если посмотреть сколько дыр фиксится, то нереально чтобы за кажую платили 3 килобакса.
по моим наблюдениям даже из опубликованных дыр (с номером на CVE) до эксплоитов (неработающих) доводится в лучшем случае 5%, а рабочих из них вообще можно по пальцем пересчитать. из чего мы делаем вывод, что дыры хакерам малоинтересны и степень опасности сильно преувеличена.
М>так ведь никто не говорит, что жабу нельзя атаковать в принципе. можно. но разработчики предусмотрели глубоко эшелонированную линию обороны на всех уровнях.
М>ваша позиция мне понятна, но она непродуктивна.
О позиции по какому именно вопросу идет речь?
М>кстати сказать в движках жаба _скриптов_ так и не нашлось ошибок, ставших популярным вектором атак. вполне безопасный язык жабаскрипт. а с учетом последних оптимизирующих движков даже не слишком тормозной.
Это был скарказм? =/ Полно же было сплоитов
KV>> Да и type-safety это еще не защищенность.
М>так ведь в жабе не только это...
Из mandatory-механизмов обеспечения защищенности на уровне языка, IMO только оно
М>кстати, какой такой type-safety?
Ну, http://en.wikipedia.org/wiki/Type_safety
М>на уровне байт кода есть куча "ручек" для обхода системы типов, а именно на таком уровне скорее всего будет работать злоумышленник.
Дык злоумышленнику сначала нужно каким-то образом попасть на этот уровень?
KV>> Java было актуально (на момент атаки) и для ее открытой реализации?
М>общая база кода.
Это был сарказм в виде риторического вопроса в адрес сторонников априорной защищенности опенсорс-кода
KV>> который потребовался "тысячам глаз", чтобы таки-найти их в открытом коде.
М>если бы я стал искать дыры в открытом коде, то иксы были бы последнее на что я обратил внимание. давайте все-таки обсудим возможность реализации угроз (если они, действительно, есть).
Ок. Речь об угрозах в иксах из числа продемонстрированных тем парнем?
М>а вот вам мой пример: алгоритм мд5 открытый. и его хакнули, хотя и с большим опозданием. но все-таки хакнули, т.к. на него обрушился мозговой штурм специалистов со всех стран мира. был бы он закрытым... тогда бы он продержался намного дольше.
С точки зрения blackbox-подхода, md5 является ящиком с одним входом и одним выходом. + как минимум один побочный канал временных задержек. Этого недостаточно для того, чтобы отреверсить сам протокол, но вполне достаточно для применения любых методик, представляющих собой комбинаторику по входным данным. То есть, найти коллизии черным ящиком возможно разве что брутфорсом, а вот подверженность алгоритма атакам типа расширения хэша (https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks) — вполне анализируется вчерную, без владения алгоритмом.
В любой же мало-мальски комплексной ИС, таких входов и выходов — сотни, а в чуть более сложных — счет идет уже на десятки/сотни тысяч. Не считая побочных каналов. Этого более чем достаточно для того, чтобы оценить защищенность системы, не прибегая к изучению ее исходного кода смарт-фаззингом всех точек входа. Такой поход дает выявление до 70-75% уязвимостей от числа существующих в системе на момент анализа и зачастую этого уже достаточно для владельца системы и ее пользователей. Покрытие остальных 25-30% добирается анализом результатов реверсинга бинарников системы, если конечно они доступны.
М>это же маркетинг. уязвимость есть. ее показывает компилятор, выдающий ругательства и даже (о боги!) детектирующий переполнение в рантайме и прерывающий работу браузера, в результате его становится невозомжно запустить без изменения либо маке файла, либо фикса дыры. (либо установки старого компилятора). кстати, если посмотреть сколько дыр фиксится, то нереально чтобы за кажую платили 3 килобакса.
М>по моим наблюдениям даже из опубликованных дыр (с номером на CVE) до эксплоитов (неработающих) доводится в лучшем случае 5%, а рабочих из них вообще можно по пальцем пересчитать. из чего мы делаем вывод, что дыры хакерам малоинтересны и степень опасности сильно преувеличена.
Я хз о причинах выделенного, но действительно платят за каждый найденный сторонними исследователями критичный security-баг. Получавших от Mozilla такое вознаграждение знаю лично, если что
М>скажем так: открытый код намного более открыт для контрибьюции, а потому когда кого-то серьезно беспокоит гондурас, то его либо перестают чесать, либо исправляют проблему. вот только проблема безопасности для подавляющего большинства это ни разу не проблема. даже для тех немногих (типа нас с вами) она чисто формальная проблема. например, меня больше волнует, что в лисе опять поломали жабаскрипт и он проваливает свои же собственные тесты, в результате чего мой код перестает работать на чужих компьютерах.
Плохо дело — чужие компы перестали работать на мыщъха