Hi. I am wondering if someone can explain what information is based on to create relevances in the Microsoft monthly released security patch fixlets. I am trying to ask this question in a general way. Is relevance created based on some type of information Microsoft provided and way I can access it?
In more specific on what I am working on. I have some servers which keep applicable to multiple version of MS Office(2007, 2010 and 2016) patch fixlets. The patches associated with these office products will attempt to apply but all getting exitcode 17029… Further looking into it, these devices had Office or Office components installed but have been removed. My guess is some of the DLL or files got left behind after the removal. But MBSA scan will show the devices don’t need any patches but yet Fixlets are applicable. And then my Security team ran Qualys scan and appear Qualys is also detecting based existence of the DLL files and report the vulnerabilities’ exist on the devices. So, I am trying to gather information on how the relevancies are developed for these fixlets and try to proven that they detect correctly…
Fixlets for Office family product typically use registry data. They will check in “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products” for the product IDs that the patch applies to and if it exists and has the expect version in the InstallProperties hive and that does not have the expected Patch GUID in the Patches sub hive, the fixlet will then go on to check other registry keys for data that indicates if the patch is installed or not.
This from a machine showing 1 aspect for why fixlet 401831301 “MS19-FEB: Security update for Office 2010 - Office 2010 SP2 - KB4018313 (x64)” would be detected as not relevant. (if the “Patches” subkey was missing, it could be detected as Relevant)
If you know a system had a version of Office installed and you’re seeing patches for Office being relevant, I’d recommend Office Scrub. This is a Microsoft tool that goes back at least to 2010 which will remove old traces of Office installs to deal with issues like this.
Office is notoriously terrible since it shares a lot of Common Files with other Microsoft products, and you’ll quite often see these kinds of false positives related to Office due to orphaned DLLs or registry keys.
Be wary of 17029 errors. They can affect the reports by Microsoft Updates and MBSA.
I’ve posted some info about it here:
An easy way to demonstrate this is install an Office product (Office suite, Sharepoint Designer, etc) on a test system.
Do an MS update scan, which would report back a ton of Office updates needed since this is new installation which hasn’t yet been patched. Then delete .msi files and .msp files in the C:\Windows\Installer folder. At this point, you can try installing one of the updates reported in the scan and you would get an 17029 exit code. Now run the MS update scan again and you would see that it now reports zero Office updates needed.
Wanted to answer the question about the relevance. Generally, relevance for Office fixlets are based off of information gleaned from the package internals.
If you extract the contents of an Office update package, you will usually find an xml document in it detailing the GUID’s and versions that will be patched as well as the patch’s GUID.