6 ms·

Microsoft Edge (Chromium) – Elevation of Privilege to Potential RCE

177 points by wglb 7y ago

spaceribs 7y ago
These are awesome finds, but also pretty troubling lack of care on both Microsoft and Chrome. 1. Why don't chrome:// pages have at least basic CSP setup to mitigate XSS? 2. Why isn't Microsoft using some sort of framework which abstracts them from direct DOM access?
- Lammy 7y ago
  RE: #1, I think it’s probably just one of those assumptions that passes over our collective heads until we have a wake-up call, like the need for TLS over leased fiber in the wake of the PRISM/MUSCULAR revelations. I could totally see a hypothetical “chain of changes” that lead to something like a lack of exploit mitigations on internal/preference pages. Those kind of interfaces used to be implemented with native OS GUI controls (or some facsimile like XUL), and I assume the collective thinking toward their security didn’t get rethought much when Chrome et al implemented them with web controls. Considering I’m here commenting about it and not discovering this myself just makes me thankful these things get found at all :)
- londons_explore 7y ago
  chrome:// pages do. But Microsoft didn't use a chrome:// URL, they instead gave the privileges to an https:// https:// URL, breaking the security model.
  - spaceribs 7y ago
    Ah, thanks for that info! The article made it seem like the entire implementation was done within chrome://
ChrisSD 7y ago
> The one thing that is unique about the [New Tab Page] in the new Edge is that it's actually an online website > [The New Tab Page] is actually a higher privileged page. This combination sounds risky no matter how you slice it. Amongst other things, your user's browser security now depends on the security of your user facing web site.
- ocdtrekkie 7y ago
  Another scary thing about Edge I hope they choose to amend in the future: Edge "stories" on the new tab page often include Outbrain/Taboola "stories". This means you can actually be one-click from launching Edge to a Windows support scam popup page. I originally looked at Edge as a very secure browser choice until I realized Microsoft's zeal for ad revenue meant it literally came with malicious links built-in.
  - geofft 7y ago
    Hm, how much would it cost to buy a "Experts Say This Software Is More Effective Than Antivirus" ad on the Edge new tab page that encourages you to download Chrome?
    - ocdtrekkie 7y ago
      That would just be another example of someone peddling malware from the Edge New Tab page...
      - giancarlostoro 7y ago
        I would be inclined to say some variant of adware moreso than malware.
    - rgoulter 7y ago
      Related: https://slatestarcodex.com/2019/03/04/prospiracy-theories/ https://slatestarcodex.com/2019/03/04/prospiracy-theories/
    - technion 7y ago
      Ironically, this is one of the first ads I saw when I tried the default Edge page: https://imgur.com/a/TY8CqK2 https://imgur.com/a/TY8CqK2 Text: "A browser that's 200% faster than Chrome". It's an ad for Brave.
- userbinator 7y ago
  I'm one of those who think that if you open a new tab or window, the only thing it should show is a blank page with the address bar focused, but I'm probably in the minority...
4684499 7y ago
> The one thing that is unique about the [New Tab Page] in the new Edge is that it's actually an online website IIRC Chrome used to use https://www.google.com/_/chrome/newtab https://www.google.com/_/chrome/newtab as its ntp.
- londons_explore 7y ago
  But it wasn't privileged. Specifically, it had access to a magic chrome:// URL which allowed listing the most recently used URL's in an opaque way (ie. so that if google went evil, they still couldn't see what your most visited site was or view it's thumbnail, despite it rendering on their webpage).
- abrowne 7y ago
  https://duckduckgo.com/chrome_newtab https://duckduckgo.com/chrome_newtab is the ntp if you choose DuckDuckGo,
ptx 7y ago
This relies on two different XSS bugs where the page displays messages by just jamming them straight into the HTML output rather than properly encoding text to HTML. This technique – reusing the unprocessed input straight up as the output – doesn't seem like the first tool people ought to reach for just to display a simple string, so maybe the frameworks and templating libraries used make it far too easy to do the wrong thing? In Mithril, for example, injecting raw HTML requires you to explicitly call the trust method[1], so doing it wrong is more work than doing it right, and the documentation is very clear about the risks of trusting data. In Thymeleaf, displaying text uses th-text, injecting raw HTML uses th-utext and the documentation[2] in clear on the difference, but this seems a bit more subtle and easy to miss for those who aren't familiar with the consequences. Microsoft's ASP.NET, from what I can tell, used to[3] do it the PHP-style wrong-by-default way, relying on developers' unfailing vigilance in remembering to call Html.Encode every single time they display a value if they wanted to avoid XSS, but in version 4 syntax was added for displaying values as text by default. Their newer Razor templating library apparently[4] also does the right thing. So... maybe these pages were created in old-style ASP.NET? Or have newer libraries recreated the mistakes of the past? [1] https://mithril.js.org/trust.html https://mithril.js.org/trust.html [2] https://www.thymeleaf.org/doc/tutorials/3.0/usingthymeleaf.html#unescaped-text https://www.thymeleaf.org/doc/tutorials/3.0/usingthymeleaf.h... [3] https://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 https://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-en... [4] https://blog.slaks.net/2011/01/dont-call-htmlencode-in-razor.html https://blog.slaks.net/2011/01/dont-call-htmlencode-in-razor...
- moomin 7y ago
  I seriously doubt (3) is a factor. Or if it is, it’s their own stupid fault. Razor, which fixes this idiocy of the original templating engine, has been the recommended approach for longer than Edge has been a thing.
londons_explore 7y ago
Whenever I read about bugs in Chrome, they are very complex multi step processes that were probably found with a fuzzer. This bug I see in Chromium based Edge looks like anyone could stumble across it, is far simpler, and smells like a lot less effort went into secure architecture design.
- yjftsjthsd-h 7y ago
  In all fairness, age/maturity of software is a thing that could affect that; it would be interesting to know if Chrome also had less low-hanging fruit when it was the same age as Chromium-Edge is now.

177 points by wglb 7y ago

These are awesome finds, but also pretty troubling lack of care on both Microsoft and Chrome. 1. Why don't chrome:// pages have at least basic CSP setup to mitigate XSS? 2. Why isn't Microsoft using some sort of framework which abstracts them from direct DOM access?

Lammy 7y ago
RE: #1, I think it’s probably just one of those assumptions that passes over our collective heads until we have a wake-up call, like the need for TLS over leased fiber in the wake of the PRISM/MUSCULAR revelations. I could totally see a hypothetical “chain of changes” that lead to something like a lack of exploit mitigations on internal/preference pages. Those kind of interfaces used to be implemented with native OS GUI controls (or some facsimile like XUL), and I assume the collective thinking toward their security didn’t get rethought much when Chrome et al implemented them with web controls. Considering I’m here commenting about it and not discovering this myself just makes me thankful these things get found at all :)
londons_explore 7y ago
chrome:// pages do. But Microsoft didn't use a chrome:// URL, they instead gave the privileges to an https:// https:// URL, breaking the security model.
- spaceribs 7y ago
  Ah, thanks for that info! The article made it seem like the entire implementation was done within chrome://

ChrisSD 7y ago

> The one thing that is unique about the [New Tab Page] in the new Edge is that it's actually an online website > [The New Tab Page] is actually a higher privileged page. This combination sounds risky no matter how you slice it. Amongst other things, your user's browser security now depends on the security of your user facing web site.

ocdtrekkie 7y ago
Another scary thing about Edge I hope they choose to amend in the future: Edge "stories" on the new tab page often include Outbrain/Taboola "stories". This means you can actually be one-click from launching Edge to a Windows support scam popup page. I originally looked at Edge as a very secure browser choice until I realized Microsoft's zeal for ad revenue meant it literally came with malicious links built-in.
- geofft 7y ago
  Hm, how much would it cost to buy a "Experts Say This Software Is More Effective Than Antivirus" ad on the Edge new tab page that encourages you to download Chrome?
  - ocdtrekkie 7y ago
    That would just be another example of someone peddling malware from the Edge New Tab page...
    - giancarlostoro 7y ago
      I would be inclined to say some variant of adware moreso than malware.
  - rgoulter 7y ago
    Related: https://slatestarcodex.com/2019/03/04/prospiracy-theories/ https://slatestarcodex.com/2019/03/04/prospiracy-theories/
  - technion 7y ago
    Ironically, this is one of the first ads I saw when I tried the default Edge page: https://imgur.com/a/TY8CqK2 https://imgur.com/a/TY8CqK2 Text: "A browser that's 200% faster than Chrome". It's an ad for Brave.
userbinator 7y ago
I'm one of those who think that if you open a new tab or window, the only thing it should show is a blank page with the address bar focused, but I'm probably in the minority...

4684499 7y ago

> The one thing that is unique about the [New Tab Page] in the new Edge is that it's actually an online website IIRC Chrome used to use https://www.google.com/_/chrome/newtab https://www.google.com/_/chrome/newtab as its ntp.

londons_explore 7y ago
But it wasn't privileged. Specifically, it had access to a magic chrome:// URL which allowed listing the most recently used URL's in an opaque way (ie. so that if google went evil, they still couldn't see what your most visited site was or view it's thumbnail, despite it rendering on their webpage).
abrowne 7y ago
https://duckduckgo.com/chrome_newtab https://duckduckgo.com/chrome_newtab is the ntp if you choose DuckDuckGo,

ptx 7y ago

This relies on two different XSS bugs where the page displays messages by just jamming them straight into the HTML output rather than properly encoding text to HTML. This technique – reusing the unprocessed input straight up as the output – doesn't seem like the first tool people ought to reach for just to display a simple string, so maybe the frameworks and templating libraries used make it far too easy to do the wrong thing? In Mithril, for example, injecting raw HTML requires you to explicitly call the trust method[1], so doing it wrong is more work than doing it right, and the documentation is very clear about the risks of trusting data. In Thymeleaf, displaying text uses th-text, injecting raw HTML uses th-utext and the documentation[2] in clear on the difference, but this seems a bit more subtle and easy to miss for those who aren't familiar with the consequences. Microsoft's ASP.NET, from what I can tell, used to[3] do it the PHP-style wrong-by-default way, relying on developers' unfailing vigilance in remembering to call Html.Encode every single time they display a value if they wanted to avoid XSS, but in version 4 syntax was added for displaying values as text by default. Their newer Razor templating library apparently[4] also does the right thing. So... maybe these pages were created in old-style ASP.NET? Or have newer libraries recreated the mistakes of the past? [1] https://mithril.js.org/trust.html https://mithril.js.org/trust.html [2] https://www.thymeleaf.org/doc/tutorials/3.0/usingthymeleaf.html#unescaped-text https://www.thymeleaf.org/doc/tutorials/3.0/usingthymeleaf.h... [3] https://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2 https://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-en... [4] https://blog.slaks.net/2011/01/dont-call-htmlencode-in-razor.html https://blog.slaks.net/2011/01/dont-call-htmlencode-in-razor...

moomin 7y ago
I seriously doubt (3) is a factor. Or if it is, it’s their own stupid fault. Razor, which fixes this idiocy of the original templating engine, has been the recommended approach for longer than Edge has been a thing.

londons_explore 7y ago

Whenever I read about bugs in Chrome, they are very complex multi step processes that were probably found with a fuzzer. This bug I see in Chromium based Edge looks like anyone could stumble across it, is far simpler, and smells like a lot less effort went into secure architecture design.

yjftsjthsd-h 7y ago
In all fairness, age/maturity of software is a thing that could affect that; it would be interesting to know if Chrome also had less low-hanging fruit when it was the same age as Chromium-Edge is now.