Comments 22
Кажется, что-то пошло не так в развитии Chrome. Он же изначально позиционировался как защищенный вариант браузера, где каждая вкладка работает в независимом процессе.
А раз мы получаем
то это ж явно shared memory и совсем не изолированность каждой вкладки.
А раз мы получаем
Вторая уязвимость CVE-2020-16017 обозначена как ошибка повреждения памяти при использовании данных после освобождения памяти (use after free) в компоненте браузера Chrome под названием Site Isolation. Этот элемент изолирует данные разных сайтов друг от дружки.
то это ж явно shared memory и совсем не изолированность каждой вкладки.
Надо браузер запускать из под другого пользователя, желательно под linux. У меня 4: root, непривилегированный юзер системы и два разных юзера для помоешного контента и финансового.
Волосы вполне шелковистые…
Волосы вполне шелковистые…
Если самое ценное что у вас есть на компе это то что вы в браузере смотрите (условный онлайн банк, и т.п.) то как это поможет :)
На условном ноутбуке может вообще не быть ничего ценного кроме паролей к сайтам и их содержимого :)
Так-то я с Вами согласен, но раз mspain упомянул двух пользователей для браузеров — то, как минимум, это лишняя граница между паролем от онлайн-банка и «помоешным» сайтом, баннер на котором может пытаться воровать все доступные пароли.
Вы же не предлагаете для работы, помоешного контента, и онлайн банка использовать разные ноутбуки? :)
Вы же не предлагаете для работы, помоешного контента, и онлайн банка использовать разные ноутбуки? :)
Достаточно использовать разные виртуальные машины. Joanna_Rutkowska говорила об этом некоторое время назад
У вас пользователь для браузера входит в отдельном сеансе DE/WM, что и пользователь системы или в разных?
Ну а как между процессами-то общаться, само собой там всё чрез shared memory и устроено.
то это ж явно shared memory и совсем не изолированность каждой вкладки.браузер может пытаться кешировать общие элементы разных вкладок чтобы оптимизировать память
Если я правильно читаю документацию, то Site Isolation — это и есть как раз «каждая вкладка работает в независимом процессе». Просто дело в том, что iframe'ы могут быть с разных сайтов, но всё равно общаться между собой, разные вкладки могут отправлять postMessage друг другу, а ещё есть замечательный window.opener. Вот где-то здесь что-то и есть.
Какой юз кейс у общения вкладок между собой?
Вот именно! Единственное, что я придумал — это кнопки типа «залогиниться через ...», работающие без перезагрузки страницы. Такая кнопка открывает новое окно (или iframe) целевого сайта, где происходит авторизация, и потом это окно передаёт всю информацию о пользователе своему открывателю. Но все равно то же самое можно было бы сделать и на редиректах.
Для поддержки постоянного соединения и отображения событий только на одной вкладке, а не на всех сразу. При этом поддерживать соединение в «сейчас просматриваемой» вкладке «не получится» как минимум из-за того, что пользователь может «прыгать» по вкладкам, а значит и соединению нужно было бы «прыгать».
Так, а зачем поддерживать только одно соединение?Что бы не было дополнительного расхода ресурсов и не садить пользователю батарею + что бы браузер не «заморозил» подобное поведение из-за слишком большой нагрузки веб-страниц.
Если я открыл 5 вкладок с мессенджером (например с 5 людьми (хотя я не представляю, зачем так делать)), то я хочу мочь ответить каждому в своей вкладке, а не видеть уведомление на текущей, потом переключиться на нужную, дождаться пока там прокачается история (или не прокачается, ага) и там ответить.Так никто и не запретит вам это делать. Речь была о соединениях типа WebSocket. При любом вашем действии данные будут передаваться из одной вкладки в другую, потом по WebSocket на сервер и обратно в «просматриваемую» вкладку или во все вкладки одновременно. При этом звук/визуализация события будет только там, где пользователь увидит.
Вот представьте себе музыкальный плеер в соц. сети без этой штуки. При любом желании изменить песню вам бы приходилось искать вкладку, в которой вы эту музыку и включили. При этом если на другой вкладке вы включите видео, то музыка на прошлой вкладке не была бы автоматически поставлена на паузу и вам это нужно было бы делать вручную.
На самом деле я не встречал сайтов, в которых нужно держать несколько вкладок одного и того же инстанса чтобы так работать.
Выше я указал вам пример такой реализации. Ещё можете представить реализацию чата без необходимости подгружать данные сразу во всех открытых вкладках, если пользователь так открыл (забыл закрыть старую при множестве открытых вкладок; серфил по сети и попал на тот же чат и так далее).
Нужно сделать его опенсорсным чтоб можно было баги легче выявлять. Ждемс багов с паленой лисы ибо я на ней сижу.
каждая вкладка работает в независимом процессеТак и есть же. При этом каждый процесс ограничен «песочницей», что бы не работать в рамках ОС без ограничений. В коде Site Isolation обнаружена брешь, которая позволяет представить свои данные в виде кода, работающего «под видом» Site Isolation. В результате получен доступ к ОС и другим процессам.
От подобных уязвимостей в идеале защитит только использование отдельного устройства для каждого нового веб-ресурса (на одной вкладке может быть загружено несколько веб-ресурсов с разными уровнями изоляции).
Ответьте, пожалуйста, если я не прав.
Во-первых, мне не очень понятна необходимость вообще существования site isolation.
Гугл пишет
А я помню как изначально хром позиционировался как «1 вкладка = 1 процесс». А сейчас мы натыкаемся на фичу, которая «удостоверяется, что вкладка в отдельном процессе» — т.е. делает ту же работу, которая итак должна быть изначально.
Во-вторых, раз уж существует компонент привилегированный — вполне логично, что он должен не доверять данным вкладки и проверять их. И уж точно ему не стоит доверять этим данным настолько, что исполнять их внутри себя. Кажется, тема разделения данных и исполняемого кода в целях безопасности и валидации входных данных — очень давняя.
Гугл пишет
It ensures that pages from different websites are always put into different processes
А я помню как изначально хром позиционировался как «1 вкладка = 1 процесс». А сейчас мы натыкаемся на фичу, которая «удостоверяется, что вкладка в отдельном процессе» — т.е. делает ту же работу, которая итак должна быть изначально.
Во-вторых, раз уж существует компонент привилегированный — вполне логично, что он должен не доверять данным вкладки и проверять их. И уж точно ему не стоит доверять этим данным настолько, что исполнять их внутри себя. Кажется, тема разделения данных и исполняемого кода в целях безопасности и валидации входных данных — очень давняя.
Во-первых, мне не очень понятна необходимость вообще существования site isolationЧто бы процесс не мог получить доступ к системным ресурсам и к конфиденциальным данным на других сайтах того же пользователя.
А я помню как изначально хром позиционировался как «1 вкладка = 1 процесс».Так и есть.
А сейчас мы натыкаемся на фичу, которая «удостоверяется, что вкладка в отдельном процессе» — т.е. делает ту же работу, которая итак должна быть изначально.Нет, эта фича ограничивает сайт в этом процессе, что бы он «не выпрыгнул». При этом на одной вкладке могут быть разные страницы и их тоже нужно отделить одна от другой. Почитайте о политиках безопасности для таких тегов как iframe, script.
Хотелось бы ещё небольшого сравнения с браузерами конкурентами. А то не совсем понятно это хорошо или плохо.
Что вы хотите сравнивать? Уязвимости? Перефразируя классика: "Все неуязвимые браузеры похожи друг на друга, каждый уязвимый — уязвим по-своему."
Вот недавно как раз сайт для этого кто-то запилил, на HN обсуждение было.
Но как это показывает, это хорошо или плохо — вопрос спорный.
Но как это показывает, это хорошо или плохо — вопрос спорный.
Sign up to leave a comment.
Google закрыла в Chrome ещё две уязвимости нулевого дня. За месяц их было устранено уже пять