Skip to content

[BUG] Notepad3 loads attacker-controlled MSFTEDIT.DLL from the application directory via the About dialog #5605

@quart27219

Description

@quart27219

Summary

The latest rizonesoft/Notepad3 still performs a bare-name DLL load in the real About-dialog path. By placing an attacker-controlled MSFTEDIT.DLL in the application directory and triggering the About dialog, the current official Notepad3.exe loads the malicious DLL. This can lead to arbitrary code execution in the context of the user running Notepad3. It looks similar to CVE-2022-32168.

Details

The latest-source rizonesoft/Notepad3 still keeps the same unsafe DLL-loading behavior in the real About-dialog code path (src/Notepad3.c):

case IDM_HELP_ABOUT: {
    HMODULE const hRichEdit = LoadLibrary(L"MSFTEDIT.DLL");
    if (hRichEdit) {
        ThemedDialogBox(Globals.hLngResContainer, MAKEINTRESOURCE(IDD_MUI_ABOUT), hwnd, AboutDlgProc);
        FreeLibrary(hRichEdit);
    }
}
break;

The problem is the use of a bare DLL name with LoadLibrary() instead of a safe load from a trusted location such as System32. This leaves the application exposed to DLL search-order hijacking if an attacker can place a malicious MSFTEDIT.DLL in the application directory or another preferred search location.

This was validated on the real latest official release binary, not just on a helper harness. I launched the shipped Notepad3.exe, sent the Shift+F1 accelerator to trigger the IDM_HELP_ABOUT path, and confirmed that a malicious same-directory MSFTEDIT.DLL was actually loaded at runtime.

The malicious DLL wrote the following marker to the log:

FAKE_MSFTEDIT_LOADED

As a control, I also tested the same release bundle with minipath.exe and a fake uxtheme.dll, and that path did not trigger. So the confirmed strict path is specifically:

Notepad3.exe -> Shift+F1 -> About dialog -> LoadLibrary("MSFTEDIT.DLL")

This differs from the original Notepad++ fix, which hardened the same bug class by using LoadLibraryEx(..., LOAD_LIBRARY_SEARCH_SYSTEM32). The current Notepad3 code still preserves the unsafe bare-name load.

Reproduction

  1. Obtain the latest official Notepad3 release binary.
  2. Place an attacker-controlled MSFTEDIT.DLL in the same directory as Notepad3.exe.
  3. Start Notepad3.exe.
  4. Trigger the About dialog using the Shift+F1 accelerator.
  5. Observe that the malicious MSFTEDIT.DLL is loaded.

** The validation log confirms the malicious DLL load.

Impact

This is a DLL search-order hijacking vulnerability.

Who is impacted:
users launching the official Notepad3.exe
environments where an attacker can place files in the application directory or another preferred DLL search location

Security impact:
attacker-controlled DLL loading
arbitrary code execution in the context of the user running Notepad3
local privilege escalation potential if the program is run in a privileged context

Please check the information and fix the code.

Also, let me know if there is anything you need to know when you proceed with the patch.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions