PR for Detecting Faulty Notepad++ Upgrades

Introduction:

I might be a bit behind the wave here, but I wanted to provide something to the community that has helped in my world.

As I am sure many folks are already aware, there were a host of vulnerabilities recently found and patched in Notepad++. Those include CVE-2023-40031, CVE-2023-40036, CVE-2023-40164, CVE-2023-40166 which you can read about on the NVD site for more information. In short, this caused a rush of folks trying to upgrade to version 8.5.7 which patches these issues.

Many organizations, my own included, use Patch My PC (PMP) to manage apps like Notepad++. Given that active patching was occurring and showing as successful in Intune, and our Log Analytics (which pulls app install information from the registry) also showed success, we felt we were up to snuff and safe. It fully appeared that 8.5.7 was successfully deploying and we were safe to move on without ever having even a second of concern.


The Problem:

Well… apparently not. You see, someone’s installation was flagged. Quite confused as the machine showed it was up to date in Control Panel, Log Analytics, and Intune, we went into Notepad++ and hit the help button. Much to our further confusion, we found that the app itself said its version was much older and concerningly did NOT at all match the registry. After investigating the install files, it became clear that despite the registry saying it was 8.5.7, it was not up to date. The files were ancient. In fact, it was actually 8.4.9, a hideously old version.


Why Did This Happen?

Note: Before I give this explanation of why, I want to say that I am not an expert on PMP nor the owner of it in my org, but I believe I have my ducks in a row here. Additionally, the root issue is not PMP’s fault in my opinion (that would be the NP++ upgrade behavior), they are just heavily involved in the explanation and could possibly implement a fix.

PMP seems to have three main ways of handling an update when the app is running. It either kills the running app and proceeds with the update, kills the update and will try again later with the hope being that the app is no longer running, or PMP just tries to go and hopes for the best. Just trying to go is seemingly the default option, at least that is what I have been told.

In my experience, when hit with that default option while the app is running, most apps succeed (although often need to be restarted) or simply fail and will still try again later. That is not the case with Notepad++. It seems if PMP tries to update it while Notepad++ is running, the registry updates, but nothing else does. The files of the app remain the same.

The huge problem there is that PMP’s detection rule for Notepad++ looks purely to the registry to validate that the app succeeded so, to them (and thus Intune) it appears that it has been completed. Thus, if you are like me and constantly leave Notepad++ running, you will slowly fall farther and farther behind as your registry continues to update like everything is okay, but the actual app and files are not updating.

Since Log Analytics pulls from the installed app registry, as just about any inventory system will, it too thinks you’re patched. The same goes for the control panel.

All in all, you wind up with an environment that looks like it’s patched, reports like it’s patched, but is not patched. That is not good. In our environment, after running the below detection script, it turned out that 3% of devices had this issue.

The Answer:

First, change your Notepad++ update packages to either kill Notepad++ then install or, to fail and try again later if the app is running. Do not leave them on the default behavior. That will take care of net new updates as they come out.

However, we still need to locate all your devices that aren’t actually up to date and fix them. Step one of that is to find them. Step two has a few options, one of which is to send them a package to uninstall Notepad++ and install the latest version. I am here to help with step one.


Locating Devices With Mismatched Registries to EXE Versions:

Luckily, there is a simple solution, relatively speaking anyway. You simply need a script that can go down to the device, look and see if Notepad++ is installed according to the registry, and then compare the registry version to the actual EXE version (which involves finding that EXE) to see if they match, then report back.

There is a script that does just that on my GitHub here.

If PMP were to upgrade their detection script with similar logic to also validate the EXE version, this issue could be avoided going forward even on the default “go even if it’s running” methodology. That could also just complicate things though, it’s just food for thought.


This script is to be deployed as an Intune Proactive Remediation detection script, run it as the System, and run it as 64-bit. There is no remediation although, you could make one to perform the needed remediation actions.

The script then reports back with three possible scenarios.

  1. Success: Notepad++ was not found
  2. Success: Notepad++ was found and the Registry and EXE match
  3. Failure: Notepad++ was found and the Registry and EXE do NOT match – this is followed by information on the registry versus EXE that was found.

For example, as seen in the Script Output column of the Proactive Remediation Device Status export:


The export also contains plenty of other information such as the device name, ID, employee, OS version, type (Hybrid or AAD), etc, which can then be used to build a static group of devices to target with say an app. Or, again, you could build a remediation script as well and have the PR itself as a more dynamic solution.

The script also has local logging which can be altered or shut off entirely if you wish. The logging location is controlled primarily via the variables region near the top.

Update:

I got some replies back from the PMP folks, thanks team!

First, yes, Notepad++ attempting to go while it is running is the ultimate root cause of the issue. To avoid situations like this with Notepad++ and other apps, they indeed recommend setting the conflicting process behavior to fail or kill, rather than attempt to install. They recently changed the conflicting process default behavior to be a failure, rather than to go ahead and try to install, to further prevent this. However, this only applies going forward to new apps customers select as they didn’t want to mess up clients purposefully selected existing options.


Conclusion:

With this Proactive Remediation script in hand, you can now identify your affected audience that you need to remediate. Good luck and happy hunting!



Disclaimer:

The following is the disclaimer that applies to all scripts, functions, one-liners, setup examples, documentation, etc. This disclaimer supersedes any disclaimer included in any script, function, one-liner, article, post, etc.

You running this script/function or following the setup example(s) means you will not blame the author(s) if this breaks your stuff. This script/function/setup-example is provided AS IS without warranty of any kind. Author(s) disclaim all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall author(s) be held liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the script or documentation. Neither this script/function/example/documentation, nor any part of it other than those parts that are explicitly copied from others, may be republished without author(s) express written permission. Author(s) retain the right to alter this disclaimer at any time. 

It is entirely up to you and/or your business to understand and evaluate the full direct and indirect consequences of using one of these examples or following this documentation.

The latest version of this disclaimer can be found at: https://azuretothemax.net/disclaimer/

Leave a comment