Update: As predicted there is a patch bypass for this, now labled as CVE-2022-26904

According to https://twitter.com/KLINIX5/status/1480996599165763587 this appears to be a patch for the code blogged about at https://halove23.blogspot.com/2021/10/windows-user-profile-service-0day.html. The details on this bug can be found at https://github.com/klinix5/ProfSvcLPE/blob/main/write-up.docx but I’ll summarize them here for brevity.

The original incomplete patch, aka CVE-2021-34484 is explained best by Mitja Kolsek at https://blog.0patch.com/2021/11/micropatching-incompletely-patched.html where he notes that bug was originally considered to be an arbitrary directory deletion bug that allowed a logged on user to delete a folder on the computer.

However upon reviewing the fix KLINUX5 found that it was possible to not only bypass the fix, but also make the vulnerability more impactful.

Specifically by abusing the User Profile Service’s code which creates a temporary user profile folder (to protect against the original user profile folder being damaged etc), and then copies folders and files from the original profile folder to the backup, one can instead place a symbolic link. When this symbolic link is followed, it can allow the attacker to create attacker-writeable folders in a protected location and then perform a DLL hijacking attack against high privileged system processes.

Unfortunately when patching this bug, Microsoft correctly assumed that one should check that the temporary user folder (aka C:\Users\TEMP), is not a symbolic link, but didn’t check to see if any of the folders under C:\Users\TEMP contains a symbolic link.

Note that as noted in https://blog.0patch.com/2021/11/micropatching-incompletely-patched.html this bug does require winning a race condition so exploitation is 100% reliable however there are ways to win the race condition as was shown in the code for the patch bypass published at https://github.com/klinix5/ProfSvcLPE/tree/main/DoubleJunctionEoP.

I’d keep an eye on this one as KLINIX5 has a habit of finding patch bypasses for his bugs and if he says Microsoft has messed things up again, more than likely there will be another patch bypass for this bug. I’m still looking into exactly what was patched here though.