Hi, It's been many years since I have posted here. It's good to be back. Many years ago I revealed an area of security research that was far ahead of its time. I was working on a device driver that had the capability of scanning an executable during the initial process creation and all of its dependencies... and used a deterministic algorithm which located all system calls that were necessary for execution. The process was allowed to continue and only these system calls were available. https://www.wilderssecurity.com/thre...-challenge-64-bits.314015/page-2#post-2021004 This has partially been implemented by the engineers over at Microsoft. By calling the UpdateProcThreadAttribute function software engineers may now block the win32k graphics and window management subsystem on processes and threads that do not need these window/gdi capabilities. They can do this by defining: PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON Moving forward it would be great if Microsoft would make the decision to move the window management system and possibly the GDI subsystem out of the kernel and into usermode. Let's discus GDI and font rendering and further system call attack surface reduction: Most font formats (non-raster) are mathematical descriptions of shapes (bezier curves). The problem is... . It is difficult for humans to think of all error cases to handle when converting vector to raster. To make matters worse... some internet browsers and e-mail readers have added the capability to embed and render fonts in emails and web pages. Browser plugins such as flash can render remote fonts not installed on the local operating system. The Windows operating system has had the capability of font signing for over a decade. But this feature is not even used or enforced by the win32k subsystem. Microsoft Windows OpenType Font Signing Tool Microsoft Typography Font Signing November 2001 Adobe Beginner's Guide to Digitally Signing OpenType Fonts Yet, even here in the year 2016 if you are sitting at an important meeting... perhaps such as the democratic national convention... you can't even restrict your operating system to use only signed fonts. Hackers or perhaps even state actors can embed a font that causes an error during render/rasterization. Where does this exception occur? It can occur in kernelmode and with specially crafted fonts it may execute code. You can't even sandbox this... the font rendering occurs directly in the operating system kernel. It's a one-step sandbox escape and privilege escalation. The only way to mitigate this is to implement your own usermode font rendering. Any browser/e-mail plugin using the default operating system font rendering (such as Adobe Flash) will make your application vulnerable and your sandbox useless. There are perhaps many other window management and GDI drawing errors present in the win32k subsystem. In conclusion I firmly assert that Microsoft should consider moving the old window management and drawing subsystems out of the kernel and into usermode. End users should be also be given the option to only use signed locally-installed fonts. Moving forward into 2017++ it is imperative that we continue building a safer computing environment. Best Wishes, -MessageBoxA
Maybe you know, but Win10 have registry value to block untrusted fonts. Still it will be very good if MS can implement rendering engine in user mode. I think the reason they do this in kernel-mode is performance, and as I'm not techy I don't know what occur if it is done on user-mode.
