[Дискасс] Эпический фейл крэш-репортера и будущее проекта Fox

[The-OP]

На днях я изучил баг 1424373 (и связанный с ним баг 1427111), исправленный в Firefox 57.0.3 и 52.5.3, и увидел, что все намного серьезнее чем казалось.

Шаги для проявления этого самого бага:

1. Скачать Firefox 57.0.0. Либо 52 ESR, версию до 52.5.3.
2. Создать новый профиль через менеджер профилей (firefox -p), но пока не запускать браузер с ним.
3. Создать в новом профиле user.js с настройками, отключающими автообновление браузера и аддонов. Это нужно, чтобы Firefox не обновился до 57.0.3 или не скачал системный аддон-хотфикс, который воркэраундит баг для пользователей не обновляющихся до 57.0.3.
4. Запустить новый профиль, зайти в Preferences и убедиться что автоотправка крэш-репортов отключена (Allow Firefox to send crash reports to Mozilla - она же browser.crashReports.unsubmittedCheck.autoSubmit в about:config). Она отключена по умолчанию, ибо якобы подразумевалась opt-in, как пишут разработчики в Багзилле.
5. Открыть какой-нибудь таб и убить его процесс с SIGTERM или SIGKILL. При такой участи крэш-репорт не сгенерируется. Зато проявится тот самый баг.
6. Нажать Restore tab на убитом табе, снова зайти в настройки и убедиться что автоотправка крэш-репортов сама включилась.
7. Открыть еще какой-нибудь таб и переключиться с него на любой другой. Ронять будем тот, с которого переключились.
8. Запустить Browser Toolbox, вкладку Network Monitor. Она показывает сетевые запросы всего браузера, а не только вкладки.
9. Уронить контент-процесс таба из п.7 таким образом, чтобы крэш-репорт сгенерировался. Для этого можно убить его с SIGSEGV или SIGILL (Illegal Instruction).
10. Переключиться обратно на уроненную вкладку. Из-за включенной автоотправки крэш-репортов вкладка восстановится автоматически, без показа about:tabcrashed.
11. Увидеть в Browser Toolbox, что крэш-дамп автоматически улетел на crash-reports.mozilla.com. И он содержит в себе URL упавшей вкладки (даже (!) если browser.tabs.crashReporting.includeURL = false) и еще кучу веселой информации, которую видно на вкладке Params в Network Monitor. (Также старые крэш-репорты можно посмотреть в ~/.mozilla/Firefox/Crash Reports.)

Я считаю этот баг критическим как для этого проекта, так и для самой идеи использования Firefox в качестве прайваси-ориентированного браузера. Ибо от такого бага вас никак не спасут содержащиеся в этом репозитории настройки (можете проверить, подставив prefs_1 - не поможет) - там отключено все что можно было, однако, как видим, оно включается само. А URL, по которому крэш-репортер отправляет репорты, зашит в исходники, и префами с ним ничего не сделаешь.

Этот баг - далеко не первый звоночек (а скорее последняя соломинка) - в течение всего 2017 года Мозилла как будто нарочно пыталась дискредитировать себя - то обещания собирать адреса посещаемых сайтов, то подсовывание немецким пользователям adware от Cliqz прямо вместе с установщиком браузера, а также рассуждениями разработчиков о том, как бы это сделать тайком, иначе ведь юзеры увидят надпись "Cliqz" и не будут качать эту широко известную в Германии адварь. И наконец предпоследний инцидент с аддоном Looking Glass - в котором тоже, кстати, по сообщениям некоторых людей были замешаны "случайно" включающиеся сами собой настройки.

Итак, раньше основной идеей, которой мы руководствовались, было то, что все мол можно отключить. Теперь это не так. Теперь мало того что Мозилла пихает все больше и больше дряни в Firefox, так эта дрянь еще и "случайным" образом включается сама и для какой-либо уверенности конфигов уже не хватает - нужно компилировать Firefox, вырезая все из исходников. То есть, как бы ни печально было это признавать, Мозилла таки сумела превратить Лису в Хром, переняв его самые худшие черты.

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

Что делать дальше - неясно. Думаю, нужно рассматривать какие-то альтернативные варианты. Хотелось бы услышать и ваши мысли. Мне на ум приходит только Tor Browser. (Ибо все остальные форки Firefox не являются серьезными проектами и не имеют перспектив по очевидным причинам.)

К дискуссии приглашаются все контрибуторы и прочие заинтересованные люди. Особенно: @dartraiden @KOLANICH @leedoyle @soredake

[leedoyle]

Нормальная идея. Возможный донор - аддоны типа https://addons.mozilla.org/de/firefox/addon/modify-header-value/ Надо будет добавить предотвращение установки и/или запуска "системных" аддонов ещё, те которые в директории features лежат - а то вдруг они решат телеметрию через вебексты слать. Правда, надо будет потестировать, насколько это будет замедлять браузер, а то в зависимости от моделей возможных угроз это может оказаться нецелесообразным для случаев, когда фокусы вроде утечки урлов скрашившихся страниц некритичны.

[KOLANICH]

Просто заблеклистить эту папку в firejail? A чем плох вариант с дампом эфемерных ключей?

[The-OP]

@leedoyle

У WebExt нет доступа к телеметрии браузера. Разве что если это какой-нибудь аддон со своей собственной телеметрией.

@KOLANICH

A чем плох вариант с дампом эфемерных ключей?

Не знаю, может и ничем. А куда их можно присобачить кроме Wireshark, чтобы, собственно, фильтровать по хедерам?

[leedoyle]

Так, я наткнулся на уже готовый аддон, который позволяет подменять все хедеры. https://addons.mozilla.org/de/firefox/addon/chrome-headers-middleman https://github.com/DingoEatingFuzz/chrome-headers-middleman

И даже Ungoogled еще не нашли все стучащие места

Что имеется в виду? Запаздывание релизов ungoogled или недостаточная проработанность самих релизов? Я пробежался сейчас по багтрекеру, за последний год судя по всему только один случай коннекта на непонятный домен https://github.com/Eloston/ungoogled-chromium/issues/274 .

[The-OP]

Что имеется в виду?

Вот это: https://github.com/Eloston/ungoogled-chromium/issues/302

(Кстати, попробуй свой пост исправить, написав ссылку так же - мне любопытно, исчезнет ли там референс сюда.)

[leedoyle]

@The-OP неа, как и ожидалось не исчез. Эти события типа  "X added the bug label" не исчезают и принципиально неудалимы. В лучшем случае скроются, если там будет штук 50, и то не уверен.

[KOLANICH]

Кто-то уху ел на завтрак, лэнч, обед, полдник и ужин

[dartraiden]

Вроде бы, операционку можно задетектить ещё и по MTU, так что все эти спуфинги ОС - "мама, я анонимус".

[KOLANICH]

3 Though it can be possible to fingerprint tcp/ip stack to get the OS, I guess we should still spoof the OS in useragent and maybe consider using a userspace tcp/ip stack.

И детект идёт не по MTU, MTU удаленный компьютер не видит. Можно пофингерпринтить по задержкам (перебирать ΜSS бинарным поиском и измерять задержки, при переходе границы по идее должна измениться скачком), но это ещё бабушка надвое сказала, где bottleneck.

[leedoyle]

@dartraiden когда я искал рабочие имплементации определения браузера по особенностям css и js движка, мне ничего не удалось найти. Поэтому я склонясь к тому, что Горхилл неправ, что удалил спуфинг уа из матрицы. Я даже хотел ему issue накатать, но руки не доходят, т.к. с ним сложно общаться.

[The-OP]

@dartraiden

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

@leedoyle

Да полно их - любое различие в поддержке стандартов можно использовать. У них даже вроде порядок и/или набор HTTP-заголовков другой. Так что под чужой браузер действительно не имеет смысл подделываться. Вот ОС - это уже другой вопрос.

[KOLANICH]

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

[Remu-rin]

К слову: https://github.com/jbtronics/CrookedStyleSheets https://www.opennet.ru/opennews/art.shtml?num=47902

[The-OP]

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

Пишите ваши замечания что ли. Я вот думаю, выкидывать ли настройки для 53+? С одной стороны, надо бы, с другой - все равно возвращать придется, когда выдет TB, основанный на 60 ESR.

[leedoyle]

@KOLANICH поставили у друга 20 процессов, тормозов не наблюдается.

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

@The-OP их можно просто закомментить с пометкой кодовым словом.

[The-OP]

по процессу на вкладку

Я тут пробовал на 57 (processCount=1000) - но после где-то 30 вкладок начались разные странные глюки - например, вкладка создается, но не прогружается. По-моему оно не готово.

для защиты от уязвимостей типа спектры?

Проще создать два профиля - один для сайтов с аккаунтами, второй - для остального серфинга.

[KOLANICH]

А с чего вы вообще взяли, что многопроцессность защищает от spectre?

@leedoyle : сколько ядер, сколько оперативы, используется ли своп-файл на диске, диск - ссд?

[The-OP]

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

[The-OP]

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

[KOLANICH]

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

[ghost]

фейл крэш-репортера

https://bugzilla.mozilla.org/show_bug.cgi?id=1427117 Мозилла всё удалила же.

[KOLANICH]

А осадочек (во всех смыслах) остался.

[KOLANICH]

I have recently tried to unpack mozilla's shitty hidden addons, and found that these .xpis cannot be unpacked with a usual archiver. This may be implemented intentionally to deter unpacking, though the content is pretty readable if I open the xpis with a text editor. We may need to write an (un)packer.

[leedoyle]

@KOLANICH унижения продолжаются, лол.

[KOLANICH]

@leedoyle, а нам вот не до смеху.

[The-OP]

@KOLANICH Это в какой версии? Всегда обычным unzip распаковывались с парой варнингов.

[dartraiden]

В 58. Обычные архиваторы теперь не берут.

[KOLANICH]

https://firefox-source-docs.mozilla.org/toolkit/mozapps/extensions/addon-manager/SystemAddons.html

extensions.systemAddon.update.url - настройка используется для тестирования. Если переопределить - заблокирует обновления?

По-видимому сиcтемные аддоны пакуются инструментом cpx. В паблике я его не нашёл, видимо он у них под NDA. Раньше у мозиллы был инструмент cfx, возможно что cpx - его форк.

[The-OP]

Н-да, Мозилла продолжает поворачиваться к пользователям отнюдь не лицом. Так что мысль переходить на TB была верной.

Попробую посмотреть, что там за формат, но на той неделе. Сейчас у меня завал.

[KOLANICH]

I have reversed a bit ... It's a zip archive, but a strange one: prepended by 4 null bytes, and these 4 bytes spoil all the addressing, if you just remove them, the offsets everywhere will be wrong, this disrupts unmodified archivers working. So a patched archiver is needed - the one having a mode to adressing not base beginning zip archive block, but base beginning of file. Maybe we need to send a PR to 7z, but I think the right reaction on it is to say that this is mozilla users' problem и послать сами знаете на что. Or a script fixing all the offsets in the file by subtracting them by 4.

Mozilla may also claim that this behavior is just a result of a programming error ....

[KOLANICH]

https://bugzilla.mozilla.org/show_bug.cgi?id=1434934

Get rid of dom.workers.enabled pref RESOLVED FIXED in Firefox 60

[ffug]

@KOLANICH It's not about dom.serviceWorkers.enabled. dom.workers.enabled is not even in this repo.

[KOLANICH]

It is not about service workers, I know that service workers are controlled with another pref. I have posted the link about it here because removal of the pref reduces customizability, which is yet another sign of Mozilla downfall, which this issue is about.

[ffug]

What are the problems with workers or why somebody would like to disable them? It's not like they ever had a toggle for each js feature.

[KOLANICH]

No problems at all, but it is not the reason to remove the already implemented pref.

[ffug]

Unless the pref was implemented for times when workers weren't considired stable. Didn't they implement and remove such prefs for other js features earlier? Anyway this is nothing comparing to many other removed stuff.

[KOLANICH]

Even though it is a step to removing all the stuff from the about:config. Neither I nor you know the real reason to disable workers, but it doesn't mean that no man needs this. But Chrome has nearly empty (in comparison to FF about:config) chrome:flags, but it still the most popular browser. People doesn't need customization. Mozilla can remove all the prefs from about:config because very little people need it, and Mozilla can afford itself to **** on the people who need it.

[ffug]

I think some of prefs are needed by some corporative cases, but i guess disabling workers for mozilla just looks like something nobody needs. Maintaining even such simple pref could require some time and thats not their goal to make everything customizable, they don't have resources for that. So either somebody will maintain a set of patches for esr or we'll have to trust forks with backports of fixes. Any solution except for staying with config requires coding. There are not that much people who ready to spend time on this and AFAIK they all are porting new mozilla code to their forks and not just maintaining a set of patches so it's difficult to check their code.

[KOLANICH]

disabling workers for mozilla just looks like something nobody needs.

All the prefs which are not changed on majority of installations or not needed for Mozilla development process look like something "nobody needs". But in fact we don't know what is needed and what is not. What if somone had found a vulnr in workers, a hotfix probably would be just disabling them. This is true for any feature.

Maintaining even such simple pref could require some time and thats not their goal to make everything customizable, they don't have resources for that.

The ones wasting money on donating $100,000 to Riseup and $70,000 for an Apache module for certificate renewal automation (the job is done with a cron job + shell script + certbot) don't have resources for supporting prefs not needed by majority? I wonder if you work for Mozilla and know some information we don't know to be able to make claims like they don't have resources for that.

[ffug]

Most likely thouse decisions made by different people. Mozilla is not just people working on firefox. And money are likely separated. So firefox managers reducing amount of things to maintain. Since there are really small amount of people who'll disable something because of vulnr before their hotfix they just don't care. They have resources and they want to spend them to something required by many people (Apache module is what actually needed by many people. I haven't check it' but i guess they spent lots to managers and security analytics).

[KOLANICH]

Since there are really small amount of people who'll disable something because of vulnr before their hotfix they just don't care.

To develop a fix mozilla needs time. They have a mechanism distributing and automatically installing chrome addons, which can be used to change about:config prefs. So ths first stage may be mass disabling of the feature and then developing a fix and then reenabling the feature.

So firefox managers reducing amount of things to maintain.

I have an ultimate idea for their team how to reduce the things to maintain: just stop developing firefox and say to everyone "just use Chrome".

They have resources and they want to spend them to something required by many people (Apache module is what actually needed by many people. I haven't check it' but i guess they spent lots to managers and security analytics).

Of course it's their right. But taking in account the said IMHO it's wrong to say they don't have resources.

[KOLANICH]

???

[dartraiden]

Firefox ещё поддерживается, но идёт работа по переезду всего хозяйства на Tor Browser.

[ghost]

@KOLANICH These donations are coming from Mozilla Foundation, a non-profit organization, a money gathered by donations from people, so they can't legally spend this money on Firefox development, which is done by Mozilla Corporation, a for-profit organization.

[KOLANICH]

they can't legally spend this money on Firefox development, which is done by Mozilla Corporation, a for-profit organization.

What prevents Mozilla Foundation from hiring the same devs as in Mozilla Corp. and paying them from M. F.?

[leedoyle]

Anybody alive?

[KOLANICH]

Only undead are here.

[KOLANICH]

toolkit.telemetry.enabled is locked, and the lock is hardcoded into C++ code to prevent it from being disabled easily https://dxr.mozilla.org/mozilla-central/source/modules/libpref/Preferences.cpp#3213

When they were asked about that they have rejected the proposal to unlock it.

[dartraiden]

Это, вроде бы, не касается релизов.

[KOLANICH]

It doesn't matter. This fact doesn't make Mozilla's actions acceptable anyhow.