Follina gets fixed – but it’s not listed in the Patch Tuesday patches!

A few hours ago, we recorded this week’s Naked Security podcast, right on Patch Tuesday itself.

It was just after 18:00 UK time when we hit the mics, which meant it was just after 10:00 Microsoft HQ time, which meant we had access to this month’s official June 2022 Security Updates bulletin from Redmond itself just before we started.

According to this bulletin, the CVEs fixed this month, listed in increasing numeric order, are as follows:

    CVE-2022-2007
    CVE-2022-2008
    CVE-2022-2010
    CVE-2022-2011
    CVE-2022-21123
    CVE-2022-21125
    [. . . .]
    CVE-2022-30184
    CVE-2022-30188
    CVE-2022-30189    <---jumps from this
    CVE-2022-30193    <---to this
    CVE-2022-32230

As you can see, CVE-2022-30190, popularly known as Follina, isn’t on the list.

We said as much in the podcast, and inferred (as we expect you did, too), that Follina either wasn’t really considered a bug, and therefore didn’t get fixed, or was still in the process of getting some sort of fix that wasn’t ready in time.

As you will no doubt recall (and as we will demonstrate and explain in tomorrow’s live Sophos Spotlight security webinar), we like to describe Follina as:

A feature that no one really wanted, combined with a feature no one really needed, to produce a malware implantation exploit than no one really expected.

Simply put (but please join us tomorrow for that 30 minute jargon-free explainer session!), you can use the Object Linking and Embedding (OLE) system in Windows to tell an Office document to fetch and display an HTML web page.

In that web page, you can embed a short JavaScript program that references a little-known proprietary Microsoft URL starting ms-msdt: in order to trigger the Microsoft Support Diagnostic Tool (MSDT).

(This, by the way, is the feature we can’t imagine anyone really wanted, given that OLE is typically used for pulling images into presentations or for embedding live spreadsheet data into documents, not for starting software tests for locally installed apps.)

Unfortunately, that ms-msdt: URL can not only be used to fire up the MSDT app, but also to feed it parameters so the user doesn’t need to choose the troubleshooting settings from the usual menus, including pre-identifying the app that needs testing by providing its precise path and filename.

And in that filename, you can embed a “metacommand” (a bit like Log4Shell or the recent Atlassian Confluence bug) buried inside a $(...) sequence of characters.

That weird sequence $(...)is apparently ignored when the system checks to see if the named app exists, so even though there aren’t any apps with $(...) in their names that could match those characters, and even though the troubleshooter should bail at this point, you don’t get an error and Windows ploughs on regardless.

But when the system actually kicks off its troubleshooting, that weird filename apparently gets re-processed, and the character sequence inside the $(...) markers isn’t used literally.

Instead, it’s executed as a PowerShell command that’s supposed to generate the text that will actually be used at that point in the filename.

(That, of course, is the feature that we can’t imagine anyone really needed, as useful and as “proactive” as it might have seemed at the time.)

Run-what-you-want

Loosely speaking, the embedded PowerShell code can do anything you want it to, from popping up a calculator to opening a reverse shell for a waiting cybercriminal (yes, we’ll show you how that part works in the demo, and how to stop it from happening).

You don’t even need to open a booby-trapped file in Word itself, because simply scrolling to an RTF file in File Explorer with the Preview Pane turned on is enough.

As you see here, moving the cursor to our test file t1.rtf opened up the Windows Troubleshooter automatically and popped up a calculator without any warning or Are you sure? message, based on the sneaky JavaScript URL in the booby-trapped HTML file loaded by our booby-trapped document:

Fixed after all

Having recorded the podcast, based on the June 2022 Security Update bulletin that we mentioned above, we checked with our sister site, Sophos News, where SophosLabs had by then published its own analysis of that security bulletin, covering the CVEs in the official list in useful detail.

But SophosLabs agrees: there was still no obvious sign of CVE-2022-30190 having been attended to!

Anyway, a short while after that, we noticed reports that the Follina bug was apparently “fixed” after all.

So we installed 2022-06 Cumulative Update for Windows 11 for x64-based Systems (KB5014697), rebooted…

…and this time, even though previewing our booby-trapped RTF triggered a web download and launched the troubleshooter, the Diagnostic Tool seemed to detect that sneakily-hidden $(...) sequence in the filename specification as an illegal value, and produced error 0x80070057, the numeric code for INVALID_PARAMETER:

We repeated the test with Windows 10, where (on our system) the update announced itself as 2022-06 Cumulative Update for Windows 10 Version 21H2 for x64-based Systems (KB5014699).

As on Windows 11, we could trivially exploit he bug (using the latest Microsoft 365 flavour of Office) before the update; couldn’t do so afterwards; and could once again exploit it after rolling back the update.

So, as far as we can see, the June 2022 “Patch Tuesday” update does suppress this bug, at least in our brief testing.

As mentioned above, we checked to see that the update was indeed the change that did the trick, by uninstalling KB5014697 (or KB5014699), and verifying that the exploit starting working once again.

Therefore, the CVE-2022-30190 bug does seem to have been recognised as a genuine security flaw by Microsoft, and it has been patched, even if you weren’t sure about that to start with, and even if it’s not officially acknowledged in the FAQs, Mitigations, and Workarounds section of this month’s security bulletin.

You’re welcome.