How MSI Center Exposed SYSTEM Privileges to Local Users

OEM utility software is a notorious breeding ground for local privilege escalation (LPE) vulnerabilities. Because these applications must bridge the gap between user-space UI controls and kernel-level hardware management, they frequently run background services with administrative or system-level privileges.

A stark example of this pattern was uncovered in MSI Center, a utility preinstalled on millions of MSI laptops and desktops. The application's background service, "Notebook Foundation," spawned an insecure named pipe that allowed any authenticated local user to execute arbitrary commands as LocalSystem in seconds.

This vulnerability highlights the dangers of relying on custom cryptographic wrappers to secure Inter-Process Communication (IPC) instead of using proper operating system access controls.

The Anatomy of the Named Pipe Flaw

Named pipes are a standard mechanism for IPC on Windows, allowing different processes to communicate and pass data. However, because they are exposed via the file system namespace (under \\.\pipe\), they must be secured with explicit access controls.

In the case of MSI Center, the Notebook Foundation service spawned a named pipe called \\.\pipe\MSI_SERVICE_2 on system boot. The service itself runs under the highly privileged LocalSystem security context. The vulnerability stems from how the service configured the pipe's Discretionary Access Control List (DACL):

CreateNativePipeSecurity("D:(A;OICI;GRGW;;;AU)(A;OICI;GA;;;BA)");
CreateNamedPipe("\\\\.\\pipe\\MSI_SERVICE_2", PIPE_ACCESS_DUPLEX);

To understand why this is a critical security failure, we must parse the Security Descriptor Definition Language (SDDL) string passed to CreateNativePipeSecurity:

• (A;OICI;GA;;;BA) grants Generic All (GA) permissions to Built-in Administrators (BA). This is expected.
• (A;OICI;GRGW;;;AU) grants Generic Read (GR) and Generic Write (GW) permissions to Authenticated Users (AU).

Because the Authenticated Users group includes any local user account that has successfully logged in, any low-privilege process running on the machine can open a read/write handle to this pipe.

The Illusion of Security via 3DES

MSI did not leave the named pipe entirely open to plaintext commands. Instead, they attempted to secure the channel using a custom protocol wrapped in Triple DES (3DES), an outdated symmetric-key cipher.

To interact with the service, a client application had to perform a handshake:

1. The client registers itself by sending an arbitrary client name string (e.g., ABCD123) to the pipe.
2. The client then sends its command payload, encrypted with 3DES, using that same client name as the encryption key.
3. Upon receiving the message, the Notebook Foundation service attempts to decrypt the payload by brute-forcing through its list of registered client names until one succeeds.

This design suffers from a fundamental logical flaw: the client chooses the key. Because the service trusts the client to provide both the key and the encrypted payload, there is no actual authentication happening. A low-privilege attacker can simply register a random string, encrypt a malicious command with that string as the 3DES key, and send it down the pipe. The service will happily decrypt it and execute it.

Even worse, the commands exposed by this pipe were incredibly powerful:

• PC REXE: Runs any executable with arbitrary arguments as LocalSystem.
• KEXE: Kills any running process on the system.
• Registry: Allows reading, writing, and deleting any registry key as LocalSystem.
• WMI: Allows modifying Windows Management Instrumentation settings, including Windows Defender exclusions.

By sending a PC REXE command containing a payload like cmd.exe or a malicious PowerShell script, an unprivileged local user could instantly spawn a shell with system-level privileges.

The Developer Angle: Securing Windows IPC

If you are building a Windows service that runs with elevated privileges, you must treat IPC boundaries as untrusted. Relying on custom application-layer cryptography to police access to a system-level pipe is a recipe for failure.

1. Restrict the DACL

Do not grant Authenticated Users write access to your named pipes unless there is a compelling, highly sandboxed reason to do so. If your UI helper only needs to be run by administrators, restrict the pipe to the Built-in Administrators group (BA) and Local System (SY).

In C#, you can use the NamedPipeServerStreamAcl class to enforce strict access rules:

using System.IO.Pipes;
using System.Security.AccessControl;
using System.Security.Principal;

var pipeSecurity = new NamedPipeSecurity();

// Allow Built-in Administrators Full Control
pipeSecurity.AddAccessRule(new PipeAccessRule(
    new SecurityIdentifier(WellKnownSidType.BuiltinAdministratorsSid, null),
    PipeAccessRights.FullControl,
    AccessControlType.Allow
));

// Allow Local System Full Control
pipeSecurity.AddAccessRule(new PipeAccessRule(
    new SecurityIdentifier(WellKnownSidType.LocalSystemSid, null),
    PipeAccessRights.FullControl,
    AccessControlType.Allow
));

using var pipe = NamedPipeServerStreamAcl.Create(
    "SecurePipeName",
    PipeDirection.InOut,
    NamedPipeServerStream.MaxAllowedServerInstances,
    TransmissionMode.Byte,
    PipeOptions.None,
    0,
    0,
    pipeSecurity
);

2. Use Impersonation

If your service must perform actions on behalf of a low-privilege client, use client impersonation. Windows named pipes allow the server to call ImpersonateNamedPipeClient. This temporarily drops the thread's security token to match the caller's token. If a low-privilege user attempts to trigger a file write or process execution through the pipe, the action will fail because the impersonated thread lacks the necessary permissions.

3. Validate Caller Identity

If you must allow non-admin users to connect to your pipe, validate the calling process before executing any commands. You can use the GetNamedPipeClientProcessId API to retrieve the process ID of the client on the other end of the pipe. Once you have the PID, you can inspect the executable path, verify its digital signature, and ensure it is a trusted binary signed by your organization.

The Sysadmin Reality: Managing OEM Bloatware

For system administrators, this vulnerability is a reminder of the security risks posed by OEM bloatware in enterprise environments. Utilities like MSI Center, ASUS Armoury Crate, and Dell SupportAssist are frequently targeted by security researchers because they introduce massive attack surfaces to otherwise clean Windows installations.

When deploying Windows machines in an enterprise, the safest approach is to use clean, vanilla Windows images that strip out all OEM-provided software. If hardware-specific utilities are required to manage fan curves, battery thresholds, or GPU profiles, they should be audited closely.

To audit active named pipes on your fleet, you can use Sysinternals Pipelist or run a PowerShell script to query active pipe security descriptors. Any pipe exposing write access to Authenticated Users while backed by a service running as SYSTEM should be treated as a high-risk vector.

MSI patched this vulnerability shortly after it was reported, but because they lacked the ability to issue a CVE directly, many users remained unaware of the risk until they requested one through MITRE. Ensure that any MSI devices in your inventory are running the latest version of MSI Center to mitigate this flaw.