Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


Sign in to follow this  
FranceBB

Vulnerability in Microsoft CTF protocol

Recommended Posts

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 by FranceBB

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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! :P

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.

Share this post


Link to post
Share on other sites
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:

XKTlDhXE_o.png

I don't find MSCTF correspondence in my pc.

To verify use:

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

My pc:

m6MaNovM_o.jpg

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 by Sampei.Nihira

Share this post


Link to post
Share on other sites

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 by Mathwiz

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Mathwiz

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...