Здравствуйте, Vain, Вы писали:

V>Количество людей, которое может найти баг в исходниках, всяко выше того кол-ва, которое может найти баг в бинарниках.

Если идти арифметическим путем, то количество тех, кто может найти security-баги блэкбоксом равно сумме и тех и других. А исходники для блэкбокса не требуются. Вот такая занимательная арифметика

V>Эти задачи вообще находятся на разных уровнях, не надо ставить их в один ряд.

Ну не знаю, для кого как. Когда у нас заказывают анализ защищенности, в большинстве случаев доступ к исходникам не предоставляют (чтобы получить более-менее точную картину того, что может сделать реальный потенциальный атакующий). Поэтому как-то приходится в один ряд ставить, уж извини

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, kochetkov.vladimir, Вы писали:

V>>>А без её наличия желание и умение тебе уже не помогут.
KV>>Возможность найти уязвимость существует всегда. В отличии от желания и умения.
V>Я говорил про возможность исправить.

А я говорил, что пока мы не разберемся с возможностью "найти", рассуждать об еще и "исправить" по меньшей мере странно

V>>>Видимо тесты решили написать?
KV>>Нет, код впервые за время существования проекта посмотрел тот, кто умел искать уязвимости. После его репорта авторы решили просканировать код каким-то бесплатным анализатором и в пачке обнаруженных еще и им недостатков, как раз и всплыла уязвимость, которой было 23 года.
V>Тоже вариант. Это как тесты самого кода.

Я не об этом. Почему в данном проекте преимущества защищенности opensource-кода не выстрелили в течении 23 лет? Понятно, что частный случай, и правильный ответ на вопрос: "потому что даже его авторы забивали на защищенность, пока их не ткнули носом", но уж больно забавный этот случай)

V>>>И при чём здесь опен сорс?
KV>>Не причем. Его защищенность ни чем не лучше защищенности закрытого кода, я только об этом тут и говорю
V>Это спорно. Защищённость кода в открытых исходниках зависит от степени исапользования его всеми остальными.

Да, только не защищенность, а заинтересованность того или иного контингента в ее анализе для конкретного продукта. Опыт OpenSSL и X11, правда, говорит об обратном, но ок, допустим соглашусь.

V>Открытые библиотеки могут попросту чаще использоваться и соответственно чаще фикситься. А возможность адаптировать исходники под "свои нужны" лишь усиливает это.

Т.е. увеличивает ту самую защищенность. Что делает открытость исходников лишь одним из множества факторов, потенциально способных повлиять на защищенность продукта при их определенной совокупности. Не более того.

V>Ты про 23 года? Это не делает опен сорс хуже по отношению к приватсорсу, это вообще ни о чём ещё не говорит.

Вот опять ты про свое Я утверждаю "не лучше", почему ты все время пытаешься приписать мне утверждение "хуже"?

Здравствуйте, kochetkov.vladimir, Вы писали:

V>>Эти задачи вообще находятся на разных уровнях, не надо ставить их в один ряд.
KV>Ну не знаю, для кого как. Когда у нас заказывают анализ защищенности, в большинстве случаев доступ к исходникам не предоставляют (чтобы получить более-менее точную картину того, что может сделать реальный потенциальный атакующий). Поэтому как-то приходится в один ряд ставить, уж извини
Не понял как недоступность исходников равняет эти вещи.

Здравствуйте, kochetkov.vladimir, Вы писали:

V>>>>А без её наличия желание и умение тебе уже не помогут.
KV>>>Возможность найти уязвимость существует всегда. В отличии от желания и умения.
V>>Я говорил про возможность исправить.
KV>А я говорил, что пока мы не разберемся с возможностью "найти", рассуждать об еще и "исправить" по меньшей мере странно
Ты только недавно приводил пример как обычный статик чек исходников находит баги в них и тут же говоришь что не разобрался с возможностью. Да в последнее время только и появляются возможности как через анализ исходников или их линковку с отладочным кодом найти такие баги.

V>>Тоже вариант. Это как тесты самого кода.
KV>Я не об этом. Почему в данном проекте преимущества защищенности opensource-кода не выстрелили в течении 23 лет? Понятно, что частный случай, и правильный ответ на вопрос: "потому что даже его авторы забивали на защищенность, пока их не ткнули носом", но уж больно забавный этот случай)
С чего ты взяд что в приватном софте не бывает таких багов? Вот, к примеру, баг с диалоговым окном, которое вешало винду семёрку это скольколетний по-твоему баг?

V>>Открытые библиотеки могут попросту чаще использоваться и соответственно чаще фикситься. А возможность адаптировать исходники под "свои нужны" лишь усиливает это.
KV>Т.е. увеличивает ту самую защищенность. Что делает открытость исходников лишь одним из множества факторов, потенциально способных повлиять на защищенность продукта при их определенной совокупности. Не более того.
А это уже само по себе не хорошо?

V>>Ты про 23 года? Это не делает опен сорс хуже по отношению к приватсорсу, это вообще ни о чём ещё не говорит.
KV>Вот опять ты про свое Я утверждаю "не лучше", почему ты все время пытаешься приписать мне утверждение "хуже"?
Ты только что выше написал что это фактор из разряда "лучше", не?

Здравствуйте, Vain, Вы писали:

V>Количество людей, которое может найти баг в исходниках, всяко выше того кол-ва, которое может найти баг в бинарниках.
Зато квалификация вторых на порядок выше.

Здравствуйте, CreatorCray, Вы писали:

V>>Количество людей, которое может найти баг в исходниках, всяко выше того кол-ва, которое может найти баг в бинарниках.
CC>Зато квалификация вторых на порядок выше.
Но индустрию двигают середнячки, обычные работники, поэтому опять не понятно к чему это сказано.

Здравствуйте, CreatorCray, Вы писали:
CC>Ну я пару раз выкатывал патчи в виде "offset: bytes заменить на bytes" к чужим бинарям.
Я лично патчил вполне себе закрытый Триллиан (не для секьюрити, а для починки их автодетектора codepage), потому что авторы Триллиана — клинические идиоты. Мало того, что они сами не понимали, что такое интернационализация (это вообще нормально для людей, основной язык которых бинарно одинаков в ASCII7, ASCII, KOI8-R, 866, 20866, 1251, 1252, 1253, UTF8 и ещё в десятке code pages, про которые я ничего не знаю), так они несколько лет последовательно игнорировали письма от более компетентных в вопросе товарищей, где им подробно объясняли, что и где следует починить.

Здравствуйте, Vain, Вы писали:

V>Но индустрию двигают середнячки, обычные работники, поэтому опять не понятно к чему это сказано.

Найти нетривиальную уязвимость даже в исходниках — это уровень чуть повыше середнячка.

Здравствуйте, ins-omnia, Вы писали:

V>>Но индустрию двигают середнячки, обычные работники, поэтому опять не понятно к чему это сказано.
IO>Найти нетривиальную уязвимость даже в исходниках — это уровень чуть повыше середнячка.
Для применения всяких статических анализаторов и отладчиков этот уровень ниже среднего.

Здравствуйте, Vain, Вы писали:

V>Для применения всяких статических анализаторов и отладчиков этот уровень ниже среднего.

Вряд ли статические анализаторы нашли бы heartbleed или goto fail.
Проекты вроде OpenSSL и GnuTLS скорее всего регулярно через них прогоняют.
Если не авторы, то кто-то ещё.

Здравствуйте, ins-omnia, Вы писали:

V>>Для применения всяких статических анализаторов и отладчиков этот уровень ниже среднего.
IO>Вряд ли статические анализаторы нашли бы heartbleed или goto fail.
IO>Проекты вроде OpenSSL и GnuTLS скорее всего регулярно через них прогоняют.
IO>Если не авторы, то кто-то ещё.
Ну я всякие сложные случаи не рассматриваю. Они и в приватном софте возникают, тут нет ничего особенного. И кстати, для написания тестов, которые находят 95% багов уровень — тоже средний.

Здравствуйте, Vain, Вы писали:

V>Ну я всякие сложные случаи не рассматриваю.

С точки зрения ручного анализа — случаи с heartbleed и openssl были элементарными. А вот статанализатором вещи, подобные задвоенному goto поймать практически нереально в общем случае (см. теорему Райса и рассуждения на тему: http://sgordey.blogspot.ru/2013/07/blog-post_30.html). На практике, результат в 40-60%% обнаруженных анализатором уязвимостей (от числа обнаруженных ручным анализом) дают только наиболее продвинутые решения, выходящие также за рамки статического анализа. Среди свободных анализаторов таких решений в настоящий момент, в общем-то, нет.

V>И кстати, для написания тестов, которые находят 95% багов уровень — тоже средний.

Тесты тут мало чем помогут, ибо баг != уязвимость. Покажи, как ты будешь покрывать тестами подобный этому код, чтобы избежать появления в нем уязвимостей к атакам SQL-инъекций и злоупотребления функционалом. Не хочешь синтетический пример — покажи на примере багов heartbleed и openssl. Или возьми пару любых угроз из какого-нибудь хит-парада типа OWASP TOP 10. Когда начнешь продумывать такие тесты, сам поймешь, насколько они "полезны" в плане обеспечения защищенности кода.

Здравствуйте, Vain, Вы писали:

V>Не понял как недоступность исходников равняет эти вещи.

Я не знаю, на какой еще лад повторить, что анализ бинарников кажется сложным только разработчикам в силу того, что они привыкли работать с исходниками. Понимаешь, среднестатистический разработчик не найдет и половины уязвимостей в коде среднестатистической степени паршивости (неоднократно проверял, в т.ч. здесь), просто потому что это не его предметная область. А для тех, кто этим занимается профессионально, особой разницы нет. В подавляющем же большинстве случаев, при анализе защищенности веб-приложений — и исходники, и бинарники нужны только для того, чтобы выделить в коде вызовы потенциально уязвимых функций, а подтвердить по каждой наличие уязвимости и построить эксплоит (либо опровергнуть ее) проще и быстрее, отправив скриптом пару сотен запросов, чем пол-дня продираться по развеститому CFG, пытаясь вывести ограничения на параметры эксплоита вручную. Блэкбокс реально рулит, а тут пофиг и на исходники, и на бинарники. С поиском и эксплуатацией бинарных уязвимостей в нативных приложениях та же самая история: гораздо проще и быстрее профаззить исследуемое приложение относительно небольшим набором векторов и изучить кейсы, приводящие к крешу под отладчиком, нежели корпеть над кодом, чтобы понять, в какое место относительно стека мы попадаем в каждом конкретном случае.

Здравствуйте, Vain, Вы писали:

KV>>А я говорил, что пока мы не разберемся с возможностью "найти", рассуждать об еще и "исправить" по меньшей мере странно
V>Ты только недавно приводил пример как обычный статик чек исходников находит баги в них и тут же говоришь что не разобрался с возможностью.

Я так понимаю, что ты не в курсе существования анализаторов бинарного кода, которые на выходе дают тот же процент обнаруженных уязвимостей, что и анализаторы кода? Ну и блэкбокс-сканеров, которым вообще до лампочки исходники с бинарниками, лишь бы можно было дергать за точки входа в приложение?

Никаких существенных преимуществ при использовании автоматизированных средств, факт наличия исходников не дает. Все равно чуть меньше половины уязвимостей таким образом не обнаружить. А что я думаю по поводу ручного анализа и "возможности" провести его любым желающим — я высказал еще в начале ветки.

V>Да в последнее время только и появляются возможности как через анализ исходников или их линковку с отладочным кодом найти такие баги.

V>С чего ты взяд что в приватном софте не бывает таких багов? Вот, к примеру, баг с диалоговым окном, которое вешало винду семёрку это скольколетний по-твоему баг?

Бывают. Но ты же утверждаешь, что опенсорс де-факто защищеннее. Вот мне и интересно, как в нем даже теоретически может _внезапно_ обнаружиться 23 летний баг, еще и с без малого полутора сотнями менее древних, но не менее критичных?

KV>>Т.е. увеличивает ту самую защищенность. Что делает открытость исходников лишь одним из множества факторов, потенциально способных повлиять на защищенность продукта при их определенной совокупности. Не более того.
V>А это уже само по себе не хорошо?

Разумеется хорошо. Я не критикую модель опенсорса, я призываю смотреть на нее объективно и без столмановского фанатизма.

V>Ты только что выше написал что это фактор из разряда "лучше", не?

Но в конечном итоге-то решает совокупность факторов, разве нет?

Здравствуйте, kochetkov.vladimir, Вы писали:

V>>Ты только что выше написал что это фактор из разряда "лучше", не?
KV>Но в конечном итоге-то решает совокупность факторов, разве нет?
Для этого должны быть положительные факторы из приват сорса которых нет в открытом. Можешь привести примеры этих факторов?

Здравствуйте, ins-omnia, Вы писали:

V>>Для применения всяких статических анализаторов и отладчиков этот уровень ниже среднего.
IO>Вряд ли статические анализаторы нашли бы heartbleed или goto fail.

IO>Проекты вроде OpenSSL и GnuTLS скорее всего регулярно через них прогоняют.
Насколько я помню прогонять начали уже после heartbleed

Здравствуйте, Vain, Вы писали:

Радует, что по остальным пунктам вопросов уже нет

V>Для этого должны быть положительные факторы из приват сорса которых нет в открытом.

Необязательно. Достаточно чтобы в рамках одного и того же открытого проекта наряду с положительными "сыграли" отрицательные факторы выбранной модели разработки. Например, если целевой аудиторией проекта являются исключительно домохозяйки, то вероятность того, что кто-либо из них заинтересуется возможностью изучить исходный код равна нулю. Туда же она стремиться в малоизвестных проектах с небольшой пользовательской базой, как ты сам заметил выше. А, как уже говорил выше я, обеспечение защищенности кода — процесс, требующий от PM построения и выполнения SDLC (процесса контроля метрик защищенности кода проекта на протяжении всего цикла разработки), в который совершенно не вписывается такой "положительный" фактор, как "кто-нибудь, когда-нибудь — да посмотрит, возможность-то есть". Открытых проектов, в которых этот процесс выстроен: а) эффективно б) на регулярной волонтерской работе, наберется от силы несколько десятков. И это такие проекты, как Debian, NetBSD, Sqlite, NaCl и т.п., т.е. отнюдь не малоизвестные, чья ЦА либо достаточно широка, либо достаточно специфична для того, чтобы в ней нашлись те, кто не только могут, но и умеют, и хотят участвовать в обеспечении защищенности этих проектов.

Здравствуйте, Vain, Вы писали:

V>Конретно ответ был про опенсорс в сравнении с приватным. Поиск уязвимостей никак не связан с открытостью исходников. Но с открытыми исходниками у тебя имеется прямая возможность исправить багу/дыру. Сколько мне раз это надо повторить?

У проектов с закрытыми исходниками обычно есть владелец, который занимается внесением правок в исходный код. Какая принципиальная разница кто исправил баг, ты или владелец продукта ?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Радует, что по остальным пунктам вопросов уже нет
Я тебя просто перестал понимать, да и времени отвечать на несколько веток нет.

V>>Для этого должны быть положительные факторы из приват сорса которых нет в открытом.
KV>Необязательно. Достаточно чтобы в рамках одного и того же открытого проекта наряду с положительными "сыграли" отрицательные факторы выбранной модели разработки.
Отрицательные факторы ничего не будут говорить потому-что они присутствуют везде. Меряют по кол-ву плюшек а не г-на.

KV>Например, если целевой аудиторией проекта являются исключительно домохозяйки, то вероятность того, что кто-либо из них заинтересуется возможностью изучить исходный код равна нулю.
Я работаю в программировании давно и домохозяек здесь ни одной не видел.

KV>Туда же она стремиться в малоизвестных проектах с небольшой пользовательской базой, как ты сам заметил выше. А, как уже говорил выше я, обеспечение защищенности кода — процесс, требующий от PM построения и выполнения SDLC (процесса контроля метрик защищенности кода проекта на протяжении всего цикла разработки), в который совершенно не вписывается такой "положительный" фактор, как "кто-нибудь, когда-нибудь — да посмотрит, возможность-то есть".
Да это просто не решаемая задача в рамках пм-а. Всё равно будут дыры.

KV>Открытых проектов, в которых этот процесс выстроен: а) эффективно б) на регулярной волонтерской работе, наберется от силы несколько десятков. И это такие проекты, как Debian, NetBSD, Sqlite, NaCl и т.п., т.е. отнюдь не малоизвестные, чья ЦА либо достаточно широка, либо достаточно специфична для того, чтобы в ней нашлись те, кто не только могут, но и умеют, и хотят участвовать в обеспечении защищенности этих проектов.
У этих проектов и аудитория не маленькая, так? Мне почему-то кажется что именно этот фактор накладывает свой отпечаток на защищённость.

Здравствуйте, Evgeniy Skvortsov, Вы писали:

V>>Конретно ответ был про опенсорс в сравнении с приватным. Поиск уязвимостей никак не связан с открытостью исходников. Но с открытыми исходниками у тебя имеется прямая возможность исправить багу/дыру. Сколько мне раз это надо повторить?
ES>У проектов с закрытыми исходниками обычно есть владелец, который занимается внесением правок в исходный код. Какая принципиальная разница кто исправил баг, ты или владелец продукта ?
Огромная разница. Для того чтобы владелец исправил — ему надо захотеть сделать это. И вот тут появляется 100500 причин почему не надо это делать. К примеру, "продукт и так деньги приносит", "нету времени мы пилим новые фичи", "новая версия не содержит этого бага — фича для покупки новой версии", "новая исправленная версия не поддерживается фичи X — устарела, а пользователи всё-равно пользуют", "дыра не страшная — мы не тот продукт чтобы её закрывать".