Опубликовано корректирующее обновление Firefox 74.0.1, в котором исправлены две критические уязвимости, которые могут привести к выполнению кода атакующего при обработке определённым образом оформленного контента. Предупреждается, что в сети уже выявлены факты применения данных уязвимостей для совершения атак. Проблемы вызваны обращением к уже освобождённым областям памяти (use-after-free) при обработке ReadableStream (CVE-2020-6820) и при выполнении деструктора nsDocShell (CVE-2020-6819).Подробнее: https://www.opennet.me/opennews/art.shtml?num=52672
А учитывая исчезающе малую долю рынка и, соответственно, низкий интерес "хороших хакеров" к лисе, страшно представить себе сколько там ещё незакрытых дыр.
Главное на улицу никогда не выходи - страшно представить себе сколько там ещё неизвестных опасностей.
Улица, а отличии от этой rust'аманской поделки, большей частью, неплохо протестирована. Список багов известен. При нормальной системе управления, есть некая дорожная карта с графиком их закрытия. Понёсшим от них ущерб полагается та или иная компенсация. Так что сравнение неуместно.
> Улица, а отличии от этой rust'аманской поделки, большей частью, неплохо протестирована. Список багов известен.А я всё ждал, когда же rust ввернут. Да и как-то слабоватое тестирование у улицы, учитывая что баг типа "вирусная пандемия" давно известен и уже не раз проявлялся. А сколько ещё всякого UB бывает типа бухого мужика на улице с топором, водителя жигулей под спайсами или падения кирпича на голову. Так что нет, спасибо, rust'аманская поделка по крайней мере не сможет меня убить.
Вот начнут для мёд.оборудования писать софт на расте и посмотрим.
>А я всё ждал, когда же rust ввернут.Ну так Rust это, практически, Гитлер OpenNet'а. Закон Годвина неумолим.
>Да и как-то слабоватое тестирование у улицы, учитывая что баг типа "вирусная пандемия" давно известен и уже не раз проявлялся.А что не так? Процессы, кроме системных, переведены на контейнерную изоляцию, всё что шевелится проверятся на правильный хэш, сигнатура атаки уже есть, идёт разработка заплатки. По моему, реакция среды абсолютно адекватна.
>А сколько ещё всякого UB бывает типа бухого мужика на улице с топором, водителя жигулей под спайсами или падения кирпича на голову.Это вообще не повторяемые баги, а разовые сбои.
>Так что нет, спасибо, rust'аманская поделка по крайней мере не сможет меня убить.Только потому, что её влияние на индустрию ничтожно.
> А что не так? Процессы, кроме системных, переведены на контейнерную изоляцию, всё
> что шевелится проверятся на правильный хэш, сигнатура атаки уже есть, идёт
> разработка заплатки. По моему, реакция среды абсолютно адекватна.Не сказал бы. На нашем южном локалхосте поизолировали в контейнеры всех подряд и понаставили ограничения на I/O так, что даже за ресурсами сходить не получается. Да реакция среды сначала была похожа на "авось пронесёт", а сейчас очень близка к "антивирус запускать уже поздно". Вон на китайском сервере то же самое происходило на месяц раньше - было время подготовиться к атаке.
> Это вообще не повторяемые баги, а разовые сбои.
Только на нашем локалхосте по статистике в 2018 году в среднем в сутки происходило 45 различных сбоев. Довольно сильно для разовых сбоев.
> Только потому, что её влияние на индустрию ничтожно.
Ну "правильная" rust-free поделка от корпорации бобра имеет куда больше влияния на индустрию, однако и про неё я не знаю ни единого случая.
Какая связь между растом, пауками и пользователями опеннета?Пауки не имеют развитого мозга. Поразительно, но имея вместо мозга простой нервный центр, пауки умудряются выживать и размножаться. Вся деятельность пауков управляется этим нервным центром и все что делает паук это лишь набор заложенных в нервный центр простых правил — рефлексов. Один из таких рефлексов — движение по паутине к центру вибраций, если вибрации совпадают с определенным паттерном, в частности, паттерном вибраций пытающейся выбраться из паутины жертвы. Паутинка завибрировала — паучок полез по паутинке в поиске еды.
Причем здесь раст?
Оказывается, что последовательность букв R, u, s, t, формирует рефлекторный отклик у простейших организмов опеннета, заставляя их, как мухи — пауков, ползти по паутине интернета к странице opennet.ru и оставлять комментарии подобные этому.
Характерной чертой этих комментариев, кстати, является попытка, вероятно, рефлекторная, но достоверные данные отсутствуют, скрыть триггер рефлекторной реакции, декорируя последовательность букв rust префиксами, суффиксами, применяя транслитерацию, и т.д.. Примеров подобного феномена существует множество, что, кстати, вызывает недоумение — так сильно подобная изобретательность контрастирует с базовым устровойством мыслительного процесса этих простейших организмов опеннета. Вот лишь некоторые примеры: хруст, растишка, rust'аман и т.д..
> Проблемы вызваны обращением к уже освобождённым областям памяти (use-after-free) при обработке ReadableStream (CVE-2020-6820) и при выполнении деструктора nsDocShell (CVE-2020-6819).
https://github.com/mozilla/gecko-dev/blob/master/docshell/ba...
Радует то, с каким самообладанием отвечают так называемые "растишки". По делу, и не переходя в деструктивную плоскость, иногда с юмором.Ребят, большое спасибо
Так там же вирус на улице! Не смотря на то что протестирована. Как же выходить?!
да там тестить и тестить, конца-края не видно
Нубский вопрос от "просто пользователя"?Если javascript отключен, то уязвимости нет?
Доподлинно известно, что абсолютно все уязвимости можно устранить отключением яваскрипта. Все уязвимости. Вообще все. И даже не только компьютерные. И даже не только уязвимости. И даже не только устранить. И даже не только даже.
Не все, по-моему ту же плойку успешно через парсер DOM хакали, т.е. обычный html. Да и на той неделе хакали через css -- тоже не js.
Нет, не факт.
Ну уязвимости бывают и в библиотеках обработки картино, в парсере CSS, в движке рендеринга HTML.
>Если javascript отключен, то уязвимости нет?"Проблемы вызваны обращением к уже освобождённым областям памяти (use-after-free)" это низкоуровневая работа с памятью, не поможет.
Те же уязвимости устранены в Firefox ESR 68.6.1
Очередная сишная дырень?
>при выполнении деструктора
>сишнаяНу это твой уровень, да. Хотя лично я все проблемы как раз на конструкторах/деструкторах и имел, поэтому нисколько не оправдываю плючи. Но всё же не стоит сравнивать простую человеческую сишку с переусложнёнными опасными языками.
Действительно, сишка ведь ни разу не дырявая XD
> Действительно, сишка ведь ни разу не дырявая XDЛюди вообще склонны совершать ошибки, си тут ни при чём. Там, где язык простой, ошибки будут логические, а в сложном не только они.
Минутка философии.Когда ты ищешь причину явления, то наиболее разумный метод выбирать что-то на роль причины -- это возможность как-то повлиять на следствие, влияя на причину. Обвиняя людей в ошибках, которые они совершают в C, ты загоняешь себя в тупик: людей ты не сможешь изменить. И заменить людей тебе нечем. А вот язык изменить можно.
Проблема всегда в людях: самый лучший инструмент тебе не поможет, если ты не умеешь им пользоваться. И простой инструмент при этом и освоить каждый способен. А сложный слишком много возьмёт на себя -- ты не будешь иметь понятия, что он на самом деле делает, и начнёшь совершать дополнительные ошибки.
> Проблема всегда в людях: самый лучший инструмент тебе не поможет, если ты
> не умеешь им пользоваться. И простой инструмент при этом и освоить
> каждый способен. А сложный слишком много возьмёт на себя -- ты
> не будешь иметь понятия, что он на самом деле делает, и
> начнёшь совершать дополнительные ошибки.Ты можешь нежно поглаживать словами свой выбор причины сколько угодно, это не отменит того факта, что никому ещё не удавалось собрать команду C-программистов, которая бы не выходила бы многократно за границы буфера, не тестировала бы последствий use-after-free, и не вытворяла бы других глупостей.
Когда создавались большинство проектов, ещё не существовало таких хороших анализаторов, как сегодня. Кстати, хоть какая-то польза от шланга, в том же ггц они появились по его примеру.
> Когда создавались большинство проектов, ещё не существовало таких хороших анализаторов,
> как сегодня. Кстати, хоть какая-то польза от шланга, в том же
> ггц они появились по его примеру.Создание анализатора для повышения качества кода -- это не изменение людей, а признание неисправимости людей и смещение фокуса борьбы с багами на язык и его инструментарий.
Так проблема-то действительно в людях. Обычно это либо "я знаю, что так нельзя, но мне виднее", либо "я всегда так делал и ничо". Теперь компиляторы за плохой код хотя бы могут бить по рукам.
> Так проблема-то действительно в людях.Я выше описал критерии для выбора причины. Ты, я смотрю, их проигнорил и продолжаешь функционировать из каких-то своих критериев, которые ты либо тщательно скрываешь от меня, либо даже не в состоянии сформулировать для себя. Ты понимаешь, что осмысленный диалог при таком твоём поведении невозможен?
> Обычно это либо "я знаю, что так
> нельзя, но мне виднее", либо "я всегда так делал и ничо".Эмм... Я не знаю куда ты смотришь, что для тебя это "обычно", я чаще вижу ситуации, которые не вписываются в твоё описание, и при этом я затрудняюсь выделить какие-то категории ситуаций, которые можно было бы назвать обычными: с обычными случаями люди обычно справляются без открытия багрепортов. Проблему представляют именно необычные, когда вроде всё продумал, решил, что например здесь не требуется особых заморок, чтобы избежать переполнения целого, потому как оно не может переполнится, но через полгода кто-то нашёл способ добиться переполнения целого именно в этом месте.
Тут проблема в том, что ты, думая о возможности переполнения думал, допустим, 5 минут, а тот кто нашёл переполнение думал, как его добиться, может быть, два дня. Но у тебя нет возможности думать по два дня над каждой строчкой кода.
>переполнения целогоТак это и не баг вовсе. А какие ещё могут быть варианты? Предупреждать о возможном переполнении? Ну, где-то это сработает. Обложить всё костылями в рантайме? И это есть уже давно. Переполнение либо может быть, либо не может. Надо просто правильно выбирать типы данных
> Так это и не баг вовсе.Что значит "не баг"? С точки зрения языка это может и не баг, а фича, а с точки зрения программы переполнение может привести к тому, что твой индекс в массив окажется отрицательным, и когда ты проверишь что i<len, то получишь true, но когда пройдёшь по индексу окажешься за границами массива. То есть это, всё же, баг.
> А какие ещё могут быть варианты?
В смысле, как это можно решить на уровне языка? Тут несколько направлений возможно, которые не исключают друг друга.
1. Дать простые способы считать с проверкой на переполнение. То есть не какие-то кодовые высказывания языка, которые позволяют проверить на переполнение не наступив ни на какие грабли, не какое-то сакральное знание, требующее долгого обучения, которое не исключает высокой когнитивной нагрузки в процессе написания кода, а _простые_ способы. Это можно сделать либо на уровне библиотеки (например, определив тип checked_int, для которого будут определены все арифметические операции, но переполнение при их выполнении будет выкидывать исключение; или хотя бы функции checked_add, checked_sub, checked_mult, checked_div, которые будут делать то же самое, но над обычными int'ами), либо на уровне языка (например, дав возможность пометить блок кода для компилятора, чтобы тот всю арифметику в нём компилировал бы с проверкой на переполнение). Вариант с компилятором удачнее, так как он позволяет в компилятор вставить оптимизации, специально заточенные на арифметику с отловом переполнений. Скажем, компилятор сможет переупорядочивать операции, и может быть какие-то из проверок выкидывать.
2. Проверка индексов в рантайме. Это не так страшно, если включить агрессивный инлайн кода, и хороший оптимизатор, который сможет проверки выкидывать из циклов наружу, а когда не сможет то хотя бы за счёт спекулятивного выполнения сведёт их стоимость к ~нулю. Это не спасёт от переполнений целых в общем случае, но от довольно распространённых последствий этих переполнений спасёт.
3. Замена индексов итераторами и функционалами. Когда вместо for(i = 0; i < len; i++) sum += array[i]; ты пишешь sum = array.fold(sum, |acc, x| { return acc + x }), у тебя нет ну никаких шансов выйти за границы массива. Такой функциональный стиль не всегда удобен, но когда он удобен он устраняет не только возможность выхода за границы массивов, он ещё и гарантирует отсутствие ненужных проверок в рантайме (даже при -O0), а в некоторых случаях он позволяет оптимизировать код лучше, потому как этот стиль подталкивает программиста писать код, который хорошо векторизуется.
И, мне кажется, (1) наиболее важный пункт: постоянно обдумывать каждую операцию на предмет того, что может случится в случае переполнения, и может ли -- это очень утомляет. Утомление ослабляет внимание, а ослабленное внимание приводит к багам. Если же есть простые способы, которые не отвлекают от основной задачи, и всё что мне надо -- не забыть сказать компилятору, что тут очень важно чтобы не было переполнения, то всё становится резко проще. А если при этом ещё добавить строгую типизацию, и потребовать чтобы вся индексы имели бы тип off_t или size_t, и никакие int'ы не приводились бы к size_t и off_t молчаливо, а потом к size_t и off_t приделать обязательную проверку на переполнение, выполняемую компилятором, то тогда можно довести ситуацию, когда программисту проще писать с проверкой на переполнение, чем без неё, а это значит, что изворачиваться и уходить от этой проверки он будет только тогда, когда это действительно важно. То есть довольно редко, а если редко это делать, то и баги такие будут возникать редко.
> Надо просто правильно выбирать типы данных
Что ты имеешь в виду? off_t -- это знаковый тип, и тому есть причины. Его не удастся сделать беззнаковым, чтобы проверять на выход только за одну границу. Ты не сможешь сделать его больше. Точнее сможешь, но это бессмысленно, потому как перед применением всё равно придётся обрезать лишние биты. Да и дорого это: size_t и off_t, как правило размером с машинное слово, если ты сделаешь их больше, то вся арифметика станет резко дороже -- проще уж автоматически проверок на выход за границы в рантайме навтыкать.
Или ты к тому, что под количество денег в игре надо выделять не 32 бита, а целое произвольной точности, чтобы у игрока не было бы возможности, нырнув в глубокий минус, вынырнуть владельцем игровой вселенной? Может быть так и нужно делать. Но не всегда разумно использовать целое произвольной точности. А если просто взять 64 бита вместо 32, то это не обязательно спасёт: произведение двух 32 битных целых может опасно подобраться к переполнению 64 битного, то есть какой-нибудь промежуточный результат вычислений может переполнить и 64 бита, и... То есть это всё полумеры, если тебе нужна защита от переполнений, то нужно проверять на переполнения, то есть вставлять рантайм-проверки. И либо ты будешь делать это ручками, либо научишь компилятор делать это за тебя.
Чёт длинно, я не в настроении читать простыни.>дорого
Операции над машинным словом дешевле операций над его частью, в среднем, в принципе.
Я имею в виду, переполнение на пустом месте не возникает. Индексы не могут быть отрицательными, а разница индексов должна быть в 2 раза больше индекса. Это логическая ошибка программиста, если он допустил переполнение там, где его быть не должно.
я почитал за вас, было довольно интересно
>это не отменит того факта, что никому ещё не удавалось собрать команду C-программистов, которая бы не выходила бы многократно за границы буфера, не тестировала бы последствий use-after-free, и не вытворяла бы других глупостей.Это были неправильные сишники.
Срочно переписать на дристре. То бишь на расте.
На dlang или nim.
D придумала не Мурзилла, потэтому NIH.
Тогда авторам dlang нужно срочно свой браузер писать.
yo dawg I herd you like GC, so we put a GC in yo GC so you can wait for GC while u wait for GCписать js-машину (у которой собственный gc) на языке, у которого самого есть gc -- это конечно верх "изящества", ничо, пользователь подождёт.
Безопасность в браузере определяется не количеством дырей, а умением разработчиков с ними бороться
--
лучше дырявый, но этот, чем хром или что там еще .... Я правда, раньше так про оперу думал, пока она не кончилась
> лучше дырявый, но этот, чем хром или что там еще«Что дальше?...
Да хоть ДЫРЫ в БРАУЗЕРЕ!
Мы на ФАЙРФОКСЕ!»
Ну конечно. На зло врагу. Лучше дырявый, но этот. Лучше хреновый, но не тот.
Там эт, вроде гугл и денег предлагает, но ломать не спешат. Либо зиродей для единственного браузера на свободном рынке можно выгодней продать, либо есть некоторые проблемы с пробитием всех слоёв изоляции.
Бабахает 💥 периодически
Деньги платят — ищут
https://www.opennet.me/opennews/art.shtml?num=52084Ну и да, песочница в Chromium тоже влияет.
Предлагаю выпускать сразу корректирующие обновления Firefox хх.0.1, а то каждый раз уже
Уже Firefox 75.0 вышел, а вы всё Firefox 74.0 обновляете...
Да хоть 95! Что значимого сделано за последних... N лет? Ни-че-го! Как сломали браузер много лет назад, так и всё. Приехали.
(Кстати, а страну кто развалил? Втихушку. На сходняке. Хорошее дело изподтишка не делают)
Аноны яро минусуют. Не хотят новых лис. Видать достали уже своими экзерсисами хитровые...ными. А путного ничего нет давно.
когда же на rust полностью firefox перепишут?
Servo
Суммарная доля Firefox за март 2020 на всех платформах - 3,18% : https://www.netmarketshare.com/browser-market-share.aspx?opt...
https://www.netmarketshare.com/browser-market-share.aspx?opt...
Браузер Microsoft Edge превзошел по популярности Firefox: https://ru.gecid.com/news/brauzer_microsoft_edge_prevzoshel_.../Цитата: "Согласно информации аналитической компании NetMarketShare, усилия Microsoft постепенно оправдывают себя. В марте доля веб-браузера Edge на ядре Chromium в сегменте десктопов и ноутбуков выросла до 7,59%. Это позволило ему подняться на второе место, оттеснив Firefox (7,19%) на третье. Неизменным лидером остается Chrome (68,5%). Также в пятерку лучших входят Internet Explorer (5,87%) и Safari (3,62%).
Аналитики предполагают, что Edge и далее будет укреплять свои позиции и подбираться к лидеру. Тем более что позже в этом году он станет предустановленным веб-браузером в Windows 10, и некоторые пользователи будут использовать его по умолчанию."
> и некоторые пользователи будут использовать его по умолчанию.а не будут брать - отключим газ!
Кстати ёж отличный браузер, быстрый и легковесный. В мире хромомонстров. Был.
На так хоть только гугл. А Ёж - это и микрософт и гугл вместе. Многовато будет!
Раньше он был без гугла, в том-то и дело.
Ну... раньше много чего было... лучше. :-)
Даже лиса.
Ну, сейчас без гугла ничего не обходится. Даже мазила. Охромевает всё сильней и сильней.
gmail сломался или это мои глюки?
Это пандемия.
Уже 75-й, если что, вышел. Где же новость???
> Уже 75-й, если что, вышел. Где же новость???Firefox 75 выйдет 7 апреля. https://wiki.mozilla.org/RapidRelease/Calendar
Сейчас это ещё не релиз, а тестовый выпуск для распространения по зеркалам. Завтра его могут объявить релизом. До официального объявления релиза его могут заменить или отложить, что уже случалось.
А это что???
https://download-installer.cdn.mozilla.net/pub/firefox/relea...
https://download-installer.cdn.mozilla.net/pub/firefox/relea...
Тем не менее, он не помечен ни как бэта, ни как рц. А то, что могут откатить финал, это случается.
Вышел на день раньше запланированной даты. Подготовили к 7 апреля релиз 75.0, загрузили на релизные сервера и запустили тестирование версии 76.0b1 Какие тут могут быть тестовые выпуски?!
Mozilla загружает выпуск для распространения по зеркалам за несколько дней до намеченного релиза. Имя файла при этом как у релиза, но на деле это лишь кандидат в релизы. Если в последний момент проблем не обнаружено объявляют о релизе.На сайте специально для любителей сообщать о релизе раньше времени они даже специально написали https://wiki.mozilla.org/Firefox/Roadmap/Updates
2020-04-06
Firefox 74.0.1 is our latest stable release.
Firefox 75 is in the Beta channel as the final release candidate. 75 will ship to our stable release audience tomorrow, Tuesday, April 7th
Есть ветка ftp
Index of /pub/firefox/candidates/
А есть
Index of /pub/firefox/releases/Если билд находится в
Index of /pub/firefox/releases/
то он уже никак не может быть кандидатом в релизы так как он уже и есть релиз.
Я не уверен почему, но после прочтения этой темы я чувствую, что ухожу из США и переезжаю в Россию. Ну, я знаю почему, я просто не уверен, почему я думаю об этом сейчас. Каждый день, когда я не заперт в клетке, где горячая вода из-под крана с растворимым кофе считается предметом роскоши, является благословением.Я слышал, когда вы, ребята, встречаетесь с полицией, вы можете просто дать им деньги, и они оставят вас в покое? Здесь они сажают наркотики в твою машину и запирают тебя. Вы должны заплатить тысячи долларов за освобождение, пока вы ждете суда. Это если вы можете догадаться, какой друг поднимет трубку и у вас будет достаточно денег, чтобы выручить вас. В противном случае вы просто ждете в тюрьме до суда. Это может занять месяцы.
(Мы все чаще слышим о том, что зависимые от опиатов умирают в тюрьмах от комбинации изъятия и обезвоживания. Большую часть времени их единственным преступлением является то, что они вообще были зависимыми от опиатов. Охранники думают, что наблюдать за их смертью интересно, и они никогда нести ответственность.)
Даже если вы невиновны, лучше просто признать себя виновным, потому что вы рискуете получить более длительный срок, если вас осудят неправильно, чем если вы просто заключите любую сделку, которую они предлагают. Когда мы молоды, они говорят нам, что полиция защищает нас от злых людей, но злые люди, которых я боюсь больше всего, сами являются полицией.
Полагаю, я снова начну изучать русский язык. Сложнее всего переключать режимы и не видеть буквы, похожие на латинские буквы, как латинские буквы. Интересно, как так получилось, что есть общие символы, некоторые из них фонетически одинаковые, а другие совершенно разные?
Я пришел сюда в поисках примера того, как вредоносная страница может использовать уязвимость пользователя после освобождения. Это кажется особенно опасной уязвимостью, поскольку возможно запускать эксплойты в системах, где установлены типичные средства защиты, такие как отключенный JavaScript.