Microsoft Edge (Chromium) – Elevation of Privilege to Potential RCE | Hacker News Reader

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

leucosite.com

177 pointswglb27 comments

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

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.

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?

That would just be another example of someone peddling malware from the Edge New Tab page...

I would be inclined to say some variant of adware moreso than malware.

Ironically, this is one of the first ads I saw when I tried the default Edge page:

https://imgur.com/a/TY8CqK2

Text: "A browser that's 200% faster than Chrome". It's an ad for Brave.

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

That is what I'd prefer as well. I thought Firefox had taken away the ability to set the new tab page to `about:blank` but I just checked and it seems that it does direct to there now. For a while the best I could do was to turn off all the widgets on their default "home" screen.

Safari does that but can also show your (locally stored) bookmarks/favorites, which is a handy addition

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

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

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.

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.

I have mine set to be a mostly blank page with a clock. SuperEvilNew tab is another chrome extension that lets you place arbitrary HTML on the new tab page, and in your case you could you define an empty page with some background color.

At least being online means they can fix it quickly. (Until the next marketing update that adds a vulnerable script, natch.)

Back in the IE5 days they had similar bugs in res:// (DLL resource) pages, running in the then-highly-privileged My Computer Zone. Took years of reporting the same kind of crap before they finally deprivileged it.

New browser, new code base, new devs... all the old bugs are new again.

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?

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 :)

chrome:// pages do. But Microsoft didn't use a chrome:// URL, they instead gave the privileges to an https:// URL, breaking the security model.

Ah, thanks for that info! The article made it seem like the entire implementation was done within chrome://

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.

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.

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

[2] https://www.thymeleaf.org/doc/tutorials/3.0/usingthymeleaf.h...

[3] https://weblogs.asp.net/scottgu/new-lt-gt-syntax-for-html-en...

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

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.

> 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 as its ntp.

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

https://duckduckgo.com/chrome_newtab is the ntp if you choose DuckDuckGo,

Reply on news.ycombinator.com