CWE-422, nicknamed Shatter, covers a product running at elevated privileges that does not verify the source of a message in the Windows Messaging System. This creates an alternate channel through which an attacker can message the product directly.
How it happens
A privileged program has a window. Any process on the same desktop can send that window messages. If the program acts on them without checking who sent them, a low privilege user can steer a high privilege process.
MITRE's examples include gaining privileges via a Windows message (CVE-2002-1230), a control where a message changed a callback function pointer (CVE-2003-0350), and a product that launched Help at raised privileges, allowing command execution through an "open file" dialog (CVE-2003-0908).
What an attacker gains
Per the record: gain privileges or assume identity, and bypass protection mechanisms.
How to find it
No detection methods are listed. Review any Windows GUI code that runs elevated, especially services with windows, and list the messages it handles.
How to fix it
- Do not run GUI components at elevated privileges. Split the privileged work into a service with no window.
- Communicate with that service over an authenticated channel.
- Validate the sender and the content of every message that can trigger action.
- Avoid launching helper tools such as Help from a privileged process.
Why this one is old but not gone
The examples MITRE lists date from the early 2000s, when this attack style was named Shatter. The underlying rule still holds for any desktop software: a window owned by a privileged process is an input surface for every other process on the same desktop. Separating a privileged service from an unprivileged interface is the durable design answer, and it also shrinks the amount of code that runs with high privilege.
Quick check
Why is the elevated GUI the problem?
Windows messages can be sent between processes on the same desktop. An elevated window becomes a target for lower privileged senders.
