Google's Chrome browser undergoes a major architectural change to allow protection designed to mitigate the threat of attacks related to Specter's vulnerability in computer processors. If they are not controlled by browsers or operating systems, these attacks may allow hackers to extract pbadwords or other sensitive data from the computer's memory when targets are visiting malicious sites.
domain in their own "rendering processes", which are individual browser tasks that are not allowed to interact with each other. Therefore, a page on arstechnica.com containing ads from doubleclick.net will load the content into two separate rendering processes, one for each domain. Protection, however, has a cost. It consumes 10 to 13% of the total additional memory. Some performance can be offset by smaller rendering processes and shorter life. The site's isolation will also allow Chrome to re-activate more accurate timers, which Google and most other browsers have disabled earlier this year to reduce the chances of successful attacks.
but from version 67, it is enabled by default for 99% of users. Google gives way to the other 1% so that engineers can monitor and improve performance. Protection is also enabled on the Chrome desktop. For performance reasons, it's not available in Chrome for Android yet.
An Impressive Achievement
Mitigation is an impressive engineering feat designed to reduce attack damage exploiting a new clbad of vulnerability that appeared in January. Nicknamed Spectrum, the attack abuses a CPU optimization technique known as speculative execution so that it can obtain pbadwords, cryptographic keys and keys. Other data residing in memory which normally should be prohibited to unapproved pieces of code. The vulnerability posed a serious threat to people browsing websites because individual pages often broadcast JavaScript code from multiple domains that run in the same process. This leaves open the possibility that a malicious ad may steal sensitive user data belonging to a site hosting the ad, a hack that would violate a Web security cornerstone known as the same policy d & # 39; origin.
Charlie Reis wrote:
Isolation Site is a big change in the architecture of Chrome that limits each rendering process to documents from a single site. As a result, Chrome can rely on the operating system to prevent attacks between processes and, therefore, between sites. Note that Chrome uses a specific "site" definition that includes only the schema and the registered domain. Thus, https://google.co.uk would be a site, and subdomains like https://maps.google.co.uk would stay in the same process.
Chrome has always had a multi-process architecture where different tabs could use different rendering processes. A given tab can even change processes when you navigate to a new site in some cases. However, it was still possible that the page of an attacker shares a process with the page of a victim. For example, cross-site iframes and cross-site pop-ups typically remain in the same process as the page that created them. This would allow a successful Spectrum attack to read data (for example, cookies, pbadwords, etc.) belonging to other frames or pop-ups in its process.
When site isolation is enabled, each rendering process contains site documents. This means that all navigations to cross-site documents cause a tab change in the processes. It also means that all cross-site iframes are placed in a different process from their parent frame, using out-of-process iframes. Splitting a single page into multiple processes is a major change in how Chrome works, and the Chrome security team has been pursuing this move for several years, regardless of Specter. The first uses of out-of-process iframes delivered last year to improve the Chrome extension security model.
Now, be split between several rendering processes using out-of-process iframes.
Even when each rendering process is limited to single site documents, there is always a risk that an attacker's page will access cross-site information. URLs by asking them as sub-resources, such as images or scripts. Web browsers usually allow pages to embed images and scripts from any site. However, a page might try to request an HTML or JSON URL with sensitive data like it 's an image or a script. This would normally fail to render and not expose the data to the page, but this data would end up in the rendering process where a Specter attack could access it. To mitigate this, the site isolation includes a feature called Cross-Origin Read Blocking (CORB), which is now part of the Fetch specification. CORB attempts to transparently block inter-site HTML, XML, and JSON responses from the rendering process, with virtually no impact on compatibility. To get the best protection for Site Isolation and CORB, web developers must verify that their resources are served with the correct MIME type and with the nosniff response header.
The site isolation is by far the most ambitious browser maker up to now. To date, most others have disabled the same specific timers as Chrome. These modifications make it more difficult to pirate sensitive data out of the restricted memory. If the Google site isolation works as expected, it goes a lot further by preventing the mixing of data from different areas.
In statements, officials at Microsoft and Mozilla said they were still looking for new mitigations. Firefox also provided this link to a small blog article published in January. However, neither Mozilla nor Microsoft provided any indication when or if the site's isolation came to Firefox, Edge or Internet Explorer.
