
Microsoft Edge (Chromium) – Elevation of Privilege to Potential RCE - wglb
https://leucosite.com/Edge-Chromium-EoP-RCE/
======
ChrisSD
> 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.

~~~
userbinator
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...

~~~
kerng
Totally agree, the first thing i always do is to change all those default
settings to have a more slick setup. A easy setup option to achieve that would
be neat.

This applies to Firefox also unfortunately...

~~~
jfk13
Firefox lets you choose "Blank Page" for new windows and tabs in
about:preferences#home -- isn't that easy enough?

~~~
kerng
Even then I still had to remove the Firefox Home Content features, like
Highlights, Top Sites, and a few others... maybe a clean & slick checkbox
during setup could achieve this.

~~~
jfk13
Even after choosing Blank Page in _both_ the "Homepage and new windows" and
"New tabs" settings? After setting both of those to blank, I'm not seeing any
of the Home content here, without needing to explicitly uncheck the various
categories within it.

------
spaceribs
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?

~~~
londons_explore
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
Ah, thanks for that info! The article made it seem like the entire
implementation was done within chrome://

------
londons_explore
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
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.

------
ptx
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.h...](https://www.thymeleaf.org/doc/tutorials/3.0/usingthymeleaf.html#unescaped-
text)

[3] [https://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-
en...](https://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-encoding-
output-in-asp-net-4-and-asp-net-mvc-2)

[4] [https://blog.slaks.net/2011/01/dont-call-htmlencode-in-
razor...](https://blog.slaks.net/2011/01/dont-call-htmlencode-in-razor.html)

~~~
moomin
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.

------
4684499
> 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
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).

