From a small bit of skimming, sounds like it's a user escalation vector, where a low privileged user can run the installer in a contrived manner to achieve privilege escalation.
Headline is a little misleading imo -- the vulnerability isn't in Notepad++ itself as much as its installer. Current users, I imagine, don't have anything to worry about.
Unless the updater also runs the installer, then you just drop your malicious dll in the right place and wait for an update, or find a way to force-trigger an update.
Attackers can also use the notepad installer as a payload execution mechanism. To run your malware, just get older notepad++ installers and drop your dll after the installer is running to run it as SYSTEM.
For a non-admin user to get admin or system, that's a proper CVE. For an admin user behind uac though, uac bypasses aren't considered bypassing of a security boundary so no CVE there.
I had that thought of "existing installers are sus..." but didn't connect to "fingerprinting it as malware". Makes sense.
Couple questions as savvy tech person but not working day-to-day in security/IT:
Would a regular home user with an old installer in their Downloads folder need to worry? (is a bad download file going to target looking for these old installers, then moving files around, etc?)
On the other hand, I could see corporate IT having the stronger case of proactively wanting to flag this installer if present on their systems.
I wanted to say the installer has no business running things as SYSTEM but I suppose there is no way around that for registering COM DLLs. I would think Attackers would need to chain this with a Uac bypass (or be fortunate enough to find Uac disabled). If Uac is setup right, administrative operations like regsvr32 should require going through consent.exe's prompt. Uac bypasses are plenty but systems can be configured to mitigate them (at least the ones I know of). Social engineering is also another good way to bypass Uac.
Looks like it's a vulnerability in the installer.
From a small bit of skimming, sounds like it's a user escalation vector, where a low privileged user can run the installer in a contrived manner to achieve privilege escalation.
https://github.com/notepad-plus-plus/notepad-plus-plus/secur...
So for my personal install, nothing to worry about here...
Headline is a little misleading imo -- the vulnerability isn't in Notepad++ itself as much as its installer. Current users, I imagine, don't have anything to worry about.
Unless the updater also runs the installer, then you just drop your malicious dll in the right place and wait for an update, or find a way to force-trigger an update.
Attackers can also use the notepad installer as a payload execution mechanism. To run your malware, just get older notepad++ installers and drop your dll after the installer is running to run it as SYSTEM.
Meh, there's plenty of Microsoft services on a system that fall for the same trick. If an attacker has PC access, its game over anyway.
For a non-admin user to get admin or system, that's a proper CVE. For an admin user behind uac though, uac bypasses aren't considered bypassing of a security boundary so no CVE there.
Video of a POC: https://drive.google.com/drive/folders/11yeUSWgqHvt4Bz5jO3il...
Thanks for sharing!
If the problem is in the installer then this can't be 'fixed', affected installers should be fingerprinted as malware.
I had that thought of "existing installers are sus..." but didn't connect to "fingerprinting it as malware". Makes sense.
Couple questions as savvy tech person but not working day-to-day in security/IT:
Would a regular home user with an old installer in their Downloads folder need to worry? (is a bad download file going to target looking for these old installers, then moving files around, etc?)
On the other hand, I could see corporate IT having the stronger case of proactively wanting to flag this installer if present on their systems.
[dead]
I wanted to say the installer has no business running things as SYSTEM but I suppose there is no way around that for registering COM DLLs. I would think Attackers would need to chain this with a Uac bypass (or be fortunate enough to find Uac disabled). If Uac is setup right, administrative operations like regsvr32 should require going through consent.exe's prompt. Uac bypasses are plenty but systems can be configured to mitigate them (at least the ones I know of). Social engineering is also another good way to bypass Uac.
This is something that wouldn't be covered by registration free COM?
tbh, I have no idea. I know that is possible for .NET stuff but I don't know if there are downsides when you don't register it.
[dead]