Securing your extensions against compromised renderer processes

3,283 views
Skip to first unread message

Łukasz Anforowicz

unread,
Aug 26, 2019, 12:50:03 PM8/26/19
to Chromium Extensions
Chrome has introduced Site Isolation to make it harder for malicious web pages to steal data from the user's other web accounts, even if an attacker uses a Chrome security bug to compromise a renderer process. This greatly improves security for Chrome users, but it is possible for security issues in extensions to erode some of this protection.

This email provides guidance for how extension authors can help prevent extension security bugs that malicious web pages might use to bypass Site Isolation protections.

The most important advice is to treat content scripts as less trustworthy and possibly under the control of the page they're modifying. A malicious web page can influence the behavior of a content script, use a side channel attack like Spectre to leak data from the content script, or compromise Chrome's renderer process to gain full control over the content script.

More specifically, please audit your extension to ensure you follow these security best practices:
  • Protect against cross-site scripting when receiving messages from content scripts.
  • Avoid sending sensitive data to a content script if it should not leak to the web page. Secrets from the extension, data from other web origins, browsing history, and other sensitive data might be accessible to the web page if sent to the content script.
  • Limit the scope of privileged actions that can be triggered by content scripts.  Do not allow messages from content scripts to result in fetching arbitrary URLs or passing arbitrary arguments to extension APIs (e.g., chrome.tabs.create).
  • Validate and sanitize all messages and input from a content script.

For more security best practices see Stay Secure in the Chrome Extensions documentation. More details are outlined below, and please send any questions to site-isol...@chromium.org. Thank you for keeping Chrome users secure!

Best regards,

Lukasz Anforowicz, on behalf of the Site Isolation Team


Why now?  What has changed?

Extension developers have always needed to be careful about content scripts, which interact directly with potentially malicious web pages.  Following this guidance is especially important in light of two relatively recent events: the discovery of side-channel attacks like Spectre and the launch of Site Isolation in Chrome.

Site Isolation offers stronger defenses against cross-site attacks. Side channel attacks like Spectre can read any data from an attacker page's renderer process, so Site Isolation avoids putting data from other websites into the renderer process. Also, attackers who find a security bug in Chrome's renderer process may be able to compromise the process, allowing them to run arbitrary code or send spoofed messages to other Chrome processes. Site Isolation makes it harder for such processes to attack other websites.

These changes to Chrome make it more difficult for malicious web pages to attack other websites.  Based on bug reports we have received, we think that attackers may consider extensions as another attack vector and as a potentially easier way to attack other websites.  This is why we are proactively reaching out and highlighting the importance of extension security.


What is a compromised renderer process?

Attackers may find security bugs in Chrome's renderer process, such as in the JavaScript engine, DOM, or image parsing logic. Sometimes, these bugs may involve memory errors (e.g., a "use-after-free" bug) which allow an attacker's web page to execute their own, arbitrary, native code (e.g. assembly/C++ code, as opposed to Javascript code) in the renderer process. We call such a process a “compromised renderer.”

A compromised renderer is no longer constrained by the rules of JavaScript or the Same Origin Policy. Instead, it can access any data in the process or send forged messages to Chrome's browser process or extension processes, such as pretending to be an extension's content script.

The Chrome sandbox limits what damage a compromised renderer can do.  A compromised renderer has full access to any website hosted in it, but with Site Isolation the renderer can only host one website.  Thus, it is harder for an attacker's page to access other websites. Nevertheless, a compromised renderer can try to trick extensions into attacking other websites, for example by spoofing messages from a content script to the extension background page.


Why are content scripts at greater risk than background pages?

A content script runs in the same process as the web page it is modifying. If that web page is malicious, it can compromise the renderer process and impersonate a content script.  It is easy for an attacker to embed a malicious script or image in their own website in an effort to compromise the renderer process hosting the website.

In contrast, it is much more difficult to compromise the renderer process of an extension background page.  This is because we assume that extensions do not execute untrustworthy scripts or embed untrustworthy images.  Also, web iframes within extension background pages are hosted in a different renderer process.


Why should I protect my extension against compromised renderers?

The Chrome team does prioritize fixes for security bugs in Chrome's renderer process, so it may seem unnecessary for extensions to worry about them as well. However, such security bugs are common enough in practice that it is important to limit the damage they can cause. 

Protection against compromised renderers is why Chrome's architecture uses features like the sandbox and Site Isolation.  To escape the renderer sandbox or bypass Site Isolation, an attacker needs to find yet another bug; such bugs in Chrome are treated as high-severity security bugs.  Similar security bugs in extensions should also be treated as high severity by extension authors.

In addition, note that some of the attacks described here do not depend on bugs in Chrome.  For example, even without compromising a renderer, an attacker's web page can use side channel attacks like Spectre (which may leak data from the content script or elsewhere in the process) or a named items attack (to control variables across isolated worlds). 


What is Chrome doing to help me secure my extensions?

We are continuously working to make Chrome more secure through a variety of architectural efforts, security bug fixes, sandbox improvements, and other changes. It's also important that we provide extension developers the right tools and APIs to secure their extensions. Please let us know if you have any suggestions for ways to help you secure your extensions.

Some recent examples of Chrome security features we are considering thanks to community feedback are: Trusted Types support for extensions and a MessageSender.origin property.  Hopefully these examples illustrate what kind of security features we currently think might be beneficial for securing extensions against compromised content scripts.  Let us know if these ideas would be useful or if you have any other feature ideas.


Kent Brewster

unread,
Aug 26, 2019, 2:28:51 PM8/26/19
to Łukasz Anforowicz, Chromium Extensions
Hi, Łukasz. Thanks for the note, and for reminding us of the importance of secure browser extensions.

Just so I'm clear: does anything in here (or the linked Site Isolation page under Chromium Security) mean that the extension approval process will change? Dealing with the uncertainty around when Manifest V3 will be ( developable | shippable | required ) has left me feeling a little twitchy.

Thanks very much,

--Kent
> --
> You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/8d2e9ec2-7a86-48ef-a528-e652a10718d1%40chromium.org.

Simeon Vincent

unread,
Aug 26, 2019, 4:12:39 PM8/26/19
to Chromium Extensions, luk...@chromium.org
I'm not aware of any review changes related to site isolation. The Manifest V3 transition will not be fast. While we don't have an official timeline, I personally expect the transition to V3 to take at least a year. 

Simeon - @dotproto
Extensions Developer Advocate


On Monday, August 26, 2019 at 11:28:51 AM UTC-7, Kent Brewster wrote:
Hi, Łukasz. Thanks for the note, and for reminding us of the importance of secure browser extensions.

Just so I'm clear: does anything in here (or the linked Site Isolation page under Chromium Security) mean that the extension approval process will change? Dealing with the uncertainty around when Manifest V3 will be ( developable | shippable | required ) has left me feeling a little twitchy.

Thanks very much,

--Kent

> On Aug 26, 2019, at 9:50 AM, Łukasz Anforowicz wrote:
>
> Chrome has introduced Site Isolation to make it harder for malicious web pages to steal data from the user's other web accounts, even if an attacker uses a Chrome security bug to compromise a renderer process. This greatly improves security for Chrome users, but it is possible for security issues in extensions to erode some of this protection.
>
> This email provides guidance for how extension authors can help prevent extension security bugs that malicious web pages might use to bypass Site Isolation protections.
>
> The most important advice is to treat content scripts as less trustworthy and possibly under the control of the page they're modifying. A malicious web page can influence the behavior of a content script, use a side channel attack like Spectre to leak data from the content script, or compromise Chrome's renderer process to gain full control over the content script.
>
> More specifically, please audit your extension to ensure you follow these security best practices:
>         • Protect against cross-site scripting when receiving messages from content scripts.
>         • Avoid sending sensitive data to a content script if it should not leak to the web page. Secrets from the extension, data from other web origins, browsing history, and other sensitive data might be accessible to the web page if sent to the content script.
>         • Limit the scope of privileged actions that can be triggered by content scripts.  Do not allow messages from content scripts to result in fetching arbitrary URLs or passing arbitrary arguments to extension APIs (e.g., chrome.tabs.create).
>         • Validate and sanitize all messages and input from a content script.
>
> For more security best practices see Stay Secure in the Chrome Extensions documentation. More details are outlined below, and please send any questions to site-isolation-dev@chromium.org. Thank you for keeping Chrome users secure!
>
> Best regards,
>
> Lukasz Anforowicz, on behalf of the Site Isolation Team
>
>
> Why now?  What has changed?
>
> Extension developers have always needed to be careful about content scripts, which interact directly with potentially malicious web pages.  Following this guidance is especially important in light of two relatively recent events: the discovery of side-channel attacks like Spectre and the launch of Site Isolation in Chrome.
>
> Site Isolation offers stronger defenses against cross-site attacks. Side channel attacks like Spectre can read any data from an attacker page's renderer process, so Site Isolation avoids putting data from other websites into the renderer process. Also, attackers who find a security bug in Chrome's renderer process may be able to compromise the process, allowing them to run arbitrary code or send spoofed messages to other Chrome processes. Site Isolation makes it harder for such processes to attack other websites.
>
> These changes to Chrome make it more difficult for malicious web pages to attack other websites.  Based on bug reports we have received, we think that attackers may consider extensions as another attack vector and as a potentially easier way to attack other websites.  This is why we are proactively reaching out and highlighting the importance of extension security.
>
>
> What is a compromised renderer process?
>
> Attackers may find security bugs in Chrome's renderer process, such as in the JavaScript engine, DOM, or image parsing logic. Sometimes, these bugs may involve memory errors (e.g., a "use-after-free" bug) which allow an attacker's web page to execute their own, arbitrary, native code (e.g. assembly/C++ code, as opposed to Javascript code) in the renderer process. We call such a process a “compromised renderer.”
>
> A compromised renderer is no longer constrained by the rules of JavaScript or the Same Origin Policy. Instead, it can access any data in the process or send forged messages to Chrome's browser process or extension processes, such as pretending to be an extension's content script.
>
> The Chrome sandbox limits what damage a compromised renderer can do.  A compromised renderer has full access to any website hosted in it, but with Site Isolation the renderer can only host one website.  Thus, it is harder for an attacker's page to access other websites. Nevertheless, a compromised renderer can try to trick extensions into attacking other websites, for example by spoofing messages from a content script to the extension background page.
>
>
> Why are content scripts at greater risk than background pages?
>
> A content script runs in the same process as the web page it is modifying. If that web page is malicious, it can compromise the renderer process and impersonate a content script.  It is easy for an attacker to embed a malicious script or image in their own website in an effort to compromise the renderer process hosting the website.
>
> In contrast, it is much more difficult to compromise the renderer process of an extension background page.  This is because we assume that extensions do not execute untrustworthy scripts or embed untrustworthy images.  Also, web iframes within extension background pages are hosted in a different renderer process.
>
>
> Why should I protect my extension against compromised renderers?
>
> The Chrome team does prioritize fixes for security bugs in Chrome's renderer process, so it may seem unnecessary for extensions to worry about them as well. However, such security bugs are common enough in practice that it is important to limit the damage they can cause.
>
> Protection against compromised renderers is why Chrome's architecture uses features like the sandbox and Site Isolation.  To escape the renderer sandbox or bypass Site Isolation, an attacker needs to find yet another bug; such bugs in Chrome are treated as high-severity security bugs.  Similar security bugs in extensions should also be treated as high severity by extension authors.
>
> In addition, note that some of the attacks described here do not depend on bugs in Chrome.  For example, even without compromising a renderer, an attacker's web page can use side channel attacks like Spectre (which may leak data from the content script or elsewhere in the process) or a named items attack (to control variables across isolated worlds).
>
>
> What is Chrome doing to help me secure my extensions?
>
> We are continuously working to make Chrome more secure through a variety of architectural efforts, security bug fixes, sandbox improvements, and other changes. It's also important that we provide extension developers the right tools and APIs to secure their extensions. Please let us know if you have any suggestions for ways to help you secure your extensions.
>
> Some recent examples of Chrome security features we are considering thanks to community feedback are: Trusted Types support for extensions and a MessageSender.origin property.  Hopefully these examples illustrate what kind of security features we currently think might be beneficial for securing extensions against compromised content scripts.  Let us know if these ideas would be useful or if you have any other feature ideas.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

Kent Brewster

unread,
Aug 26, 2019, 4:51:43 PM8/26/19
to Simeon Vincent, Chromium Extensions, luk...@chromium.org
Thanks, that's just want I needed to hear.

--Kent

> On Aug 26, 2019, at 1:12 PM, Simeon Vincent <sim...@chromium.org> wrote:
>
> I'm not aware of any review changes related to site isolation. The Manifest V3 transition will not be fast. While we don't have an official timeline, I personally expect the transition to V3 to take at least a year.
>
> Simeon - @dotproto
> Extensions Developer Advocate
>
> On Monday, August 26, 2019 at 11:28:51 AM UTC-7, Kent Brewster wrote:
> Hi, Łukasz. Thanks for the note, and for reminding us of the importance of secure browser extensions.
>
> Just so I'm clear: does anything in here (or the linked Site Isolation page under Chromium Security) mean that the extension approval process will change? Dealing with the uncertainty around when Manifest V3 will be ( developable | shippable | required ) has left me feeling a little twitchy.
>
> Thanks very much,
>
> --Kent
>
> > On Aug 26, 2019, at 9:50 AM, Łukasz Anforowicz wrote:
> >
> > Chrome has introduced Site Isolation to make it harder for malicious web pages to steal data from the user's other web accounts, even if an attacker uses a Chrome security bug to compromise a renderer process. This greatly improves security for Chrome users, but it is possible for security issues in extensions to erode some of this protection.
> >
> > This email provides guidance for how extension authors can help prevent extension security bugs that malicious web pages might use to bypass Site Isolation protections.
> >
> > The most important advice is to treat content scripts as less trustworthy and possibly under the control of the page they're modifying. A malicious web page can influence the behavior of a content script, use a side channel attack like Spectre to leak data from the content script, or compromise Chrome's renderer process to gain full control over the content script.
> >
> > More specifically, please audit your extension to ensure you follow these security best practices:
> > • Protect against cross-site scripting when receiving messages from content scripts.
> > • Avoid sending sensitive data to a content script if it should not leak to the web page. Secrets from the extension, data from other web origins, browsing history, and other sensitive data might be accessible to the web page if sent to the content script.
> > • Limit the scope of privileged actions that can be triggered by content scripts. Do not allow messages from content scripts to result in fetching arbitrary URLs or passing arbitrary arguments to extension APIs (e.g., chrome.tabs.create).
> > • Validate and sanitize all messages and input from a content script.
> >
> > For more security best practices see Stay Secure in the Chrome Extensions documentation. More details are outlined below, and please send any questions to site-isol...@chromium.org. Thank you for keeping Chrome users secure!
> >
> > Best regards,
> >
> > Lukasz Anforowicz, on behalf of the Site Isolation Team
> >
> >
> > Why now? What has changed?
> >
> > Extension developers have always needed to be careful about content scripts, which interact directly with potentially malicious web pages. Following this guidance is especially important in light of two relatively recent events: the discovery of side-channel attacks like Spectre and the launch of Site Isolation in Chrome.
> >
> > Site Isolation offers stronger defenses against cross-site attacks. Side channel attacks like Spectre can read any data from an attacker page's renderer process, so Site Isolation avoids putting data from other websites into the renderer process. Also, attackers who find a security bug in Chrome's renderer process may be able to compromise the process, allowing them to run arbitrary code or send spoofed messages to other Chrome processes. Site Isolation makes it harder for such processes to attack other websites.
> >
> > These changes to Chrome make it more difficult for malicious web pages to attack other websites. Based on bug reports we have received, we think that attackers may consider extensions as another attack vector and as a potentially easier way to attack other websites. This is why we are proactively reaching out and highlighting the importance of extension security.
> >
> >
> > What is a compromised renderer process?
> >
> > Attackers may find security bugs in Chrome's renderer process, such as in the JavaScript engine, DOM, or image parsing logic. Sometimes, these bugs may involve memory errors (e.g., a "use-after-free" bug) which allow an attacker's web page to execute their own, arbitrary, native code (e.g. assembly/C++ code, as opposed to Javascript code) in the renderer process. We call such a process a “compromised renderer.”
> >
> > A compromised renderer is no longer constrained by the rules of JavaScript or the Same Origin Policy. Instead, it can access any data in the process or send forged messages to Chrome's browser process or extension processes, such as pretending to be an extension's content script.
> >
> > The Chrome sandbox limits what damage a compromised renderer can do. A compromised renderer has full access to any website hosted in it, but with Site Isolation the renderer can only host one website. Thus, it is harder for an attacker's page to access other websites. Nevertheless, a compromised renderer can try to trick extensions into attacking other websites, for example by spoofing messages from a content script to the extension background page.
> >
> >
> > Why are content scripts at greater risk than background pages?
> >
> > A content script runs in the same process as the web page it is modifying. If that web page is malicious, it can compromise the renderer process and impersonate a content script. It is easy for an attacker to embed a malicious script or image in their own website in an effort to compromise the renderer process hosting the website.
> >
> > In contrast, it is much more difficult to compromise the renderer process of an extension background page. This is because we assume that extensions do not execute untrustworthy scripts or embed untrustworthy images. Also, web iframes within extension background pages are hosted in a different renderer process.
> >
> >
> > Why should I protect my extension against compromised renderers?
> >
> > The Chrome team does prioritize fixes for security bugs in Chrome's renderer process, so it may seem unnecessary for extensions to worry about them as well. However, such security bugs are common enough in practice that it is important to limit the damage they can cause.
> >
> > Protection against compromised renderers is why Chrome's architecture uses features like the sandbox and Site Isolation. To escape the renderer sandbox or bypass Site Isolation, an attacker needs to find yet another bug; such bugs in Chrome are treated as high-severity security bugs. Similar security bugs in extensions should also be treated as high severity by extension authors.
> >
> > In addition, note that some of the attacks described here do not depend on bugs in Chrome. For example, even without compromising a renderer, an attacker's web page can use side channel attacks like Spectre (which may leak data from the content script or elsewhere in the process) or a named items attack (to control variables across isolated worlds).
> >
> >
> > What is Chrome doing to help me secure my extensions?
> >
> > We are continuously working to make Chrome more secure through a variety of architectural efforts, security bug fixes, sandbox improvements, and other changes. It's also important that we provide extension developers the right tools and APIs to secure their extensions. Please let us know if you have any suggestions for ways to help you secure your extensions.
> >
> > Some recent examples of Chrome security features we are considering thanks to community feedback are: Trusted Types support for extensions and a MessageSender.origin property. Hopefully these examples illustrate what kind of security features we currently think might be beneficial for securing extensions against compromised content scripts. Let us know if these ideas would be useful or if you have any other feature ideas.
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
> --
> You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/c53cbe62-098f-4934-b418-e10258eea9f3%40chromium.org.

Eric Lawrence

unread,
May 7, 2022, 9:02:09 AM5/7/22
to Chromium Extensions, Kent Brewster, Chromium Extensions, Łukasz Anforowicz, Simeon Vincent
There has been a recent claim that the sender.url property can be spoofed by a compromised renderer, and it was suggested that the new MessageSender.origin property should be used by extensions' security checks instead. Is this claim correct?

If so, shouldn't the browser kill an extension process (ReportBadMessage CHECK()) if the origin of the sender.url property does not match the unspoofable MessageSender.origin?


Łukasz Anforowicz

unread,
May 9, 2022, 12:42:10 PM5/9/22
to Eric Lawrence, Chromium Extensions, Kent Brewster, Simeon Vincent
On Sat, May 7, 2022 at 6:02 AM Eric Lawrence <bay...@gmail.com> wrote:
There has been a recent claim that the sender.url property can be spoofed by a compromised renderer, and it was suggested that the new MessageSender.origin property should be used by extensions' security checks instead. Is this claim correct?

Yes - security checks/decisions should in general be based on the origin, rather than on the URL.  This guidance helps work around some remaining gaps in IPC enforcement in Chrome, but this guidance applies even if compromised renderers are out of the picture:
  • URL can't be used to make security decisions when URL=about:blank, or URL=about:srcdoc
  • A sandboxed iframe (e.g. via iframe.sandbox attribute) at URL=https://example.com should *not* be able to act on behalf of the https://example.com origin (the sandboxed iframe should be associated with an opaque origin instead).

If so, shouldn't the browser kill an extension process (ReportBadMessage CHECK()) if the origin of the sender.url property does not match the unspoofable MessageSender.origin?

Yes.  We are trying to minimize the impact that the new IPC enforcements have on stability - we are waiting for https://crrev.com/c/3587823 to roll out to Beta, but once that happens (and we confirm that there is no spike in renderer kill reports) then we will resume the work on additional enforcements - I believe that sender.url should be covered by https://crrev.com/c/2848771

Eric Lawrence

unread,
May 9, 2022, 1:32:59 PM5/9/22
to Chromium Extensions, Łukasz Anforowicz, Chromium Extensions, Kent Brewster, Simeon Vincent, Eric Lawrence
Thanks,  Łukasz, this was super-useful!

Just so I understand the current situation a bit better, my quick read of the https://crrev.com/c/2848771 CL suggests that we aren't yet validating that the MessageSender.origin is reasonable and thus it too can presently be spoofed by a compromised renderer. Is that correct? Or is there some other protection elsewhere?

thanks again!

Łukasz Anforowicz

unread,
May 9, 2022, 1:53:32 PM5/9/22
to Eric Lawrence, Chromium Extensions, Kent Brewster, Simeon Vincent, Archana Simha
My recollection is a bit fuzzy here, but I think that:
  • sender.origin has been introduced relatively recently in https://crrev.com/c/1819353 by archanasimha@.
  • AFAICT *if* sender.origin is populated then it comes from (trustworthy, Browser-process-tracked) source_render_frame_host->GetLastCommittedOrigin().  source_render_frame_host is also trustworthy, because it is always retrieved via render_process_id which AFAICT comes from extensions::MessagingAPIMessageFilter::render_process_id_
  • OTOH sender.origin is only populated when the messages comes from a frame - it will not be populated when the message comes from a worker.  I don't remember why things are done this way - it seems in theory possible to determine the origin of the worker in the Browser process.  Maybe this is a bug (or at least a feature request).
  • The CL pointed out earlier will validate some aspects of ExtensionMsg_ExternalConnectionInfo::source_origin and ExtensionMsg_ExternalConnectionInfo::source_url.  AFAIU `source_origin` here has no relationship to `sender.origin` exposed to message-handling scripts of Chrome Extensions (i.e. AFAIU `source_origin` is a C++-only value).
Reply all
Reply to author
Forward
0 new messages