4 ms·

The earlier post on Code Integrity Guard and Arbitrary Code Guard is also interesting: https://blogs.windows.com/msedgedev/2017/02/23/mitigating-arbitrary-nati

The earlier post on Code Integrity Guard and Arbitrary Code Guard is also interesting: https://blogs.windows.com/msedgedev/2017/02/23/mitigating-arbitrary-native-code-execution/ https://blogs.windows.com/msedgedev/2017/02/23/mitigating-ar... Microsoft should apply these same restrictions to all UWP apps. Yes, that means banning JIT compilation, as Apple does on iOS. And desktop applications shouldn't be able to inject DLLs into UWP applications and system components.

comex 10y ago
In theory, they've always banned JIT in UWP apps, at least by default. UWP apps can't use VirtualProtect; they have to use VirtualProtectFromApp, which only allows JIT if you have the "codeGeneration" capability (and always enforces W^X). I don't use Windows so I don't know how it interacts with this new thing. Maybe the protection wasn't enforced at the kernel level? On any platform, it makes sense to enforce code signing by default as a hardening measure, but some apps like browsers cannot operate without a JIT. So there needs to be some exception process - possibly requiring the use of a separate process for JIT compilation, as Edge now does. You don't want to end up like iOS where Safari is the only browser permitted on the platform.
- contextfree 10y ago
  Modern apps completely banned JIT back in the Windows 8.x days (except for the CLR which was whitelisted), the APIs/capabilities you mentioned were only added in Windows 10.
JamesNK 10y ago
UWP apps from the Windows Store already ban JIT compilation - at least for .NET apps. When .NET UWP applications are uploaded the store pre-compiles them on the server with .NET Native. The user only downloads and executes native code.
- Kipters 10y ago
  Not really, the .NET Native step is performed at build time, the packages the developer uploads to the Store are AOT-compiled
  - JamesNK 10y ago
    You can .NET Native on your own machine for testing but the package uploaded to the store contains MSIL. The final .NET Native version is then compiled in the cloud. https://blogs.windows.com/buildingapps/2015/08/20/net-native-what-it-means-for-universal-windows-platform-uwp-developers/ https://blogs.windows.com/buildingapps/2015/08/20/net-native... One great feature of .NET Native is that the compiler is capable of being hosted in the cloud. When you build your Store package in Visual Studio, two packages are created – one .appxupload and one “test” .appx for sideloading. The .appxupload contains the MSIL binaries as well as an explicit reference to the version of the .NET Native toolchain your app consumes (referenced in the AppxManifest.xml). This package then goes to the Store and is compiled using the exact same version of the .NET Native toolchain. Since the compiler is cloud hosted, it can be iterated to fix bugs without you having to recompile your app locally.
rossy 10y ago
> Microsoft should apply these same restrictions to all UWP apps. Yes, that means banning JIT compilation, as Apple does on iOS. I really wish they didn't. Banning JIT means banning alternative web browsers (with alternative JavaScript engines,) banning other languages that use a runtime with a JIT, and making it very difficult to write programs that need a JIT for performance, like video game emulators. Banning JIT outright like Apple does makes for a less useful computing platform. What's worse is that if certain operating-system components are allowed to break the rules (like the built-in JavaScript engine,) it locks you in to the vendor's implementation of these components. Imagine if you could only use the CLR and not the JVM on Windows. Mitigating RCEs is important, but it's not that important. Making it a policy that can be enabled per-app (like Windows 10, according to a sibling comment) is fine though.
MohammadLee 10y ago
Sure, it does sound interesting. Now what about all EMET mitigations that Microsoft is deprecating by saying Windows 10 is "secure enough" as is?
- ryuuchin 10y ago
  Most of them are just built into Windows now and are accessible through both the registry[1] and at runtime[2][3]. The latter requires recompiling with source code changes but the former can be applied to any application. The EMET mitigations which are no longer supported have either been depreciated because of better ones (control flow guard) or are not terribly effective (EAF/EAF+, use of debug registers). [1] https://theryuu.github.io/ifeo-mitigationoptions.txt https://theryuu.github.io/ifeo-mitigationoptions.txt [2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms686880%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... [3] https://msdn.microsoft.com/en-us/library/windows/desktop/hh769088%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/hh7...
  - MohammadLee 10y ago
    I get your point, but most does not mean all, and hardening is all about adding layers. https://insights.sei.cmu.edu/cert/2016/11/windows-10-cannot-protect-insecure-applications-like-emet-can.html https://insights.sei.cmu.edu/cert/2016/11/windows-10-cannot-... is a complete review of the mitigations we are loosing.

comex 10y ago

In theory, they've always banned JIT in UWP apps, at least by default. UWP apps can't use VirtualProtect; they have to use VirtualProtectFromApp, which only allows JIT if you have the "codeGeneration" capability (and always enforces W^X). I don't use Windows so I don't know how it interacts with this new thing. Maybe the protection wasn't enforced at the kernel level? On any platform, it makes sense to enforce code signing by default as a hardening measure, but some apps like browsers cannot operate without a JIT. So there needs to be some exception process - possibly requiring the use of a separate process for JIT compilation, as Edge now does. You don't want to end up like iOS where Safari is the only browser permitted on the platform.

contextfree 10y ago
Modern apps completely banned JIT back in the Windows 8.x days (except for the CLR which was whitelisted), the APIs/capabilities you mentioned were only added in Windows 10.

JamesNK 10y ago

UWP apps from the Windows Store already ban JIT compilation - at least for .NET apps. When .NET UWP applications are uploaded the store pre-compiles them on the server with .NET Native. The user only downloads and executes native code.

Kipters 10y ago
Not really, the .NET Native step is performed at build time, the packages the developer uploads to the Store are AOT-compiled
- JamesNK 10y ago
  You can .NET Native on your own machine for testing but the package uploaded to the store contains MSIL. The final .NET Native version is then compiled in the cloud. https://blogs.windows.com/buildingapps/2015/08/20/net-native-what-it-means-for-universal-windows-platform-uwp-developers/ https://blogs.windows.com/buildingapps/2015/08/20/net-native... One great feature of .NET Native is that the compiler is capable of being hosted in the cloud. When you build your Store package in Visual Studio, two packages are created – one .appxupload and one “test” .appx for sideloading. The .appxupload contains the MSIL binaries as well as an explicit reference to the version of the .NET Native toolchain your app consumes (referenced in the AppxManifest.xml). This package then goes to the Store and is compiled using the exact same version of the .NET Native toolchain. Since the compiler is cloud hosted, it can be iterated to fix bugs without you having to recompile your app locally.

rossy 10y ago

> Microsoft should apply these same restrictions to all UWP apps. Yes, that means banning JIT compilation, as Apple does on iOS. I really wish they didn't. Banning JIT means banning alternative web browsers (with alternative JavaScript engines,) banning other languages that use a runtime with a JIT, and making it very difficult to write programs that need a JIT for performance, like video game emulators. Banning JIT outright like Apple does makes for a less useful computing platform. What's worse is that if certain operating-system components are allowed to break the rules (like the built-in JavaScript engine,) it locks you in to the vendor's implementation of these components. Imagine if you could only use the CLR and not the JVM on Windows. Mitigating RCEs is important, but it's not that important. Making it a policy that can be enabled per-app (like Windows 10, according to a sibling comment) is fine though.

MohammadLee 10y ago

Sure, it does sound interesting. Now what about all EMET mitigations that Microsoft is deprecating by saying Windows 10 is "secure enough" as is?

ryuuchin 10y ago
Most of them are just built into Windows now and are accessible through both the registry[1] and at runtime[2][3]. The latter requires recompiling with source code changes but the former can be applied to any application. The EMET mitigations which are no longer supported have either been depreciated because of better ones (control flow guard) or are not terribly effective (EAF/EAF+, use of debug registers). [1] https://theryuu.github.io/ifeo-mitigationoptions.txt https://theryuu.github.io/ifeo-mitigationoptions.txt [2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms686880%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... [3] https://msdn.microsoft.com/en-us/library/windows/desktop/hh769088%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/hh7...
- MohammadLee 10y ago
  I get your point, but most does not mean all, and hardening is all about adding layers. https://insights.sei.cmu.edu/cert/2016/11/windows-10-cannot-protect-insecure-applications-like-emet-can.html https://insights.sei.cmu.edu/cert/2016/11/windows-10-cannot-... is a complete review of the mitigations we are loosing.