В официальном блоге компании Google, посвященном вопросам безопасности, опубликована статья (http://googleonlinesecurity.blogspot.com/2010/07/rebooting-r...), в которой участники Google Security Team излагают свои соображения по вопросу раскрытия информации об уязвимостях, обнаруженных в программном обеспечении. Основным приоритетом при выборе политики раскрытия подобной информации сотрудники команды безопасности Google полагают защищенность конечного пользователя.
В настоящее время можно выделить два ключевых подхода к раскрытию такой информации:
- <i>Ответственное раскрытие</i> (responsible disclosure). При таком подходе исследователь, обнаруживший уязвимость, уведомляет о ней только производителя уязвимого программного обеспечения, скрывая информацию от общественности. Очевидным достоинством этого подхода является то, что производителю предоставляется возможность выпустить исправления раньше, чем уязвимость начнет массово использоваться злоумышл...URL: http://googleonlinesecurity.blogspot.com/2010/07/rebooting-r...
Новость: http://www.opennet.ru/opennews/art.shtml?num=27392
К сожалению работает только full disclosure, посмотрите последние выпуски PHP и Firefox, в PHP поправили дыры о которых приватно сообщили в мае, а в Firefox - в марте. Одновременно в Firefox почти мгновенно поправили дыру о которой стало известно публично.
> К сожалению работает только full disclosure, посмотрите последние выпуски PHP и Firefox, в PHP поправили дыры о которых приватно сообщили в мае, а в Firefox - в марте. Одновременно в Firefox почти мгновенно поправили дыру о которой стало известно публично.Как вы можете знать, работают ли другие способы, если вы их не видите?
В том то и суть, чтобы было больше дела, и меньше зависеть от от пустых крикунов.Своевремменность нахождения и исправления ошибок зависит в первую очередь от качества архитектуры проекта. Если архитектура корявая - потом кричи, не кричи об ошибках - их будет море.
Как это можно наблюдать с PHP.
s/PHP/руками/gВ руках мастера и палочки - оружие. Обезьяна же на танке безопасна.
>s/PHP/руками/g
>
>В руках мастера и палочки - оружие. Обезьяна же на танке безопасна.Да, если выбора не оказалось в конкретный момент.
Однако, если выбор есть, то хороший мастер выбирает хороший инструмент.Хотя, я так понял, вы согласны со мной относительно низкого качества PHP.
А сравнивать палочки и танк по качеству - нелогично. Вы явно путаете качество с размером и назначением.
Могут быть качественные палочки и некачественный танк.
Нет, Вы неправильно меня поняли. Я не согласен с Вами по поводу 'низкого качества PHP'. Это точно такой же инструмент, как и все остальные. Perl, Python, Ruby, you name. Ни чем от них не отличающийся. По крайней мере с точки зрения 'качества'.Поясню проще: с умом можно разрабатывать качественные продукты на любом из них. Кривыми же руками можно испортить абсолютно все, что угодно. И абстрактное 'качество' приведенного в качестве примера PHP тут совершенно не причем. Не стоит списывать дремучую некомпетентность отдельных конечных пользователей на проблемы инструмента.
>Нет, Вы неправильно меня поняли. Я не согласен с Вами по поводу 'низкого качества PHP'. Это точно такой же инструмент, как и все остальные. Perl, Python, Ruby, you name. Ни чем от них не отличающийся. По крайней мере с точки зрения 'качества'.То, что вы ставите в одну линию PHP, Perl, Python и Ruby по качеству архитектуры, может говорить только о том, что вы плохо представляете себе архитектуру ПО и процессы проектирования.
>Поясню проще: с умом можно разрабатывать качественные продукты на любом из них.
Разрабатывать-то можно, но только не с умом. Продукт может и будет одинакового качества, но себестоимость его производства с помощью инструментов разного качества будет тоже разной. Таких простых вещей не знаете. А еще говорите о компетентности.
>Кривыми же руками можно испортить абсолютно все, что угодно. И абстрактное 'качество' приведенного в качестве примера PHP тут совершенно не причем. Не стоит списывать дремучую некомпетентность отдельных конечных пользователей на проблемы инструмента.
Поздно метаться. Вы сравнивали до этого по качеству танк и палочки.
А ваши поздние оправдания по поводу плохого качества ваших мыслей - сродни тем самым выкрикам о больших количествах найденных и исправленных ошибках, когда качество проектирования было плохим изначально.
Да понятно, что PHP не без недостатков, но всё же это далеко не бейсик.
Писать на нём хорошо можно, он этому не мешает особо. Не навязывает - это да, но не мешает.
Если, конечно, вы не PHP3 имеете в виду, с register_globals, magic quotes, без ООП и пространств имён.
>Да понятно, что PHP не без недостатков, но всё же это далеко не бейсик.Ну если вы можете сравнить только с бейсиком - то конечно.
>Писать на нём хорошо можно, он этому не мешает особо.
Писать и на бумаге хорошо можно, она тоже этому не мешает особо.
>Не навязывает - это да, но не мешает.
Этим интересным противопоставлением вы как бы пытаетесь нам сказать, что вам даже тех навязываний, которые есть в PHP не достаточно, но зато вас утешает, что он вам "не мешает особо".
Вообще очень даже много чего навязывает, как многие более примитивнные языки.
Хотя примитивные языки и должны навязывать - стиль, методы решения и др. - в этом их назначение, своеобразная "защита от дурака".Но ведь речь шла именно о качестве реализации, а это совсем другое. Потому что будучи рожденным, как узко-специализированное средство для веб-разработок, PHP пытается изображать из себя язык общего назначения. А в итоге - "не пава, не ворона". И куча хаотичных заплат во внутренней архитектуре. Плюс еще плохое начальное проектирование даже как узко-специализированного средства. И комьюнити такое же.
Интересно, на каких тогда языках вам "плохо писать", и какие языки вам "танцевать^W писать мешают"?
>Если, конечно, вы не PHP3 имеете в виду, с register_globals, magic quotes, без ООП и пространств имён.
Понятно одно. Вы тоже один из тех, кто плохо представляет себе, что такое архитектура ПО и качество проектирования.
И руководствуетесь преимущественно такими туманными критериями, как "на нем хорошо писать", типа "хорошо сидим".
>Поясню проще: с умом можно разрабатывать качественные продукты на любом из них. >Кривыми же руками можно испортить абсолютно все, что угодно. И абстрактное
>'качество' приведенного в качестве примера PHP тут совершенно не причем. Не стоит
>списывать дремучую некомпетентность отдельных конечных пользователей на проблемы >инструмента.не верно. вы и все-все окружающие могут ездить на машинах всегда по правилам, но если вдруг у вашей машины откажут тормоза, то совершенно не очевидно, что вы не соберете впереди едущего.
>PHP [...] Perl, Python, Ruby, you name. Ни чем от них не отличающийся.
>По крайней мере с точки зрения 'качества'.Как полагаете -- руки, которыми такое пишется, как можно назвать?.. :(
PS: такое ощущение, что выгорели и устали от проблем "здеся". Не переживайте, тоже порой бывает, но в итоге когда понимаешь, что диагностируемость всё-таки милее -- всё возвращается на круги своя :)
>Обезьяна же на танке безопасна.А как насчет обезьяны с гранатой? :)
>>Обезьяна же на танке безопасна.
>
>А как насчет обезьяны с гранатой? :)Ну если рассуждать с научной точки зрения, то вероятность того, что она грамотно оторвет чеку, после этого бросит в вас (и умудрится не подорваться сама) - вероятность маленькая)
Хотя смотря какая обезъяна.
Если на вас несется разъяренная горилла, то там пофиг на гранату)А с кодингом - 99% ошибок идут изза кривизны рук, и 1% - изза ошибок самого языка.
Я бы даже сказал, что соотношение 99,99% и 0,01% =)Фишка ещё в том, что когда знаешь, что вон в том модуле, или вон в том операторе часто находят ошибки, можно написать код с оглядкой на это.
Т.е. поставить там побольше проверок данных, побольше проверок на error=1 и т.д.
Т.е. руками уменьшить даже вероятность глюка изза ошибки языка.
Обычно наоборот - это язык уменьшает вероятность глюка изза кривых рук)
Итак, речь шла о факторах, влияющих на количество багов в проектах и мерах их предотвращения.А "обезьяна" - была метафорой к этому.
>>>Обезьяна же на танке безопасна.
>>
>>А как насчет обезьяны с гранатой? :)
>
>Ну если рассуждать с научной точки зрения, то вероятность того, что она грамотно оторвет чеку, после этого бросит в вас (и умудрится не подорваться сама) - вероятность маленькая)То есть вы считате, что с научной точки зрения очень мала вероятность того, что примат сможет "грамотно оторвать чеку".
Это в метафоре прмерно соответствует способности представителей определенных течений в программировании написать код, который может запускаться.Далее вы видимо считаете, что обезьяна с гранатой да еще и с оторванной чекой по прежнему не представляет большой опастности, и ей по-вашему надо ее еще именно бросить, чтобы создать эффект. А может ли она подорваться сама - это по-вашему вообще не важно.
С учетом того, что обезьяна - это метафора какбэ "специалиста", плохо владеющего инструментом, а взрыв - это метафора большого количества багов в проектах, с учетом этого ход ваших рассуждений очень даже характеризует. Особенно игнорирование опасности "самоподрыва".
>Хотя смотря какая обезъяна.
>Если на вас несется разъяренная горилла, то там пофиг на гранату)И продолжение вашей мысли не менее интересно.
Далее, судя по всему, если попытаться вывести общий смысл из ваших сбивчивых формулировок - вы не согласны с тем, что количество багов в первую очередь зависит от качества проектирования.
>А с кодингом - 99% ошибок идут изза кривизны рук, и 1% - изза ошибок самого языка.
>Я бы даже сказал, что соотношение 99,99% и 0,01% =)
>Фишка ещё в том, что когда знаешь, что вон в том модуле, или вон в том операторе часто находят ошибки, можно написать код с оглядкой на это.Интересно, что за такими "языками" вы предпочитаете пользоваться, в операторах которых "часто находят ошибки". И вмето того, чтобы отправить баг репорт об этом, фундаментально огораживают это место большим количеством "проверок".
И судя по всему, операторов в них не меньше, чем модулей.
>Т.е. поставить там побольше проверок данных, побольше проверок на error=1 и т.д.
Т.е. по-вашему, главное поставить "побольше проверок", а проектировать не обязательно.
А откуда у вас берутся проверочные условия, вы обычно не особо задумываетесь. А также какова вероятность неправильно поставить сами эти проверки.>Т.е. руками уменьшить даже вероятность глюка изза ошибки языка.
>Обычно наоборот - это язык уменьшает вероятность глюка изза кривых рук)Ну и наконец, вы явно путаете понятие языка со средсвами разработки.
Из всего вами сказанного, отчетливо виден общий стиль, в котором вы пишете. Это длинные-длинные тексты програм, с большим-большим количеством "проверок". И вы убеждены, что именно такой стиль фундаментально огораживает вас от большого числа багов.
А также можно пердположить, что вы пользуетесь средствами, которые такой стиль всячески поощряют, и создают иллюзию, что якобы можно обойтись и без проектирования.
Почему не вижу ? Не вижу только до выхода исправленной версии. Как только версия вышла обычно можно отследить историю определения дыр. И в самих advisory обычно приводится лог, дыра найдена тогда-то, тогда-то сообщено разработчикам, тогда-то поправлено, тогда-то информация придана огласке.
>Почему не вижу ?Потому что у вас упрощенный и идеализированный взгляд на мир.
>Не вижу только до выхода исправленной версии. Как только версия вышла обычно можно отследить историю определения дыр. И в самих advisory обычно приводится лог, дыра найдена тогда-то, тогда-то сообщено разработчикам, тогда-то поправлено, тогда-то информация придана огласке.
А кто вам сказал, что все придается огласке?
Если цивилизованный способ сообщать об ошибках разработчикам, не придавая ошибки огласке. Тем не менее все довольны.
>> Если цивилизованный способ сообщать об ошибках разработчикам, не придавая ошибки огласке. Тем не менее все довольны.^Есть^ цивилизованный способ сообщать об ошибках разработчикам, не придавая ошибки огласке. Тем не менее все довольны.
>>>>Почему не вижу ?
>>>
>>>Потому что у вас упрощенный и идеализированный взгляд на мир.
>>
>>Клевый аргумент.
>>И не поспоришь - труднее всего спорить с глупым аргументом =)
>
>Ну, данный аргумент далее более подробно объясняется, и вы с этими объяснениями
>спорить не решились, посто вырвав фразу из общего контекста, и сферчно
>заявив о глупости в вакууме.Это хорошо, если подробно объясняется.
А вы можете спорить с человеком, не стараясь его задеть (своими предположениями о его возможной низкой квалификации)?
Ну и плюс, не просто сотрясать воздух фразами "грамотное проектирование", "семантическая ошибка", и т.д.
А добавить конкретики.
Например, привести пример кода или пример проектирования, который доказывает вашу правоту.
Ещё можно ссылки приводить на конкретные статьи.
А то получается спор в виде "все вот так и вот так, а если вы не понимаете этого, то вы дилетант и дурак".
Конструктива и позитива.
>Ну и плюс, не просто сотрясать воздух фразами "грамотное проектирование", "семантическая ошибка", и т.д.
>А добавить конкретики.Я вообще-то говорил о зависимости количества багов от качества проектирования.
А не сферическое "грамотное проектирование" в вакууме.
То есть для вас тема проектирования - не конкретна?
Сдается, что вы вообще плохо представляете себе, что это такое.Вы не знаете, что такое "семантическая ошибка"? А это вы вообще к чему?
>Например, привести пример кода или пример проектирования, который доказывает вашу правоту.
Интересно, как вы представляете себе пример проектирования, размещенный здесь в форуме?
И что я потеряю, если факт моей правоты, конкретно вы посчитаете не доказанным?>Ещё можно ссылки приводить на конкретные статьи.
На какие статьи? В уголовном кодексе? Как я могу привести ссылки на конкретнные стаьи, если я на конкретные стаьи не ссылался?
Вы обнаружили пробелы в своих знаниях, и хотите, чтобы я вам подсказал, как их восполнить?
При этом ставя ворос так, как будто я обязан заботиться о целостности ваших познаний.>А то получается спор в виде "все вот так и вот так, а если вы не понимаете этого, то вы дилетант и дурак".
Я что-то потеряю, если у вас так получится?
Я говорил то, что я говорил.
Количество багов в проектах в первую очередь зависит от качества проектирования.
>К сожалению работает только full disclosure,А он вообще очень полезное лекарство от раздолбайства. ИМХО гугл дело говорит - должен ставиться максимальный срок реакции. Нет реакции? Получите сплойты, будет стимул быстро реагировать.
Дело за малым: заставить пользователей конкретного продукта в массовом порядке своевременно накатывать соответствующие обновления безопасности. Иначе это все борьба с ветряными мельницами.
PS: Да, и, если уж ставить себе глобальную задачу бороться за мир во всем мире, отучить пользователей качать всякую дрянь из сети. В противном случае, не смотря на все потуги, конечный результат будет все равно один и тот же. А интересует лишь конечный результат.
> Дело за малым: заставить пользователей конкретного продукта в массовом порядке своевременно накатывать соответствующие обновления безопасности. Иначе это все борьба с ветряными мельницами.И в чем суть вашего сарказма? Вы описали то, что существует, так, какбудто этого нет. Ну можно не заствлять своевременно накатывать - есть автоматическое обновление безопасности. Да, оно работает не идеально. Но не хуже, чем лавинообразный процесс исправления ошибок, как результат плохого проектирования.
>PS: Да, и, если уж ставить себе глобальную задачу бороться за мир во всем мире, отучить пользователей качать всякую дрянь из сети. В противном случае, не смотря на все потуги, конечный результат будет все равно один и тот же. А интересует лишь конечный результат.
Все гораздо проще. Есть разработчики, которые плохо проектируют, и есть пользователи, которые с завидным упорством выбирают плохие разработки. И таких большинство.
А есть качественные проекты. И есть пользователи, которые такие проекты умеют отличать. И таких всегда меньшинство.
Однако польза от более качественного меньшинства всегда компенсирует проблемы, которые порождает большинство. В этом заключается природное рановесие.
Все в конечном итоге определяется качеством проектирования, а во вторую - системой исправления ошибок. А там, где проекты качественнее - там и система исправления ошибок качественнее, как следствие, а не наоборот, как причина, потому что систему исправления ошибок тоже надо проектировать.
Просто в качественных проектах меньше шума об исправленных ошибках. Так же, как и криков о борьбе за мир там, где друг с другом не борются.
>> Дело за малым: заставить пользователей конкретного продукта в массовом порядке своевременно накатывать соответствующие обновления безопасности. Иначе это все борьба с ветряными мельницами.
>
>И в чем суть вашего сарказма? Вы описали то, что существует, так,
>какбудто этого нет. Ну можно не заствлять своевременно накатывать - есть
>автоматическое обновление безопасности. Да, оно работает не идеально. Но не хуже,
>чем лавинообразный процесс исправления ошибок, как результат плохого проектирования.Применительно конкретно к браузерам этого нет. Достаточно взглянуть на статы user agent на пачке веб серверов с более-менее приличным трафиком. Зоопарк из версий осла и фокса фееричен. А ведь все помнят, что если не каждый то через раз то точно релиз фокса закрывает иногда до десяти критических дыр, которые при определенном желании и навыке могут привести к компрометации системы. И дыры, кстати, после релиза (а иногда и до) становятся известными широкой публике.
Да, они - закрыли. Они - молодцы. Да, у них есть соотв. механизм обновления. Причем в MS Windows например нужно приложить минимум телодвижений, чтобы фокс был up to date. А что толку? Если хотя бы треть их пользователей воспользуется обновлением а тем более сделает это своевременно - это уже можно сказать счастье. Ну а остальные?
>Применительно конкретно к браузерам этого нет.Чего именно _этого_ нет?
"И как один умрем в борьбе за _это_".>Достаточно взглянуть на статы user agent на пачке веб серверов с более-менее приличным трафиком. Зоопарк из версий осла и фокса фееричен. А ведь все помнят, что если не каждый то через раз то точно релиз фокса закрывает иногда до десяти критических дыр, которые при определенном желании и навыке могут привести к компрометации системы. И дыры, кстати, после релиза (а иногда и до) становятся известными широкой публике.
>Да, они - закрыли. Они - молодцы. Да, у них есть соотв. механизм обновления. Причем в MS Windows например нужно приложить минимум телодвижений, чтобы фокс был up to date. А что толку? Если хотя бы треть их пользователей воспользуется обновлением а тем более сделает это своевременно - это уже можно сказать счастье. Ну а остальные?Вы, собственно что здесь доказываете?
Что механизм автообновлений работает не идеально?
Ну так я уже выше это и так сказал.Кроме того, я уже сказал, что лучший способ минимизировать количество дыр - качественное проектирование.
А вы опять все про дыры, да про дыры. Вы за что боритесь-то?
Кроме невнятных формулировок, изобилующих всякими словечками, смысл которых, как видно, вы плохо понимаете, вам так и не удалось сформулировать, за что и против чего вы выступаете.
Ясно только одно - что вы плохо представляете себе реальные процессы разработок.
> Вы, собственно что здесь доказываете? Что механизм автообновлений работает не идеально? Ну так я уже выше это и так сказал.Неидеально - это как бы это сказать, это несколько смазано. Я бы сказал чуть точнее что он не работает вообще. В лучшем случае - присутствует в следовых количествах. Без этого ключевого момента все попытки оптимизации процесса репортирования багов - это все равно что тушить пожар из кружки. Круто, громко, в принципе может дать красивый PR при должном подходе, но... вот только это мало полезно с практической точки зрения.
> Кроме того, я уже сказал, что лучший способ минимизировать количество дыр - качественное проектирование.
Есть какие-то конкретные предложения? Кроме абстрактного пожелания 'давайте будем писать лучше'?
Если же обсуждать сугубо по абстракциям лежа на диване и плюя в потолок то я бы предложил, чтобы все человеки на земле были добрыми честными умными и вообще положительными во всех отношениях. Мечтать всего лишь о 'качественном проектировании' - это как-то слишком мелко. Нужно шире смотреть на проблему. Не нужно себя ограничивать в мечтах.
> А вы опять все про дыры, да про дыры. Вы за что боритесь-то?
Борюсь? Нет, спасибо. Пусть уж гугл сам как-нибудь, без меня. Благо они большие красивые и толстые и вроде как все могут. По крайней мере по слухам. У них все получится рано или поздно. Хотя сам подход конечно же не может вызывать некоторых сомнений. О чем и было написано мною выше. Впрочем, это их бизнес, их продукт и соответственно их проблемы.
Хотя.. Они несут определенную социальную ответственность. И микрософт и мозила и теперь уже гугл. Ведь это в первую очередь благодаря их продуктам Сеть постепенно но неумолимо превращается в один большой ботнет катастрофических размеров. И с них - спрос.
> Ясно только одно - что вы плохо представляете себе реальные процессы разработок.
Упорно хотите перейти на личности? Welcome to LOR. Здесь я сраться на столь низком уровне не хочу.
В исходном посте вы говорили так, как будто автообновления вообще не существует.
Поняв эту оплошность, вы теперь пытаетесь что-то такое выдумать на эту тему.>Неидеально - это как бы это сказать, это несколько смазано. Я бы сказал чуть точнее что он не работает вообще. В лучшем случае - присутствует в следовых количествах. Без этого ключевого момента все попытки оптимизации процесса репортирования багов - это все равно что тушить пожар из кружки. Круто, громко, в принципе может дать красивый PR при должном подходе, но... вот только это мало полезно с практической точки зрения.
Во-первых, вы путаете автообновление с "процессом репортирования багов" - что в очередной раз демонстрирует, что вы плохо знаете, о чем говорите.
"присутствует в следовых количествах" - Такое впечатление, что вы просто переводите малопонятные вам английский тексты авто-переводчиками, пытаясь скрыть свою некомпетентность за всякими словечками.
Ну если вы пользуетесь только софтом с большим количеством дыр и не можете настроить автообновление, то это еще ведь не значит, что у всех так. Хотя то, что автообновление - вещь неидеальная, я уже сказал. Но если у вас совсем с этим плохо, то это уже сугубо ваши проблемы.
>> Кроме того, я уже сказал, что лучший способ минимизировать количество дыр - качественное проектирование.
>
>Есть какие-то конкретные предложения? Кроме абстрактного пожелания 'давайте будем писать лучше'?Вы хотите сказать, что не знаете, как это делать, или вы просто не верите, что где-то это делают.
Ну это не удивительно, если вы понимаете "качественное проектирование" просто как "лучше писать".А зачем мне предлагать, если качественно проектируемые проекты и так существуют.
Другой вопрос, что это вы сомневаетесь в их существовании. Но это уже не моя проблема.>Если же обсуждать сугубо по абстракциям лежа на диване и плюя в потолок то я бы предложил, чтобы все человеки на земле были добрыми честными умными и вообще положительными во всех отношениях. Мечтать всего лишь о 'качественном проектировании' - это как-то слишком мелко. Нужно шире смотреть на проблему. Не нужно себя ограничивать в мечтах.
Ну я понял уже, что вы считаете, что качественного проектирования по-вашему в принципе в природе не существует. Вы считаете это чем-то абстратным, а любые упоминания об этом, вызывают у вас ассоциации с "борьбой за мир". Похоже, что вы плохо представляете, что такое проектирование вообще.
>Борюсь? Нет, спасибо. Пусть уж гугл сам как-нибудь, без меня. Благо они большие красивые и толстые и вроде как все могут. По крайней мере по слухам. У них все получится рано или поздно. Хотя сам подход конечно же не может вызывать некоторых сомнений. О чем и было написано мною выше. Впрочем, это их бизнес, их продукт и соответственно их проблемы.
И все-таки вы за что-то тут боритесь, только не можете сформулировать за что конкретно и прыгаете с тему на тему.
>Хотя.. Они несут определенную социальную ответственность. И микрософт и мозила и теперь уже гугл. Ведь это в первую очередь благодаря их продуктам Сеть постепенно но неумолимо превращается в один большой ботнет катастрофических размеров. И с них - спрос.
А, понятно, вас беспокоит социальная ответственность. Именно поэтому вы отождествляете вопросы исправления багов с идеями борьбы за мир. Правда, судя по вашим словам, вам и то и другое кажется безнадежным, но все равно вы призываете к социальной ответственности за это безнадежное дело.
Такое ощущение, что вас вообще раздражает развитие индустрии ИТ. Без всего этого вам явно было бы проще жить, и вам бы очень хотелось вернуться во времена, когда этого всего не было.
>Упорно хотите перейти на личности? Welcome to LOR. Здесь я сраться на столь низком уровне не хочу.
А, ну да, вы признаете только такую возвышенную полемику, как измерение "длины палочек" и сопоставление этого с танком. (См. в постах выше)
>> Есть какие-то конкретные предложения? Кроме абстрактного пожелания 'давайте будем писать лучше'?
> Вы хотите сказать, что не знаете, как это делать, или вы просто не верите, что где-то это делают. Ну это не удивительно, если вы понимаете "качественное проектирование" просто как "лучше писать".Повторю свой вопрос: у Вас будут какие-то конкретные технические предложения по улучшению архитектуры вполне конкретных проектов - Хрома (если уж новость о гугле) и Фокса дабы уменьшить поток багов в этих проектах и повысить безопасность конечных пользователей? Если Вы так упорно апеллируете к правильной архитектуре то, очевидно, есть какие-то конкретные мысли, предложения, пожелания, может быть даже решения? Ведь нельзя же апеллировать к ней просто так, абстрактно, правда?
>Повторю свой вопрос: у Вас будут какие-то конкретные технические предложенияЕсли вы хотите услышать конкретные технические предложения, сформулируйте ваши вопросы так, чтобы было понятно, что вы разбираетесь в этой технической области.
А вас вообще, почему интересует этот вопрос?
Вы сами хотите им что-то предложить, но не знаете что?Или вы осознали (или сразу понимали но пытались скрыть) недостаток своих знаний в этой области, и ждете от меня идей, как этот недостаток поправить?
>по улучшению архитектуры вполне конкретных проектов - Хрома (если уж новость о гугле) и Фокса дабы уменьшить поток багов в этих проектах и повысить безопасность конечных пользователей?
И жалуясь на мою якобы "абстрактность", вы считаете этот свой вопрос конкретным?
С учетом масштабов указанных вами проектов и количества используемых в них технологий.И наконец, с учетом этой же масштабности, вы ведь не доказали, что именно в этих проектах с количеством багов все так уж совсем плохо. И то, что один "грамотей" поставил их в один ряд с PHP, а вы это приняли как должное, в очередной раз подтверждает, что вы плохо в этом разбираетесь.
>Если Вы так упорно апеллируете к правильной архитектуре то, очевидно, есть какие-то конкретные мысли, предложения, пожелания, может быть даже решения? Ведь нельзя же апеллировать к ней просто так, абстрактно, правда?
Я уже прекрасно понял, что для вас зависимость количества багов от архитектуры и качества проектирования - вещь совершенно абстрактная.
Желание гугла понятно - иметь неограниченно большое время на исправление уязвимостей, чтобы никуда не торопясь попивая мохито пол года писать патч. Только причем тут интересы пользователей?!
>Желание гугла понятно - иметь неограниченно большое время на исправление уязвимостей, чтобы никуда не торопясь попивая мохито пол года писать патч.Желание создателей и владельцев Гугла - максимально извлекать выгоду, благодаря своим талантам и способностям. Никуда не торопясь. Это их право и заслуга.
> Только причем тут интересы пользователей?!
Ну может интересы нормальных пользователей и при чем, а вот интересы всяких бездарностей, которые даже из халявы выгоду для себя извлечь не могут, и просто точат лясы от зависти к другим, вместо того, чтобы самим развиваться - их интересы действительно ни при чем.
Ты статью точно читал дальше первого абзаца?
И что в этой демагогии нового, чего мы как бы не знали и не практиковали?
Это рекомендация мировому сообществу от всемирно известной корпорации. Этим и раньше пользовались, просто они обращают всеобщее внимание на то, какой метод сообщения об ошибках по их мнению лучше. Когда рекомендацию даёт некто Василий Пупких в своём ЖЖ, то его ни кто не замечает, а к Гуглу может и прислушаются. Тем более, что они готовы не словом, а делом доказать работоспособность такого подхода.
Хм, а можно поинтересоваться, что именно _Вы_ как security researcher практикуете и в чём это выражается?
Поинтересоваться можно. Кто же вам запретит?
>Поинтересоваться можно. Кто же вам запретит?Тогда представьте список найденных и отрепорченных Вами уязвимостей, пожалуйста.
Может быть еще ключ от квартиры где девки визжат?
>Может быть еще ключ от квартиры где девки визжат?Полагаю, его у Вас тоже нет. :)
Давать срок три дня и разглашать всю информацию.
та не, 2 часа достаточно..
Почему именно 3 дня? Правда интересно откуда такая цифра появилась.
Всегда удивляло (скорее даже бесило) когда люди нагло и бесстыжи прикрываются заботой о тебе, делая что либо с выгодой для себя. Мол, "я думал ты устал с работы хочешь отдохнуть и решил, что занесу долг в другой раз"...
Открывать информацию о дыре по-принципу полного раскрытия не этично в первую очередь по-отношению к другим пользователям. Сообщая разработчику информацию приватно с условием полного раскрытия через установленный срок этично по-отношению ко всем. Если разработчики не исправят, то это будет уже лишь их и только их вина, а если исправят и выпустят обновление, то раскрытие информации о уязвимости уже мало кому повредит.
В подходе "Полное раскрытие" упустили еще одно очень важное достоинство. Имея информацию о уязвимости любой пользователь сможет защитить сам себя. Если уязвимость на столько сложная что на исправление уйдет много времени, то пользователь может не использовать возможности программного обеспечения подверженные данной уязвимости, или вовсе на время использовать альтернативное ПО, если такова имеется. Согласен что не очень выгодный вариант для производителя, но это надо рассматривать если говорить о защищенность конечного пользователя.
В случае простой уязвимости и срок будет на её решение установлен короткий (всё зависит от нашедшего, естественно), а сложную не только хрен ещё кто найдёт, так потом ещё и хрен использует. Например, баги с переполнением стека в разном софте часто находят, вот только не всегда дело даже до proof of concept вызывающий крэш доходит и дыра так и остаётся лишь потенциальной, а ведь использовать его для запуска своего кода ещё сложнее.
>В подходе "Полное раскрытие" упустили еще одно очень важное достоинство. Имея информацию
>о уязвимости любой пользователь сможет защитить сам себя. Если уязвимость на
>столько сложная что на исправление уйдет много времени, то пользователь может
>не использовать возможности программного обеспечения подверженные данной уязвимости, или вовсе на
>время использовать альтернативное ПО, если такова имеется. Согласен что не очень
>выгодный вариант для производителя, но это надо рассматривать если говорить о
>защищенность конечного пользователя.Пользователю достаточно сообщить, что уязвимость имеется и чем (не )?надо пользоваться, чтобы не нарваться. "Полного раскрытия" уязвимости для этого не нужно.
>В подходе "Полное раскрытие" упустили еще одно очень важное достоинство.
>Имея информацию о уязвимости любой пользователь сможет защитить сам себя.Не любой, а достаточно квалифицированный и притом заинтересованный в срочнейшем решении очередной вылезшей проблемы.
Скажем, недавно пробегала информация по libtiff. Слегка припоминая характер внутренностей и прошлых пачей по тамошним buffer/integer overflow'ам, решил не рыпаться да подождать, пока апдейт приедет -- хотя если бы действительно было критично, то можно было бы напрячься и вспомнить/доразучить си в нужном объёме.
60 дней это слишком много, 7 ну максимум. А лучше 3
>60 дней это слишком много, 7 ну максимум. А лучше 3по хорошему, перед раскрытием уязвимости, нужно ждать пока ее исправят разработчики и когда она разойдется по юзерам. второе, так-же, ограничено скоростью мантейнера. 3-и дня это очень мало.
что можно исправлять ДВА месяца? не понимаю. Ну пару дней ещё пока заплатка по юзерам разойдется, ладно.
Жирные архитектурные косяки, что же ещё?
Неизвестнуюю массам дыру не закроют быстро. Ибо зачем, все равно никто не знает:) можно ничегометр встроить лишний.
>что можно исправлять ДВА месяца? не понимаю. Ну пару дней ещё пока
>заплатка по юзерам разойдется, ладно.Просто сиутации разные бывают.
Разработчик именно этой подсистемы может свалить в отпуск.
Или разработчики могут долго обсуждать дырку через списки рассылки (некоторые почту читают пару раз в день).
Потом написание патча, тестирование, отладка.
Если проект коммерческий, то плюс ещё всякие административные проволочки, согласование.
Например, может быть политика обновлений раз в месяц - могут приурочить патч к этому.
А потом - обновления у юзеров.
Кто-то обновления раз в месяц, или два накатывает.
Или админ может в отпуск уйти.
Ну и все такое.
Плюс некоторый запас.
Так что, если учесть все это, 2 месяца - вполне разумный срок.
1 А что делали тестировщики до этого?
2 А то что у пользователь изза этой дыры может за два месяца "реально попасть на бабки" ничего?
Так что такие 2 месяца способстыуют снижению доверия к софту, бог с ним с приетарным, но ведь и СПО обсирается
>снижению доверия к софтуВы доверяете _софту_???
PS: я -- нет, только людям.
то есть, если уязвимость через два дня откроют, то у юзера меньше возможностей попасть на бабки, нежели подробности уязвимости станут известны через 60-ят дней?
>то есть, если уязвимость через два дня откроют, то у юзера меньше
>возможностей попасть на бабки, нежели подробности уязвимости станут известны через 60-ят
>дней?Кто следит за используемым софтом сможет или самостоятельно костыли прикрутить, или отказаться от софта в пользу аналога. В любом случае шерстить логи в поисках следов использования уязвимости за 2 дня и за 60 таки большая разница.
>>то есть, если уязвимость через два дня откроют, то у юзера меньше
>>возможностей попасть на бабки, нежели подробности уязвимости станут известны через 60-ят
>>дней?
>
>Кто следит за используемым софтом сможет или самостоятельно костыли прикрутить, или отказаться
>от софта в пользу аналога. В любом случае шерстить логи в
>поисках следов использования уязвимости за 2 дня и за 60 таки
>большая разница.Ну, блин, мы говорим и про обычных домашних юзеров тоже.
Они ни за чем ни следят, ничего не знают.
Просто их браузер тупо сам обновляется)Я не говорю, что мы говорим ТОЛЬКО про них.
Мы говорим И про них.
>Ну, блин, мы говорим и про обычных домашних юзеров тоже.
>Они ни за чем ни следят, ничего не знают.
>Просто их браузер тупо сам обновляется)
>
>Я не говорю, что мы говорим ТОЛЬКО про них.
>Мы говорим И про них.Заражение вирусом машин хомячков одного провайдера с образованием ботнета приведет к компрометации провайдера.
>1 А что делали тестировщики до этого?Тестировали другие _известные_ дырки, очевидно же =)
>2 А то что у пользователь изза этой дыры может за два
>месяца "реально попасть на бабки" ничего?Каким образом?
Если инфу о дырке не раскрывать, то под неё не напишут эксплоит.
Здесь идет разговор про те случаи, когда кто-то один нашел дыру, а другие её не нашли.
>Каким образом?
>Если инфу о дырке не раскрывать, то под неё не напишут эксплоит.Вы правда думаете, что уязвимость может только кто то один найти?
>Здесь идет разговор про те случаи, когда кто-то один нашел дыру, а
>другие её не нашли.1 Система все равно будет скомпрометирована, стало быть всем системам зависящим от нее уже не будет доверия.
2 В большинстве случаев уязвимость обнаруживает несколько разных людей, вопрос лишь кто будет первым и кто использует уязвимость в своих целях.
>Каким образом?
>Если инфу о дырке не раскрывать, то под неё не напишут эксплоит.Вы правда думаете, что уязвимость может только кто то один найти?
>Здесь идет разговор про те случаи, когда кто-то один нашел дыру, а
>другие её не нашли.1 Система все равно будет скомпрометирована, стало быть всем системам зависящим от нее уже не будет доверия.
2 В большинстве случаев уязвимость обнаруживает несколько разных людей, вопрос лишь кто будет первым и кто использует уязвимость в своих целях.
Допустим, проект крупный, и только полностью пересобирается почти сутки. Допустим, ошибка найдена в ряде веток, которые еще поддерживаются, штук пять, скажем. Их все надо проверить отдельно, проверить, нет ли индивидуальных особенностей в каждой. Пересобрать. Проверить, что дырка закрыта. Выдать тестировщикам, дабы они проверили, что этот патч ничего не поломал другого, если поломал, разобраться, починить, снова пересобрать и снова проверить. Это легко может растянуться в недели. Добавляем сюда форс-мажоры, типа, ответственный за подсистему находится в отпуске или в командировке, или проблема более серьезная архитектурная, прочий резерв времени - так верхняя граница и получится.
>Тем более монструозные платформы не
>имеют даже доли устойчивости реальных динозавровСкажите это крупным корпорациям.
"Юзайте программы типа echo, cat, grep, head, tail через конвейер" =)
В некоторых случаях программы сложны и огромны не от скуки программистов.
Уточняю: не во всех случаях, а в некоторых.
>Скажите это крупным корпорациям.
>"Юзайте программы типа echo, cat, grep, head, tail через конвейер" =)Да! %) Даёшь Корпоративный Конвейер: http://www.opennet.ru/openforum/vsluhforumID10/4649.html#1 ! Чем длиннее, тем корпоративнее.
>В некоторых случаях программы сложны и огромны не от скуки программистов.
>Скажите это крупным корпорациям.
>"Юзайте программы типа echo, cat, grep, head, tail через конвейер" =)
>В некоторых случаях программы сложны и огромны не от скуки программистов.
>Уточняю: не во всех случаях, а в некоторых.Да, считающему себя программистом обычно скучать некогда, если других способов борьбы с ошибками он не знает, кроме как вставлять в код "побольше проверок", не задумываясь даже толком, откуда он сам берет условия для этих проверок.
В результате даже для элементарных вещей у него получается длинный-длинный код, который он уже сам потом с трудом отлаживает.
Зато такую работу вместо компьютера он считает "трудолюбием". См. в начале темы.
ну тут так если бы платили за приватные баги и по качественное было бы..А так в принципе что позже что раньше без разницы. Нет профита
Неоднократно наблюдал, когда security team в Debian или Red Hat правили уязвимости раньше, чем разработчики, причем значительно раньше, на месяц и более.
>Неоднократно наблюдал, когда security team в Debian или Red Hat правили уязвимости
>раньше, чем разработчики, причем значительно раньше, на месяц и более.В альте, как и в OpenBSD, нередко бывали случаи "у нас эта дырка не работает" -- по той причине, что либо заткнуто в ходе аудита, либо вообще переписано начисто. :) (или как вариант -- отключено по умолчанию, при включении слушает только 127.0.0.1)
Что не помешало RedHat-у внести в репы firefox 3.6.4 лишь совсем недавно. До этого там долго и основательно жил мамонт чрезвычайно почтенного возраста.
>Что не помешало RedHat-у внести в репы firefox 3.6.4 лишь совсем недавно.
>До этого там долго и основательно жил мамонт чрезвычайно почтенного возраста.Что именно не помешало?
Судя по контексту вы отождествляете "правку уязвимостей" с "внесением в репы" нового пакета.
А неиспользование последних версий - это по-вашему тоже самое, что и уязвимость.
>
>Что не помешало RedHat-у внести в репы firefox 3.6.4 лишь совсем недавно.
>До этого там долго и основательно жил мамонт чрезвычайно почтенного возраста.
>В Debian Sid вчера вечером ещё был firefox, пардон, iceweasel 3.5.11.. Не все куда-то спешат ;)
Предлагаемый гуглом метод попахивает шантажом. А кто-нибудь из кретинов именно так его и поймёт и сделает на этом акцент где-нибуть в суде.
>Предлагаемый гуглом метод попахивает шантажом.А когда дыру зарепортили но за годы так и не было починено и в итоге все пришло к тому что через эту дыру хаксоры набрали некислый ботнет и завалили все вокруг спамом - это попахивает преступной халатностью. Пусть виновные оплатят паразитную нагрузку на сервера? :) Учтя что 90% почты - спам, виновные должны разориться нахрен, оплачивая 90% стоимости работы почтовых серверов во всем мире.
full disclosure работает в данном случае лучше предложенного, ИМХО. По крайней мере в opensource. Если разработчик не шевелится, то хоть кто-то патч напишет. А в случае с проприетарщиной нефига этих маргиналов в принципе информировать. Надо юзать их дыры и все дела :) ... ах да. Если что - в суд их за драные продукты. :)
Предлагаю дополнение.
Если руководитель отказывается реагировать на запрос, или если истек срок, пойти другим путем.
Отправляете информацию об ошибке разработчикам, или даже сообществу.
На форумах, в списках рассылки и т.д.
Возможно кто-то из разработчиков исправит ошибку по своей инициативе.
Если никто не откликнулся, публиковать на весь интернет.
А почему административные грабли какой-то конторки/команды/... должны парить кого-то вне этой конторы вообще? В обязанности исследователей безопасности не должно входить наведение порядка в работе команд/контор. Это совершенно ненужный им геморрой который не оплачивается. Вариантов есть два: или зарепортить дыру просто, почетно и вознаграждается, или дыра будет слита на черный рынок, пардон. Потому что это относительно просто и вознаграждается. Далее те кто делают софт сами решают как они предпочитают.