The OpenNET Project / Index page

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

Google предлагает переосмыслить подход к раскрытию информации об уязвимостях

23.07.2010 07:19

В официальном блоге компании Google, посвященном вопросам безопасности, опубликована статья, в которой участники Google Security Team излагают свои соображения по вопросу раскрытия информации об уязвимостях, обнаруженных в программном обеспечении. Основным приоритетом при выборе политики раскрытия подобной информации сотрудники команды безопасности Google полагают защищенность конечного пользователя.

В настоящее время можно выделить два ключевых подхода к раскрытию такой информации:

  • Ответственное раскрытие (responsible disclosure). При таком подходе исследователь, обнаруживший уязвимость, уведомляет о ней только производителя уязвимого программного обеспечения, скрывая информацию от общественности. Очевидным достоинством этого подхода является то, что производителю предоставляется возможность выпустить исправления раньше, чем уязвимость начнет массово использоваться злоумышленниками.
  • Полное раскрытие (full disclosure). При данном подходе исследователь, после обнаружения им уязвимости, публикует в открытом доступе всю информацию о ней. Основным достоинством данного подхода является наличие для производителя стимула выпустить исправление как можно скорее.

Подробную аргументацию за и против для каждого из этих подходов можно прочитать в статье Брюса Шнайера, датируемой еще 2001 годом. Однако команду безопасности Google больше интересует, какой подход является более эффективным для защиты конечного пользователя сейчас, в 2010 году.

В настоящее время наиболее распространенным является подход ответственного раскрытия, однако участники Google Security Team подчеркивают, что эта концепция в чистом виде часто не может обеспечить эффективной защиты конечного пользователя. Нередки случаи, когда производитель откладывает эксклюзивную информацию об уязвимостях «в долгий ящик», не выпуская исправлений месяцами, а то и годами. В то же время, исследователи в области безопасности, не связывающие себя соображениями профессиональной этики («серые» и «черные шляпы») могут обнаружить эти уязвимости, пользуясь теми же знаниями и инструментами, что и «белые шляпы» (добросовестные исследователи, честно уведомившие производителя о проблеме). Таким образом, обнаруженная уязвимость нулевого дня начинает активно эксплуатироваться теневыми кругами, в то время как производитель, не знающий об этом, считает вопрос устранения уязвимости не приоритетным.

В качестве профилактики подобных ситуаций, авторы статьи предлагают использование комбинированного подхода, сочетающего достоинства обоих изложенных выше методов. При таком подходе, изначально об уязвимости уведомляется только производитель. Однако, в отличие от ответственного раскрытия, устанавливается некоторый срок, по истечении которого информация об уязвимости должна быть открыта широкой общественности. Разумеется, производитель уведомляется об этом условии, и как раз оно и должно стимулировать его выпустить исправления в разумные сроки. Авторы статьи полагают, что в качестве верхней границы такого срока можно принять 60 дней. Конкретный выбор срока в каждом случае производится с учетом таких факторов, как сложность устранения уязвимости, оценочные сроки распространения исправленной версии и т.п. Также срок может быть резко сокращен, если стало известно, что «черные шляпы» уже владеют этой информацией. В случае, если производитель отказывается рассматривать проблему, информация публикуется немедленно.

Именно такой подход команда безопасности Google намерена отныне использовать в своей работе. Также, ее сотрудники готовы к тому, что подобный подход будет использоваться и в отношении Google, как производителя программного обеспечения. Более того, они призывают всех «белых шляп» последовать их примеру — чем шире распространится такой подход, тем лучше будут защищены конечные пользователи, считают сотрудники Google Security Team.

  1. Главная ссылка к новости (http://googleonlinesecurity.bl...)
Автор новости: Sergey Ptashnick
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/27392-google
Ключевые слова: google, security
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (77) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 09:01, 23/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    К сожалению работает только full disclosure, посмотрите последние выпуски PHP и Firefox, в PHP поправили дыры о которых приватно сообщили в мае, а в Firefox - в марте. Одновременно в Firefox почти мгновенно поправили дыру о которой стало известно публично.
     
     
  • 2.7, ВДНХ (?), 09:59, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > К сожалению работает только full disclosure, посмотрите последние выпуски PHP и Firefox, в PHP поправили дыры о которых приватно сообщили в мае, а в Firefox - в марте. Одновременно в Firefox почти мгновенно поправили дыру о которой стало известно публично.

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

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

    Как это можно наблюдать с PHP.

     
     
  • 3.9, klalafuda (?), 10:16, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    s/PHP/руками/g

    В руках мастера и палочки - оружие. Обезьяна же на танке безопасна.

     
     
  • 4.12, ВДНХ (?), 10:29, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >s/PHP/руками/g
    >
    >В руках мастера и палочки - оружие. Обезьяна же на танке безопасна.

    Да, если выбора не оказалось в конкретный момент.
    Однако, если выбор есть, то хороший мастер выбирает хороший инструмент.

    Хотя, я так понял, вы согласны со мной относительно низкого качества PHP.

    А сравнивать палочки и танк по качеству - нелогично. Вы явно путаете качество с размером и назначением.
    Могут быть качественные палочки и некачественный танк.

     
     
  • 5.14, klalafuda (?), 10:44, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • –7 +/

    Нет, Вы неправильно меня поняли. Я не согласен с Вами по поводу 'низкого качества PHP'. Это точно такой же инструмент, как и все остальные. Perl, Python, Ruby, you name. Ни чем от них не отличающийся. По крайней мере с точки зрения 'качества'.

    Поясню проще: с умом можно разрабатывать качественные продукты на любом из них. Кривыми же руками можно испортить абсолютно все, что угодно. И абстрактное 'качество' приведенного в качестве примера PHP тут совершенно не причем. Не стоит списывать дремучую некомпетентность отдельных конечных пользователей на проблемы инструмента.

     
     
  • 6.19, ВДНХ (?), 11:00, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +4 +/
    То, что вы ставите в одну линию PHP, Perl, Python и Ruby по качеству архитектуры... большой текст свёрнут, показать
     
     
  • 7.54, Crazy Alex (??), 16:05, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да понятно, что PHP не без недостатков, но всё же это далеко не бейсик.
    Писать на нём хорошо можно, он этому не мешает особо. Не навязывает - это да, но не мешает.
    Если, конечно, вы не PHP3 имеете в виду, с register_globals, magic quotes, без ООП и пространств имён.
     
     
  • 8.56, ВДНХ (?), 16:36, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну если вы можете сравнить только с бейсиком - то конечно Писать и на бумаге хо... большой текст свёрнут, показать
     
  • 6.29, Аноним (-), 12:22, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Поясню проще: с умом можно разрабатывать качественные продукты на любом из них. >Кривыми же руками можно испортить абсолютно все, что угодно. И абстрактное
    >'качество' приведенного в качестве примера PHP тут совершенно не причем. Не стоит
    >списывать дремучую некомпетентность отдельных конечных пользователей на проблемы >инструмента.

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

     
  • 6.41, Michael Shigorin (ok), 14:04, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >PHP [...] Perl, Python, Ruby, you name. Ни чем от них не отличающийся.
    >По крайней мере с точки зрения 'качества'.

    Как полагаете -- руки, которыми такое пишется, как можно назвать?.. :(

    PS: такое ощущение, что выгорели и устали от проблем "здеся".  Не переживайте, тоже порой бывает, но в итоге когда понимаешь, что диагностируемость всё-таки милее -- всё возвращается на круги своя :)

     
  • 4.46, User294 (ok), 14:30, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Обезьяна же на танке безопасна.

    А как насчет обезьяны с гранатой? :)


     
     
  • 5.72, XoRe (ok), 20:43, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну если рассуждать с научной точки зрения, то вероятность того, что она грамотно... большой текст свёрнут, показать
     
     
  • 6.81, ВДНХ (?), 09:59, 24/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Итак, речь шла о факторах, влияющих на количество багов в проектах и мерах их пр... большой текст свёрнут, показать
     
  • 3.10, Аноним (-), 10:23, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Почему не вижу ? Не вижу только до выхода исправленной версии. Как только версия вышла обычно можно отследить историю определения дыр. И в самих advisory обычно приводится лог, дыра найдена тогда-то, тогда-то сообщено разработчикам, тогда-то поправлено, тогда-то информация придана огласке.
     
     
  • 4.13, ВДНХ (?), 10:34, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Почему не вижу ?

    Потому что у вас упрощенный и идеализированный взгляд на мир.

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

    А кто вам сказал, что все придается огласке?

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

     
     
  • 5.50, ВДНХ (?), 15:19, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Если цивилизованный способ сообщать об ошибках разработчикам, не придавая ошибки огласке. Тем не менее все довольны.

    ^Есть^ цивилизованный способ сообщать об ошибках разработчикам, не придавая ошибки огласке. Тем не менее все довольны.


     
     
     
    Часть нити удалена модератором

  • 7.85, XoRe (ok), 14:28, 24/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Это хорошо, если подробно объясняется А вы можете спорить с человеком, не стара... большой текст свёрнут, показать
     
     
  • 8.88, ВДНХ (?), 15:10, 24/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Я вообще-то говорил о зависимости количества багов от качества проектирования А... большой текст свёрнут, показать
     
  • 2.47, User294 (ok), 14:32, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >К сожалению работает только full disclosure,

    А он вообще очень полезное лекарство от раздолбайства. ИМХО гугл дело говорит - должен ставиться максимальный срок реакции. Нет реакции? Получите сплойты, будет стимул быстро реагировать.

     

  • 1.2, klalafuda (?), 09:16, 23/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/

    Дело за малым: заставить пользователей конкретного продукта в массовом порядке своевременно накатывать соответствующие обновления безопасности. Иначе это все борьба с ветряными мельницами.
     
     
  • 2.3, klalafuda (?), 09:19, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/

    PS: Да, и, если уж ставить себе глобальную задачу бороться за мир во всем мире, отучить пользователей качать всякую дрянь из сети. В противном случае, не смотря на все потуги, конечный результат будет все равно один и тот же. А интересует лишь конечный результат.
     
     
  • 3.35, ВДНХ (?), 13:08, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И в чем суть вашего сарказма Вы описали то, что существует, так, какбудто этого... большой текст свёрнут, показать
     
     
  • 4.52, klalafuda (?), 15:26, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Применительно конкретно к браузерам этого нет Достаточно взглянуть на статы use... большой текст свёрнут, показать
     
     
  • 5.53, ВДНХ (?), 15:41, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Чего именно _этого_ нет И как один умрем в борьбе за _это_ Вы, собственно чт... большой текст свёрнут, показать
     
     
  • 6.55, klalafuda (?), 16:14, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Неидеально - это как бы это сказать, это несколько смазано Я бы сказал чуть точ... большой текст свёрнут, показать
     
     
  • 7.58, ВДНХ (?), 17:16, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    В исходном посте вы говорили так, как будто автообновления вообще не существует ... большой текст свёрнут, показать
     
     
  • 8.59, klalafuda (?), 17:44, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Повторю свой вопрос у Вас будут какие-то конкретные технические предложения по ... текст свёрнут, показать
     
     
  • 9.62, ВДНХ (?), 18:14, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Если вы хотите услышать конкретные технические предложения, сформулируйте ваши в... большой текст свёрнут, показать
     

  • 1.4, koblin (ok), 09:23, 23/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –13 +/
    Желание гугла понятно - иметь неограниченно большое время на исправление уязвимостей, чтобы никуда не торопясь попивая мохито пол года писать патч. Только причем тут интересы пользователей?!
     
     
  • 2.8, ВДНХ (?), 10:05, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Желание гугла понятно - иметь неограниченно большое время на исправление уязвимостей, чтобы никуда не торопясь попивая мохито пол года писать патч.

    Желание создателей и владельцев Гугла - максимально извлекать выгоду, благодаря своим талантам и способностям. Никуда не торопясь. Это их право и заслуга.

    > Только причем тут интересы пользователей?!

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

     
  • 2.18, Lain_13 (?), 10:59, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ты статью точно читал дальше первого абзаца?
     

  • 1.5, filosofem (ok), 09:29, 23/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    И что в этой демагогии нового, чего мы как бы не знали и не практиковали?
     
     
  • 2.26, Lain_13 (?), 11:25, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это рекомендация мировому сообществу от всемирно известной корпорации. Этим и раньше пользовались, просто они обращают всеобщее внимание на то, какой метод сообщения об ошибках по их мнению лучше. Когда рекомендацию даёт некто Василий Пупких в своём ЖЖ, то его ни кто не замечает, а к Гуглу может и прислушаются. Тем более, что они готовы не словом, а делом доказать работоспособность такого подхода.
     
  • 2.28, Michael Shigorin guest (?), 11:48, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Хм, а можно поинтересоваться, что именно _Вы_ как security researcher практикуете и в чём это выражается?
     
     
  • 3.33, filosofem (ok), 12:59, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Поинтересоваться можно. Кто же вам запретит?
     
     
  • 4.42, Michael Shigorin (ok), 14:12, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Поинтересоваться можно. Кто же вам запретит?

    Тогда представьте список найденных и отрепорченных Вами уязвимостей, пожалуйста.

     
     
  • 5.44, filosofem (ok), 14:17, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Может быть еще ключ от квартиры где девки визжат?
     
     
  • 6.90, Michael Shigorin (ok), 17:21, 24/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Может быть еще ключ от квартиры где девки визжат?

    Полагаю, его у Вас тоже нет. :)

     

  • 1.6, Аноним (-), 09:40, 23/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Давать срок три дня и разглашать всю информацию.
     
     
  • 2.15, splat_pack (ok), 10:44, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +4 +/
    та не, 2 часа достаточно..
     
  • 2.34, filosofem (ok), 13:07, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Почему именно 3 дня? Правда интересно откуда такая цифра появилась.
     

  • 1.16, SaveMeGood (??), 10:58, 23/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Всегда удивляло (скорее даже бесило) когда люди нагло и бесстыжи прикрываются заботой о тебе, делая что либо с выгодой для себя. Мол, "я думал ты устал с работы хочешь отдохнуть и решил, что занесу долг в другой раз"...
     
     
  • 2.20, Lain_13 (?), 11:06, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Открывать информацию о дыре по-принципу полного раскрытия не этично в первую очередь по-отношению к другим пользователям. Сообщая разработчику информацию приватно с условием полного раскрытия через установленный срок этично по-отношению ко всем. Если разработчики не исправят, то это будет уже лишь их и только их вина, а если исправят и выпустят обновление, то раскрытие информации о уязвимости уже мало кому повредит.
     

  • 1.21, Maris (?), 11:09, 23/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    В подходе "Полное раскрытие" упустили еще одно очень важное достоинство. Имея информацию о уязвимости любой пользователь сможет защитить сам себя. Если уязвимость на столько сложная что на исправление уйдет много времени, то пользователь может не использовать возможности программного обеспечения подверженные данной уязвимости, или вовсе на время использовать альтернативное ПО, если такова имеется. Согласен что не очень выгодный вариант для производителя, но это надо рассматривать если говорить о защищенность конечного пользователя.
     
     
  • 2.24, Lain_13 (?), 11:21, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    В случае простой уязвимости и срок будет на её решение установлен короткий (всё зависит от нашедшего, естественно), а сложную не только хрен ещё кто найдёт, так потом ещё и хрен использует. Например, баги с переполнением стека в разном софте часто находят, вот только не всегда дело даже до proof of concept вызывающий крэш доходит и дыра так и остаётся лишь потенциальной, а ведь использовать его для запуска своего кода ещё сложнее.
     
  • 2.36, filosofem (ok), 13:12, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >В подходе "Полное раскрытие" упустили еще одно очень важное достоинство. Имея информацию
    >о уязвимости любой пользователь сможет защитить сам себя. Если уязвимость на
    >столько сложная что на исправление уйдет много времени, то пользователь может
    >не использовать возможности программного обеспечения подверженные данной уязвимости, или вовсе на
    >время использовать альтернативное ПО, если такова имеется. Согласен что не очень
    >выгодный вариант для производителя, но это надо рассматривать если говорить о
    >защищенность конечного пользователя.

    Пользователю достаточно сообщить, что уязвимость имеется и чем (не )?надо пользоваться, чтобы не нарваться. "Полного раскрытия" уязвимости для этого не нужно.

     
  • 2.43, Michael Shigorin (ok), 14:17, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >В подходе "Полное раскрытие" упустили еще одно очень важное достоинство.
    >Имея информацию о уязвимости любой пользователь сможет защитить сам себя.

    Не любой, а достаточно квалифицированный и притом заинтересованный в срочнейшем решении очередной вылезшей проблемы.

    Скажем, недавно пробегала информация по libtiff.  Слегка припоминая характер внутренностей и прошлых пачей по тамошним buffer/integer overflow'ам, решил не рыпаться да подождать, пока апдейт приедет -- хотя если бы действительно было критично, то можно было бы напрячься и вспомнить/доразучить си в нужном объёме.

     

  • 1.27, i (??), 11:40, 23/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    60 дней это слишком много, 7 ну максимум. А лучше 3
     
     
  • 2.30, Аноним (-), 12:28, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >60 дней это слишком много, 7 ну максимум. А лучше 3

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

     
     
  • 3.31, i (??), 12:41, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    что можно исправлять ДВА месяца? не понимаю. Ну пару дней ещё пока заплатка по юзерам разойдется, ладно.
     
     
  • 4.32, Lain_13 (?), 12:54, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Жирные архитектурные косяки, что же ещё?
     
  • 4.38, fr0ster (ok), 13:36, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Неизвестнуюю массам дыру не закроют быстро. Ибо зачем, все равно никто не знает:) можно ничегометр встроить лишний.
     
  • 4.84, XoRe (ok), 14:24, 24/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >что можно исправлять ДВА месяца? не понимаю. Ну пару дней ещё пока
    >заплатка по юзерам разойдется, ладно.

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

     
     
  • 5.89, fr0ster (ok), 15:18, 24/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    1 А что делали тестировщики до этого?
    2 А то что у пользователь изза этой дыры может за два месяца "реально попасть на бабки" ничего?
    Так что такие 2 месяца способстыуют снижению доверия к софту, бог с ним с приетарным, но ведь и СПО обсирается
     
     
  • 6.91, Michael Shigorin (ok), 17:22, 24/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >снижению доверия к софту

    Вы доверяете _софту_???

    PS: я -- нет, только людям.

     
  • 6.92, Аноним (-), 21:32, 24/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    то есть, если уязвимость через два дня откроют, то у юзера меньше возможностей попасть на бабки, нежели подробности уязвимости станут известны через 60-ят дней?
     
     
  • 7.93, fr0ster (ok), 05:03, 25/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >то есть, если уязвимость через два дня откроют, то у юзера меньше
    >возможностей попасть на бабки, нежели подробности уязвимости станут известны через 60-ят
    >дней?

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

     
     
  • 8.100, XoRe (ok), 17:23, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, блин, мы говорим и про обычных домашних юзеров тоже Они ни за чем ни следят... текст свёрнут, показать
     
     
  • 9.106, fr0ster (ok), 19:03, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Заражение вирусом машин хомячков одного провайдера с образованием ботнета привед... текст свёрнут, показать
     
  • 6.99, XoRe (ok), 17:22, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >1 А что делали тестировщики до этого?

    Тестировали другие _известные_ дырки, очевидно же =)

    >2 А то что у пользователь изза этой дыры может за два
    >месяца "реально попасть на бабки" ничего?

    Каким образом?
    Если инфу о дырке не раскрывать, то под неё не напишут эксплоит.
    Здесь идет разговор про те случаи, когда кто-то один нашел дыру, а другие её не нашли.

     
     
  • 7.104, fr0ster (ok), 18:59, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Каким образом?
    >Если инфу о дырке не раскрывать, то под неё не напишут эксплоит.

    Вы правда думаете, что уязвимость может только кто то один найти?

    >Здесь идет разговор про те случаи, когда кто-то один нашел дыру, а
    >другие её не нашли.

    1 Система все равно будет скомпрометирована, стало быть всем системам зависящим от нее уже не будет доверия.
    2 В большинстве случаев уязвимость обнаруживает несколько разных людей, вопрос лишь кто будет первым и кто использует уязвимость в своих целях.

     
  • 7.105, fr0ster (ok), 19:01, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Каким образом?
    >Если инфу о дырке не раскрывать, то под неё не напишут эксплоит.

    Вы правда думаете, что уязвимость может только кто то один найти?

    >Здесь идет разговор про те случаи, когда кто-то один нашел дыру, а
    >другие её не нашли.

    1 Система все равно будет скомпрометирована, стало быть всем системам зависящим от нее уже не будет доверия.
    2 В большинстве случаев уязвимость обнаруживает несколько разных людей, вопрос лишь кто будет первым и кто использует уязвимость в своих целях.

     
  • 4.94, nuclight (ok), 00:10, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Допустим, проект крупный, и только полностью пересобирается почти сутки. Допустим, ошибка найдена в ряде веток, которые еще поддерживаются, штук пять, скажем. Их все надо проверить отдельно, проверить, нет ли индивидуальных особенностей в каждой. Пересобрать. Проверить, что дырка закрыта. Выдать тестировщикам, дабы они проверили, что этот патч ничего не поломал другого, если поломал, разобраться, починить, снова пересобрать и снова проверить. Это легко может растянуться в недели. Добавляем сюда форс-мажоры, типа, ответственный за подсистему находится в отпуске или в командировке, или проблема более серьезная архитектурная, прочий резерв времени - так верхняя граница и получится.
     
     
     
     
     
    Часть нити удалена модератором

  • 8.101, XoRe (ok), 17:26, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Скажите это крупным корпорациям Юзайте программы типа echo, cat, grep, head, t... текст свёрнут, показать
     
     
  • 9.102, Andrey Mitrofanov (?), 18:36, 26/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да Даёшь Корпоративный Конвейер http www opennet ru openforum vsluhforumI... текст свёрнут, показать
     
  • 9.114, ВДНХ (ok), 10:30, 27/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да, считающему себя программистом обычно скучать некогда, если других способов б... текст свёрнут, показать
     

  • 1.37, Аноним (-), 13:14, 23/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ну тут так если бы платили за приватные баги и по качественное было бы..

    А так в принципе что позже что раньше без разницы. Нет профита

     
  • 1.39, uldus (ok), 13:36, 23/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Неоднократно наблюдал, когда security team в Debian или Red Hat правили уязвимости раньше, чем разработчики, причем значительно раньше, на месяц и более.
     
     
  • 2.45, Michael Shigorin (ok), 14:19, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Неоднократно наблюдал, когда security team в Debian или Red Hat правили уязвимости
    >раньше, чем разработчики, причем значительно раньше, на месяц и более.

    В альте, как и в OpenBSD, нередко бывали случаи "у нас эта дырка не работает" -- по той причине, что либо заткнуто в ходе аудита, либо вообще переписано начисто. :) (или как вариант -- отключено по умолчанию, при включении слушает только 127.0.0.1)

     
  • 2.57, klalafuda (?), 16:47, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/

    Что не помешало RedHat-у внести в репы firefox 3.6.4 лишь совсем недавно. До этого там долго и основательно жил мамонт чрезвычайно почтенного возраста.
     
     
  • 3.60, ВДНХ (?), 17:45, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Что не помешало RedHat-у внести в репы firefox 3.6.4 лишь совсем недавно.
    >До этого там долго и основательно жил мамонт чрезвычайно почтенного возраста.

    Что именно не помешало?
    Судя по контексту вы отождествляете "правку уязвимостей" с "внесением в репы" нового пакета.
    А неиспользование последних версий - это по-вашему тоже самое, что и уязвимость.

     
  • 3.69, Bod (??), 20:06, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >
    >Что не помешало RedHat-у внести в репы firefox 3.6.4 лишь совсем недавно.
    >До этого там долго и основательно жил мамонт чрезвычайно почтенного возраста.
    >

    В Debian Sid вчера вечером ещё был firefox, пардон, iceweasel 3.5.11.. Не все куда-то спешат ;)

     

  • 1.61, Аноним (-), 17:47, 23/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Предлагаемый гуглом метод попахивает шантажом. А кто-нибудь из кретинов именно так его и поймёт и сделает на этом акцент где-нибуть в суде.
     
     
  • 2.68, User294 (ok), 19:19, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Предлагаемый гуглом метод попахивает шантажом.

    А когда дыру зарепортили но за годы так и не было починено и в итоге все пришло к тому что через эту дыру хаксоры набрали некислый ботнет и завалили все вокруг спамом - это попахивает преступной халатностью. Пусть виновные оплатят паразитную нагрузку на сервера? :) Учтя что 90% почты - спам, виновные должны разориться нахрен, оплачивая 90% стоимости работы почтовых серверов во всем мире.

     
     
  • 3.70, Аноним (-), 20:25, 23/07/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    full disclosure работает в данном случае лучше предложенного, ИМХО. По крайней мере в opensource. Если разработчик не шевелится, то хоть кто-то патч напишет. А в случае с проприетарщиной нефига этих маргиналов в принципе информировать. Надо юзать их дыры и все дела :) ... ах да. Если что - в суд их за драные продукты. :)
     

  • 1.74, XoRe (ok), 20:54, 23/07/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Предлагаю дополнение.
    Если руководитель отказывается реагировать на запрос, или если истек срок, пойти другим путем.
    Отправляете информацию об ошибке разработчикам, или даже сообществу.
    На форумах, в списках рассылки и т.д.
    Возможно кто-то из разработчиков исправит ошибку по своей инициативе.
    Если никто не откликнулся, публиковать на весь интернет.
     
     
  • 2.87, User294 (ok), 14:55, 24/07/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А почему административные грабли какой-то конторки/команды/... должны парить кого-то вне этой конторы вообще? В обязанности исследователей безопасности не должно входить наведение порядка в работе команд/контор. Это совершенно ненужный им геморрой который не оплачивается. Вариантов есть два: или зарепортить дыру просто, почетно и вознаграждается, или дыра будет слита на черный рынок, пардон. Потому что это относительно просто и вознаграждается. Далее те кто делают софт сами решают как они предпочитают.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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