The OpenNET Project / Index page

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



Индекс форумов
Составление сообщения

Исходное сообщение
"В Firefox 67.0.4 и 60.7.2 устранена ещё одна 0-day уязвимост..."
Отправлено Ordu, 22-Июн-19 20:19 
>[оверквотинг удален]
> браузеров, это одному человеку нереально.
> Собственно, сандбоксы и прочие режимы строгой изоляции - это "капитуляция перед неизвестностью"
> примерно того же рода, что упомянутый мной запуск браузера из под
> отдельного пользователя.
> Вопрос собственно в том, почему статистику мы должны ставить выше прочих знаний
> о программе. В то время как статистика уязвимостей - это результат
> всего того, что происходит с проектом и только.
> Всего - не
> только внутреннего устройства и архитектуры, а вообще, всего, в т.ч. популярности
> программы и социальной ситуации вокруг неё.

В дискуссии на опеннете ссылаться на процесс разработки? С точки зрения опеннета, это детская наивность и безнадёжно теоретическое философствования. Но процесс разработки -- это скорее о long term перспективах проекта. Процесс разработки не может изменить ситуацию с багами кардинально. При этом крайне сложно предсказать вещи типа "firefox активно используется в Coinbase, и поэтому атака на него может принести кучу бабла, которое легко отмыть".

Не, я согласен с тем, что учитывать надо как можно больше информации. Но это не бесплатно. Это одна из тех истин, о которой, на мой взгляд, забыл Фридман запиливая свою экономическую теорию поверх "рациональных ожиданий", которые направляют действия игроков на рынке. Учёт всё большего и большего объёма информации небесплатен, он требует времени, скилла, и возможно других ресурсов. Это то, что крупным организациям даётся гораздо лучше мелких и тем более лучше чем индивидуалам. Чтобы учесть всю доступную информацию по firefox'у и по chrome'у, чтобы сравнить их, потребуется нанять нескольких человек (или несколько десятков?), с тем чтобы они полгода или год наблюдали бы за происходящим и вообще всячески собирали бы информацию. Спорили бы о структуре причинно-следственного графа, вероятно даже проводили бы специальные исследования, чтобы эту структуру выяснить. Это за пределами моих финансовых возможностей. Но даже если бы я мог бы такое сделать, я бы скорее всего не стал бы, потому что я вряд ли получу что-то существенное в результате. Всё что я получу -- это то, что если ситуация изменится, то я узнаю об этом, допустим, на полгода раньше. С какой вероятностью за эти полгода я пострадаю от уязвимости в браузере? Точнее даже не так, если я на полгода раньше сменю браузер, то насколько я снижу вероятность пострадать от уязвимости за эти полгода? Каковы ожидаемые потери, если я пострадаю? Помножаем разницу в вероятностях на потери, сравниваем с затратами на исследование, и задаём вопрос: стоит ли оно того?

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

> Если я сейчас напишу браузер, у него будет 100% хорошая история уязвимостей,
> хотя очевидно, что он будет дыряв (на самом деле, он будет
> убог, да и вообще я не напишу браузер, но это мысленный
> эксперимент).

Ну да. Это о недостаточной статистической значимости. Это если вероятность того, что кто-то будет искать баг настолько низка, то чтобы судить по статистике багов о бажности кода, потребуются тысячи лет накопления статистики. Но firefox не таков, его история тянется назад в начало 90-х, и за эту историю были серьёзные изменения и в команде разработчиков, и в принципах построения процесса разработки, и в положении дел на "рынке" браузеров.

>> Нет, ты хоть что мне говори, но это всё очень похоже на стандартную эпистемологическую панику технаря, который в кои то веки столкнулся с реально сложной проблемой.
> Всё может быть. Мне же кажется, что ты пытаешься рационализировать выбор ff
> в качестве своего браузера.

Нет. Я его выбираю не из-за багов. Мне нравится позиция Mozilla, мне нравится то, что Mozilla делает. Я в частности фанат rust'а. Я вижу активное развитие ff, которое темпами своими превосходит всё, что можно было бы ожидать от проекта такого возраста. Google со всеми его миллиардами не может сравниться темпами разработки браузера с Mozilla. А процесс разработки? Да Mozilla вывела FOSS на совершенно новый уровень, и если кому-то хочется вести FOSS проект, то ему следует изучить то, как Mozilla это делает, и перенять если не всё, то большую часть того.

Я говорю о именно статистике багов, потому что:

а) об этом разговор: если ты вернёшься в начало треда, ты увидишь там что он начался именно с этой статистики; придерживаться темы дискуссии -- это правило хорошего тона. То есть я допускаю возможность смены темы и ухода в сторону, но... я не могу это объяснить, у меня есть чувство прекрасного по отношению к дискуссии, и оно мне подсказывает когда и как можно менять тему, а когда нет. Как это чувство работает я пока не понял.

б) все остальные известные мне факты о mozilla и firefox, кроме статистики, мало говорят о вероятности ещё одного 0-day в ближайший месяц или год. Они скорее про long term предсказания.


> Талеба я очень котирую, да. Но всё же, чёрный лебедь - это
> неизвестное по своей сути событие, а уязвимость - известное.

А я не про уязвимость, как таковую, а про события меняющие статистические тренды. Вот взяли мы N точек и на основании них написали функцию, предсказывающую эти точки в будущем. Это будет работать, пока этой функции не придёт чёрный лебедь.

> А про то, что сами по себе числа ничего не
> говорят, их надо трактовать с учётом ситуации в и вокруг проекта.
> Иначе это просто бесполезные числа.

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

>[оверквотинг удален]
> того, что ты собираешься защищать. И от кого. Мне не важно,
> как у меня украдут банковские данные, например, мне важно, чтобы этого
> не произошло.
>> Индукция работает на удивление хорошо: если мы видим статистическую закономерность, которая выполняется некоторое время, то скорее всего она будет выполняться ещё некоторое время, мы можем на это полагаться. Да, там есть много граблей, на которые можно наступить, типа подгонки закономерности под данные, недостаточная статистическая значимость, и много-много других, наука имеет огромный опыт хождения по этим граблям
> Утверждаю, что на основе одной только статистичейской закономерности нельзя делать однозначный
> вывод о том, что событие и дальше будет повторяться и на
> это можно будет полагаться.
> Стрелки часов передвигаются снова и снова (отличная статистика), потом садится батарейка
> и всё заканчивается. Знание о батарейке помогло мне предсказать остановку стрелок,
> статистика не помогла им двигаться бесконечно.

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

Не, про батарейку знать полезнее, но тут мы возвращаемся к вопросу: что мы такого знаем про фф, что может изменить наши предсказания на основании статистики?

>> Но всё что я вижу на данный момент: неопределённость -- такая неопределённость, и как ни крути, но снизить риск в 0 невозможно. Я _знаю_, что снизить риск в ноль невозможно. Но между нулевым риском и стопроцентным риском, есть континуум промежуточных значений.
> Я предлагаю не оценивать риск наступления того или иного события (нахождение критической
> дыры), а исходить из того, что и от кого мы защищаем.
> Браузеры _по_умолчанию_ дырявы. Моя модель проще, а результат даёт как минимум
> такой же.

Твоя модель не говорит о том, каким браузером лучше пользоваться, если безопасность для нас имеет высокий приоритет. Мой способ принятия решения предлагает то же, что и твой -- всякие там контейнеры, кастомизированные сборки ff и зависимостей, кастомизация в about:config, аддоны режущие скрипты и cross-site запросы. Но помимо этого он предлагает ещё выбрать ff, вместо хрома, потому что в ff меньше багов находят.

> Одни развивают архитектуру в сторону безопасности и ведут исследования, другие копипастят.
> В одном случае экспертиза, накопление опыта и развитие кадров. Во втором
> - копипастинг. Грубо говоря.

Мозилла развивает массу своего уникального опыта -- они аж целый rust породили на этом. А в копипастинге есть свои плюсы: делать что-то по следам других проще, можно заранее видеть грядущие грабли.

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

Может быть, но мне приходится выуживать это "не единственное" из тебя клещами. Теперь я вижу два момента -- изоляция сайтов и копипастинг. Если их будет ещё штуки три, я возьму паузу на обдумывание: каждая из этих вещей в одиночку не может серьёзно изменить ситуацию, даже если я ошибаюсь с оценкой их влияния на реальность. Но если их будет пять штук, и ошибаться во всех случаях я буду одинаково сильно и в одну и ту же сторону, то тогда я ошибусь и с конечным выводом.

>> Да, это вполне валидный аргумент. Но я его предпочитаю игнорировать, потому что это не первое "революционное" изменение в chrome, нацеленное на повышение безопасности. Оно вполне укладывается в тренды постоянного повышения уровня защиты Chrome, и я не вижу как именно это изменение вдруг эти тренды сломает. Оно не выглядит для меня тем самым "чёрным лебедем", который нарушит статистику так, что (допустим) в течение года в хроме найдут меньше дыр чем в ff.
> Статистика нахождения дыр в chrome, как по мне, в значительно бОльшей степени
> связана с его бОльшей популярностью и как следствие бОльшей привлекательностью как
> цели для атаки.
> Для сравнения такой статистики (и не только) сильно желателен паритет в доле
> инсталляций.

Я скажу ещё раз: мне не столь интересно количество дыр в коде, сколь интересна частота нахождения дыр. Реальная частота нахождения дыр, а не какая-то теоретически возможная.

>> Что может изменить положение дел -- это резкий рост популярности ff, который приведёт к повышению активности поиска дыр в ff. Но это то, чего мы не наблюдаем.
> А стоило бы, потому что иначе ff рискует вообще загнуться.

Не спорю. И это тема для совершенно другого разговора.

> Это уже схоластика. Я ничего не имею против Джуда Перла и его
> трудов, но имею против их применимости для решения обсуждаемого вопрса.

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

>> Во-вторых, не обязательно считать вероятности. Очень часто их можно сравнить между собой не высчитывая. И очень часто знания того, какая вероятность больше, а какая меньше, достаточно для принятия решения.
> Повторюсь: если мы хотим защититься, считать вероятность возникновения дыры в том или
> ином браузере не нужно, это чёрная магия и вангование. Нужно защищать
> то, что тебе важно.

Да никто же не спорит. Но тут встаёт вопрос: что делать? Как защищать? Выдернуть сетевой шнур?

>> В век, когда вокруг нас начинают появляться реально сложные устройства, которые реально принимают решения, в том числе и решения основанные на неопределённых данных, говорить о том, что эта задача практически неразрешима, это примерно то же самое, что в начале XX века говорить о том, что железо не может заниматься арифметикой.
> Достижение в том, что сложные устройства могут сами принимать решения, а не
> в том, что они принимают всегда правильные решения. Задача выбора из
> двух стуль^W браузеров одного единственно верного неразрешима, даже если ограничиться
> только одним критерием - безопасностью.
> Как по мне, просто не нужно загонять себя в рамки такой постановки
> вопроса и решать непосредственно свои проблемы.

Если мы не будем загонять себя в рамки, когда пытаемся принимать решение, или когда ведём дискуссию в интернете, то мы никогда не придём к сколь-нибудь осмысленному решению. Человек таким образом думает: он изолирует кусочек реальности, и работает с ним. Если бы у нас были бы бесконечные вычилительные способности в голове, то может быть у нас были бы более крутые способы. Но поскольку мозги конечны, нам приходится урезать число размерностей в задаче, выкидывая из рассмотрения то одни, то другие. Тебе не приходилось сталкиваться с матаном в размерностях выше 3? Там единственный способ пережить экзамен -- научится анализировать проблемы, крутя в голове не R^n, а сечение этого R^n трёхмерным подпространством.

>>> Проще исходить из того, что браузер ненадёжен и строить модель угроз исходя из этого, а не гадать на кофейной гуще.
>> В третий раз скажу тебе: одно другому не мешает. Я именно что рассматриваю браузер как нечто ненадёжное. Но это не мешает мне сравнивать ненадёжности разных браузеров, и выбирать браузер с учётом результатов этого сравнения.
> Я тоже сравниваю ненадёжность браузеров, и тоже делаю выводы. Но опираюсь не
> только на статистику, а ещё на знания об архитектуре проектов, про
> их сообщества и аудиторию.

Если честно, я не уверен, что я понимаю, о каких выводах идёт речь. Ты ведь о том, что браузер надо запускать в контейнере, пользоваться аддонами, править about:config на повышение безопасности, так? Или о том, что для повышения безопасности надо выбирать Chrome? Этого ты не говорил вроде, но просто вот эта твоя фраза и настойчивость в споре, как-то не увязывается с тем, что ты говоришь, и заставляет задуматься, что я чего-то упустил.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



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

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