Microsoft Edge Security Blog

> I often fall into the thinking of top 10 or 20 appstore app terms

You're not the only one. As far as I can tell, the vast majority of (particularly, but not exclusively) compiler work is driven by these edge cases.

As an example, when I look a the justifications for pushing undefined behavior exploitation in C, invariably some Very Smart Compiler Guy™ will state with great authority that this is absolutely essential and completely unavoidable. When you check more closely, it turns out that it enables a somewhat obscure optimisation that at best most people can do without and at worst is just about completely useless.

See Proebsting's Law, which was unduly optimistic, and also some of the work on variability in benchmarking, for example how different lengths of environment variables can dwarf most optimisation effects.

Daniel Bernstein stated this a bit more aggressively as "The Death of Optimising Compilers"[1]. He's not wrong, either, but when I mentioned this at a Google event, Chandler Carruth basically blew up and said it was complete garbage. Apparently he and Daniel almost came to blows over this at some conference.

At the time, Google was working on a far less optimising JS runtime for Chrome, after they found out that their super-simple runtime (mostly just interpreted) for small devices was beating their super-duper sophisticated Turbofan JIT on many real world tasks. And of course Microsoft found out that just turning off the JIT completely has marginal…

Yeah, static DCE is a limited optimization. I've personally given up on it. It's not useless, but it's a big lift for developers and the app size will keep growing anyway. These days I'm more interested in dynamic code paging systems as a way forward, but, at the moment I'm not able to work on that right now. Think about how "bloated" an app like Google Maps or Search is, yet it still feels fast because it downloads what it needs on demand. Everything should work that way.

The Conveyor installer is a native Win32 app written in C++. It's pretty trivial, it mostly just invokes some Windows APIs, works around bugs in those and ties the results to a progress bar. It's a classic app that uses HWNDs, window messages and the like. The bulk of the logic is in one file. Despite that it's about a 500kb EXE. Where do the bytes come from? Partly, it's C++. Native code is verbose and template instantiation creates a lot of it. You don't need to instantiate many std::vectors before suddenly binary size has crept up on you. The widespread adoption of C++ increased binary sizes significantly over C, because suddenly you were using value typed containers everywhere instead of a single shared linked list utility library.

GraalVM native executables start extremely fast, but they aren't small. Partly this is the mismatch problem again: operating systems don't provide stuff like built in garbage collectors, even though GC is a fundamental service nearly every app needs, so, programs ship…

Google is one of only a handful of companies in this world that can fundamentally change the state of security in the tech industry. I love google and have many friends who work there, I truly believe in their mission. They have the talent and the financial resources, but sometimes they do not use those in ways that are strategically scalable IMHO.

Here's some examples of ways they could use $100MM to completely flip the script on app security:

1) Google project zero - Some of the absolute best hackers in the entire world work on this team, they identify and exploit vulnerabilities at the same skill level of the best nation states. None of this significantly moves the needle. If they took this team, expanded it's skill-set, and redirected their efforts towards building protections for compilers, runtimes and framework then that would be much more impactful then showing off the next <ubiquitous software> 0day.

2) Google's partner program - Google has a program that forces all integrators of their OAuth APIs from Gmail to Gdrive to have 3rd party security assessments conducted. The 3rd parties they use put their most junior/scanner focused pentesters on those projects. The approved 3rd party vendors turn this into a cash cow because they hire kids straight out of school and bill them out at senior rates because the API integration partners are forced to use these junior teams. Instead they could create a register of ALL pentest companies and stop the SF/SV practice of…

I agree, this mode seems like something most people could manage without difficulty. Amusingly, my (non-Apple) system is much more locked down than this and isn't exactly unusuable IMO, although some things might be harder to manage on a phone.

Microsoft did some tests for Edgium's "Super Duper Secure Mode" and found that disabling JIT improves real world performance more often than it makes it worse (and usually makes no difference):

https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/

Diabling JIT makes it possible to enable some additional exploit mitigation methods. A follow up article mentioned that few people who tried it noticed a difference:

https://microsoftedge.github.io/edgevr/posts/Introducing-Enhanced-Security-for-Microsoft-Edge/

"It is worth mentioning that when we originally had this idea, we doubted our Microsoft Edge peers would even consider it. We quietly made changes to our browser without explicitly telling them the specifics and then asked them weeks later to see if they noticed the change. They would always say no, and only then would we inform them that we disabled the JIT. After surprising multiple developers in Microsoft Edge, we got the support needed to try this experiment. One can’t help but wonder what other well established assumptions about users and the web we should reconsider."

Weekly news of memory related CVE.

Keep using unsafe langs.

What will be there in next week? CVE in Chromium?

At this point betting sites should add category for that kind of games.

I do wonder what people of future will think about this:

"So they had research indicating that a lot of issues were related to memory, had technology which significantly reduces this issue, but they still kept doin mess for years?"

https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/

https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/

https://www.chromium.org/Home/chromium-security/memory-safety/

Memory issues and JIT (browsers) are two things that are responsible for disgusting amount of security issues

According to this analysis from Mozilla, over half of "in the wild" exploited vulnerabilities in chrome use bugs in the javascript JIT compiler.

https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO45JZNB1QZF9wuijK3OxBwr0/edit#gid=865365202

https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO45JZNB1QZF9wuijK3OxBwr0/edit#gid=0

(these links were found here https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/)

So it does appear that there is a fairly heavy connection between the two things.

I am not an expert in JITs or JIT related security issues, but from my understanding, since JITs get to bypass the normal W^X memory restrictions, it makes it a really nice target for exploits and RCE.