CVE-2002-0367

What is Windows smss.exe?

The Session Manager Subsystem (smss.exe) is the first user-mode process launched by the Windows kernel during system startup. It runs with SYSTEM privileges and is responsible for initializing the Windows environment: creating paging files, loading subsystems (Win32, POSIX, OS/2 on older versions), setting environment variables, and launching the WinLogon and CSRSS processes. Because smss.exe runs continuously as SYSTEM and manages the startup of other high-privilege processes, vulnerabilities in its interfaces can provide a direct path to full system compromise.

Overview

CVE-2002-0367 is a local privilege escalation vulnerability (CVSS 7.8) in the Windows Session Manager Subsystem. The debugging subsystem within smss.exe failed to authenticate programs that attempted to connect to the debug ports of other processes. A low-privileged local user could exploit this to gain administrator or SYSTEM privileges by connecting to the debug port of a privileged process. Microsoft issued a patch in early 2002. CISA added this to KEV in March 2022 — twenty years after the original fix — as part of a wave of historical CVE additions targeting long-unpatched legacy Windows deployments.

Affected Versions

Note: Windows XP and later versions were not affected. This vulnerability was relevant primarily to organizations still running legacy Windows NT 4.0 or Windows 2000 infrastructure, which persisted in certain industrial and government environments well past end-of-life.

Technical Details

Windows NT-family operating systems exposed a debugging interface that allowed a process to attach to another process's debug port and receive debug events. This was the foundation of Windows' user-mode debugging model. In the vulnerable configuration, smss.exe's implementation of this debugging subsystem did not require the connecting process to hold appropriate permissions before attaching to debug ports of processes running at higher privilege levels.

An attacker with local code execution at a standard user privilege level could:

1. Use the unauthenticated debug port connection to attach to a SYSTEM-level process
2. Inject code or manipulate the execution of that process
3. Execute arbitrary code in the security context of the target process, gaining SYSTEM-level privileges

This class of vulnerability — abusing debugging interfaces for privilege escalation — was common across Windows NT/2000-era systems before Microsoft significantly hardened debugging permissions in Windows XP SP2 and later.

Discovery

Reported to Microsoft through responsible disclosure in 2002. The vulnerability reflects the security model of late-1990s Windows design, where debugging facilities were accessible to local users without strict privilege checks, under the assumption that local code execution already represented a trusted context. The Windows security model evolved substantially after this era.

Exploitation Context

By 2022, Windows NT 4.0 and Windows 2000 had been end-of-life for many years, yet isolated instances persisted in:

• Industrial control systems: Legacy SCADA and process control systems often run on decades-old Windows versions embedded in control hardware
• Air-gapped or isolated networks: Some government and defense environments maintained unpatched legacy systems believed to be secured by network isolation
• Embedded systems: Windows NT/2000 embedded in specialized hardware (ATMs, medical devices, industrial controllers)

CISA's March 2022 KEV batch added numerous historical CVEs that threat actors were actively using against these legacy environments. The Conti ransomware group's playbook and various nation-state toolkits included legacy Windows exploits for use against unpatched infrastructure encountered during lateral movement.

Remediation

1. Apply all available Windows updates: For systems still running Windows NT 4.0 or Windows 2000, apply the relevant security update if not already done.
2. Migrate off end-of-life Windows versions: Windows NT 4.0 and Windows 2000 have been unsupported for over 15 years. Any remaining systems should be replaced or migrated to supported OS versions.
3. Network isolation: If replacement is not immediately possible, place legacy systems in isolated network segments with strict inbound/outbound firewall rules to limit the attack surface.
4. Monitor for local privilege escalation: Use host-based monitoring to detect unexpected process privilege escalation, particularly processes attaching to other processes' debug ports.