11 ноября 2020 года Google выпустила обновление браузера Chrome — версию 86.0.4240.198 для Windows, Mac и Linux. В этой сборке специалисты компании устранили две уязвимости нулевого дня — CVE-2020-16013 и CVE-2020-16017. Информацию об этих уязвимостях передали в Google анонимные источники. За прошедшие три недели в коде браузера также были закрыты (в новых версиях браузера от 20 октября и 2 ноября) три уязвимости — CVE-2020-15999, CVE-2020-16009 и CVE-2020-16010. Они были обнаружены ранее специалистами из команды Google Project Zero и внутренней командой Google Threat Analysis Group (TAG).
Google пояснила в своем описании новой версии браузера, что уязвимость CVE-2020-16013 связана с несоответствующей реализацией в V8, JavaScript движке Chrome. Вторая уязвимость CVE-2020-16017 обозначена как ошибка повреждения памяти при использовании данных после освобождения памяти (use after free) в компоненте браузера Chrome под названием Site Isolation. Этот элемент изолирует данные разных сайтов друг от дружки.
Google не уточнила подробности обнаружения двух новых уязвимостей и фактов их вероятного применения. Компания пообещала раскрыть информацию по ним после того, как большинство пользователей установят новое обновление браузера.
Примечательно, что ранее обнаруженная уязвимость нулевого дня CVE-2020-16009 также связана с работой движка JavaScript V8 Chrome. Используя эту уязвимость злоумышленники могли удаленно выполнить произвольный код в браузере. Причем Google пояснила, что зафиксировала факты применения эксплойтов, использующих эту уязвимость.
mixsture
Кажется, что-то пошло не так в развитии Chrome. Он же изначально позиционировался как защищенный вариант браузера, где каждая вкладка работает в независимом процессе.
А раз мы получаем
то это ж явно shared memory и совсем не изолированность каждой вкладки.
mspain
Надо браузер запускать из под другого пользователя, желательно под linux. У меня 4: root, непривилегированный юзер системы и два разных юзера для помоешного контента и финансового.
Волосы вполне шелковистые…
nikolayv81
Если самое ценное что у вас есть на компе это то что вы в браузере смотрите (условный онлайн банк, и т.п.) то как это поможет :)
На условном ноутбуке может вообще не быть ничего ценного кроме паролей к сайтам и их содержимого :)
alex_shpak
Так-то я с Вами согласен, но раз mspain упомянул двух пользователей для браузеров — то, как минимум, это лишняя граница между паролем от онлайн-банка и «помоешным» сайтом, баннер на котором может пытаться воровать все доступные пароли.
Вы же не предлагаете для работы, помоешного контента, и онлайн банка использовать разные ноутбуки? :)
kt97679
Достаточно использовать разные виртуальные машины. Joanna_Rutkowska говорила об этом некоторое время назад
Viknet
После изобретения Spectre этого уже недостаточно.
alsoijw
У вас пользователь для браузера входит в отдельном сеансе DE/WM, что и пользователь системы или в разных?
crea7or
Ну а как между процессами-то общаться, само собой там всё чрез shared memory и устроено.
Antervis
alex_shpak
Если я правильно читаю документацию, то Site Isolation — это и есть как раз «каждая вкладка работает в независимом процессе». Просто дело в том, что iframe'ы могут быть с разных сайтов, но всё равно общаться между собой, разные вкладки могут отправлять postMessage друг другу, а ещё есть замечательный window.opener. Вот где-то здесь что-то и есть.
staticmain
А зачем это сделано? Какой юз кейс у общения вкладок между собой?
alex_shpak
Вот именно! Единственное, что я придумал — это кнопки типа «залогиниться через ...», работающие без перезагрузки страницы. Такая кнопка открывает новое окно (или iframe) целевого сайта, где происходит авторизация, и потом это окно передаёт всю информацию о пользователе своему открывателю. Но все равно то же самое можно было бы сделать и на редиректах.
bgBrother
Для поддержки постоянного соединения и отображения событий только на одной вкладке, а не на всех сразу. При этом поддерживать соединение в «сейчас просматриваемой» вкладке «не получится» как минимум из-за того, что пользователь может «прыгать» по вкладкам, а значит и соединению нужно было бы «прыгать».
staticmain
Так, а зачем поддерживать только одно соединение? Если я открыл 5 вкладок с мессенджером (например с 5 людьми (хотя я не представляю, зачем так делать)), то я хочу мочь ответить каждому в своей вкладке, а не видеть уведомление на текущей, потом переключиться на нужную, дождаться пока там прокачается история (или не прокачается, ага) и там ответить.
На самом деле я не встречал сайтов, в которых нужно держать несколько вкладок одного и того же инстанса чтобы так работать.
bgBrother
Так никто и не запретит вам это делать. Речь была о соединениях типа WebSocket. При любом вашем действии данные будут передаваться из одной вкладки в другую, потом по WebSocket на сервер и обратно в «просматриваемую» вкладку или во все вкладки одновременно. При этом звук/визуализация события будет только там, где пользователь увидит.
Вот представьте себе музыкальный плеер в соц. сети без этой штуки. При любом желании изменить песню вам бы приходилось искать вкладку, в которой вы эту музыку и включили. При этом если на другой вкладке вы включите видео, то музыка на прошлой вкладке не была бы автоматически поставлена на паузу и вам это нужно было бы делать вручную.
Выше я указал вам пример такой реализации. Ещё можете представить реализацию чата без необходимости подгружать данные сразу во всех открытых вкладках, если пользователь так открыл (забыл закрыть старую при множестве открытых вкладок; серфил по сети и попал на тот же чат и так далее).
Glebana
Нужно сделать его опенсорсным чтоб можно было баги легче выявлять. Ждемс багов с паленой лисы ибо я на ней сижу.
bgBrother
От подобных уязвимостей в идеале защитит только использование отдельного устройства для каждого нового веб-ресурса (на одной вкладке может быть загружено несколько веб-ресурсов с разными уровнями изоляции).
Ответьте, пожалуйста, если я не прав.
mixsture
Во-первых, мне не очень понятна необходимость вообще существования site isolation.
Гугл пишет
А я помню как изначально хром позиционировался как «1 вкладка = 1 процесс». А сейчас мы натыкаемся на фичу, которая «удостоверяется, что вкладка в отдельном процессе» — т.е. делает ту же работу, которая итак должна быть изначально.
Во-вторых, раз уж существует компонент привилегированный — вполне логично, что он должен не доверять данным вкладки и проверять их. И уж точно ему не стоит доверять этим данным настолько, что исполнять их внутри себя. Кажется, тема разделения данных и исполняемого кода в целях безопасности и валидации входных данных — очень давняя.
bgBrother
Так и есть.
Нет, эта фича ограничивает сайт в этом процессе, что бы он «не выпрыгнул». При этом на одной вкладке могут быть разные страницы и их тоже нужно отделить одна от другой. Почитайте о политиках безопасности для таких тегов как iframe, script.