Google Project Zero's IT security specialist, Tavis Ormandy, discovered a very serious security vulnerability that Windows users have been exposed to for almost 20 years. The threat applies to all editions of the system, from XP to the commonly used W10.
The author of the discovery informed Microsoft about the error, but the company did nothing about it for 90 days. Therefore, a description of the process enabling escalation of user privileges to the SYSTEM level and evidence (including prepared tools) confirming the existence of the vulnerability were uploaded online. Microsoft released a patch at the last minute, but it is not known exactly what it fixes.
Why hasn't anyone discovered this problem before? It's hard to say. It is possible that everyone assumed that it was impossible to look for holes in a place that simply had to be very well secured.
What's it all about??
Windows allows open windows to communicate with each other. However, it may happen that two programs are run in two different contexts - one with standard user privileges and the other (for example, a command line) with administrator privileges. In such a situation, in order to prevent a potential attack using messages sent through windows, the User Interface Privilege Isolation mechanism blocks this possibility. At least in theory.
"It wouldn’t make sense if an unprivileged window could just send commands to a highly privileged window, and that’s what UIPI, User Interface Privilege Isolation, prevents. (...) The tool showed that unprivileged applications were allowed to send messages in the 0xCNNN range to most of the applications I tested, even simple applications like Notepad. I had no idea message numbers even went that high! (In Windows, different types of communication are assigned separate message numbering ranges and it turns out that the security measures work selectively - editorial note)"
This leaves us with the question as to why the messages are being allowed through, but it was not an easy task and took a few weeks. Ormandy eventually found the causes of the problem in the MSCTF component, which is relatively little known, despite the fact that it is an important part of the system.
"That library is the one creating these messages and changing the message filters. It turns out CTF is part of the Windows Text Services Framework. The TSF manages things like input methods, keyboard layouts, text processing and so on. (...)
Suffice to say, CTF is vast and complex. The CTF system was most likely designed for LPC (Local Interprocess Communication) in Windows NT and bolted onto ALPC when it became available in Vista and later. The code is clearly dated with many legacy design decisions.
Booze, Blackjack and Hookers...
The fact that the library has a lot of legacy solutions is not such an important problem as the fact that the CTF component does not have any control over the authentication of processes that use its benefits."
"Any application, any user - even sandboxed processes - can connect to any CTF session. Clients are expected to report their thread id, process id and HWND, but there is no authentication involved and you can simply lie."|
The video presents the escalation of authorization with the use of prepared scripts. In theory, Microsoft has already fixed these gaps, but Ormandy is not convinced about it.
They waited literally until the last second, so I haven't had a chance to review these patches yet. I understand that the update will not be complete yet, but it should fix the most important vectors. I haven't seen an updates yet, so I'm not sure. It turns out it was possible to reach across sessions and violate NT security boundaries for nearly twenty years, and nobody noticed," summed up Ormandy.
I wonder if Microsoft will decide to speak on this matter and what will be the next steps of the creators of Windows. It is to be hoped that the holes will actually be fixed, and finding a bug in such an important component of the system will not lead to the opening of a "Pandora's box" and a flood of other similar threats.