Vulnerability in Microsoft CTF protocol

[FranceBB]

CTF is part of the Windows Text Services Framework (TSF), the system that manages the text shown inside Windows and Windows programmes. 

When users start a programme, Windows also starts a CTF client for that programme. The CTF client receives instructions from a CTF server about the OS system language and the keyboard input methods.

If the OS input method changes from one language to another, then the CTF server notifies all CTF clients, who then change the language in each Windows programme accordingly, and in real-time. 

So far so good, but there's a problem: the communications between CTF clients and the CTF servers aren't properly authenticated or secured (I.e there's no access control in CTF). 

 

This is what Tavis Ormandy, a security researcher of the Google's Project Zero elite security team, had to say about this:

 

"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."

"So you could connect to another user's active session and take over any application, or wait for an Administrator to login and compromise their session."

 

And this is what Catalin Cinpanu (security expert) had to say:

"An attacker that hijacks another app's CTF session can then send commands to that app, posing as the server -- normally expected to be the Windows OS."

"Attackers can use this loophole to either steal data from other apps, or they can use it to issue commands in the name of those apps."

"If the apps run with high-privileges, then those actions can even allow the attacker to take full control over a victim's computer."

 

Now, I know what you're thinking "what if we disable it?" and... well... I don't really think we can, in fact, because of CTF's role (to show text inside ANY programme or service) there's a CTF session for literally everything and every user interface element on XP... Sure, antivirus softwares like Avast can try to prevent threats from getting to the computer, but what about those threats that haven't been discovered yet? Well, that's a problem. Besides, it's very unlikely that we're gonna get any update for XP/WES/POSReady at this point, so I assume that the vulnerability is gonna stay there and this is a pretty big one, I think, so... what are we gonna do now? Hope and pray for Microsoft to care enough about good old XP users and release a patch?

Link to Google project zero where I read about it: https://googleprojectzero.blogspot.com/2019/08/down-rabbit-hole.html?m=1

Side note: this is a thing I would generally write inside the POSReady 2009 update topic, but I feel like it has become way too big and since support is officially over and we're unlikely going to see any new update, I didn't want to bring it up again, but... if you feel like it should be inside that topic, feel free to move it and merge it, Dencorso.

Edited August 14, 2019 by FranceBB

[NojusK]

Not good, i wonder if Vista users with Server 2008 patches reseaved we might port it to XP/Server 2003 if it's possible 

[win32]

Another remedy to this problem is switching to extended Windows 2000 + Office 2000 (but not XP or later)!!! No msctf in any of my win2k installations!

Unfortunately the chance of a backported patch seems quite low, especially with the change in the underlying component that powers CTF from LPC to ALPC with Vista; the way in which CTF is implemented in XP seems quite different, as the ctfhookprocworker function referenced in the blog post doesn't exist in XP's user32.dll.

[Guest]

Quote

CTF has been part of Windows since XP, but ctftool only supports ALPC, which was introduced in Vista.

The patch fixes a security vulnerability of ALPC:

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1162

Also in the image below taken in the article:

I don't find MSCTF correspondence in my pc.

To verify use:

https://docs.microsoft.com/en-us/sysinternals/downloads/winobj

My pc:

I don't use Microsoft Office, so no ctfmon.exe in Process Explorer even if I open my TextMaker (Softmaker FreeOffice).

Conclusion:

My pc is not affected by this vulnerability

Edited August 14, 2019 by Sampei.Nihira

[Mathwiz]

I'm probably in way over my head here, but....

CTFMon.exe doesn't seem to exist on either my Windows XP system (even though Office 2010 is installed) or my Windows 7 one (even though Office 2013 is installed). Edit: That was wrong; CTFMon.exe does exist. (I was fooled by SwiftSearch doing a case-sensitive sort on file names.) But it doesn't seem to be running as a process.

Also, WinObj's "BaseNamedObjects" doesn't show any MSCTF* object names on either system. On Windows 7, there is a MsCtfMonitor task that is run at log-on. That task doesn't exist on XP.

Concentrating on XP hereinafter, MSCTF.dll and MSCTFIME.ime do exist, in C:\Windows\System32\. Per Process Explorer, most processes seem to have MSCTFIME.ime loaded. I assume that's necessary to read keyboard input. At least one (Windows Live Mail) also has MSCTF.dll loaded.

This makes me think that on at least some XP versions, CTF is implemented via simple .dll's vs. a client/server architecture; those versions may lack the vulnerabilities discovered by Google Project Zero. But the screen shot above implies that other XP versions do implement clients and a server, so they would be vulnerable.

It would be interesting to know which XP versions include CTFMon.exe - perhaps MUI versions, and/or versions with Eastern (Chinese/Japanese/Korean) characters?

Edited August 16, 2019 by Mathwiz

[win32]

My XP x64/2003 x86 have it, and they don't have Office installed.

Installed Office 2003 on Windows 2000 and got it there. Handwriting/speech input relies on it.

[Mathwiz]

So, XP probably comes with it; 2000/98/ME probably get it with Office XP or later. I wonder what starts the process? Let me try starting an Office 2010 app and see what happens.

Edit: Strange; Excel 2010, PowerPoint 2010, and Word 2010 don't seem to start CTFMon.exe. Maybe it only starts if you use one of those alternate input methods. If so, most of us are probably safe.

Edited August 16, 2019 by Mathwiz

[Guest]

Disable ctfmon.exe:

Control Panel > Regional and Language Options > Languages > Details > Advanced

check the box that says Turn off advanced text services.

[TrevMUN]

XP64 user here, my rig didn't ever have Microsoft Office installed. CTFMon's still present and running and I have the MSCTF objects.

I tried turning off advanced text services; this didn't close CTFMon. Would I need to restart to verify, or can I kill the process without doing so?

[Dave-H]

I used this to finally see the back of ctfmon.exe.
It does work!

Office Ctfmon Remover 2.3.zip

[Guest]

3 hours ago, TrevMUN said:

XP64 user here, my rig didn't ever have Microsoft Office installed. CTFMon's still present and running and I have the MSCTF objects.

I tried turning off advanced text services; this didn't close CTFMon. Would I need to restart to verify, or can I kill the process without doing so?

Try restarting, if it is present, disable ctfmon.exe in the msconfig.exe at startup.

Edited August 19, 2019 by Sampei.Nihira

[Vistaboy]

On 8/19/2019 at 4:23 PM, Dave-H said:

I used this to finally see the back of ctfmon.exe.
It does work!

Office Ctfmon Remover 2.3.zip

I've always use that to save memory/cpu and now i know i'm also preventing vulnerability 

[SC7601]

I always end that process because I thought it was not necessary to run Windows or any programs. (did the same for spoolsv.exe) And does simply removing it prevents the vulnerability or do I need to do something else?

[Mathwiz]

On 8/19/2019 at 9:23 AM, Dave-H said:

I used this to finally see the back of ctfmon.exe.
It does work!

Office Ctfmon Remover 2.3.zip

Just FYI, here's the author's Web page: http://www.gerhard-schlager.at/en/projects/ctfmonremover/

Has info on what CTFMon does and whether you need it.

Bottom line AIUI: you need CTFMon if you use

• Speech recognition
• Handwriting recognition
• Multiple keyboard layouts (e.g., for multiple languages)
• (Probably) Asian languages/character sets (Chinese, Japanese, Korean)

If you use none of the above, might as well get rid of it!

23 hours ago, DragonSC7601 said:

does simply removing it prevents the vulnerability or do I need to do something else?

AIUI it should prevent the vulnerability, which is caused by the CTFMon.exe service not validating requests from clients. The CTFMon remover appears to replace CTFMon with a dummy program that doesn't actually handle client requests, so I'd think it can't be used to compromise your system like the "real" CTFMon can.