CWE-618, Exposed Unsafe ActiveX Method, describes an ActiveX control built for a web browser that exposes methods able to act outside the browser's zone or domain restrictions. It mostly matters to teams still maintaining legacy Windows software with browser components.
How it happens
ActiveX controls can exercise far greater control over the operating system than typical Java or JavaScript. A control may offer a method that downloads a file, launches a program or writes to disk. If the method does not validate its arguments, and nothing checks where the call came from, any page that can instantiate the control can invoke it.
MITRE's observed examples show the pattern. One control downloaded a file to an arbitrary folder (CVE-2007-1120). Another downloaded and executed a URL passed as a parameter. A third had a method argument that caused a buffer overflow.
What an attacker gains
The record lists the impact as "Other", because the result depends on what the exposed method does. In the examples above that ranged from arbitrary file writes to running remote content.
How to find it
Automated static analysis can find some instances by tracing how method arguments flow into file, process or network calls. In practice, also review every method a control registers for scripting and ask what a hostile page could pass to it.
How to fix it
From the MITRE mitigations:
- If you must expose a method, validate all of its arguments and guard against the vulnerabilities that the method's behavior could create.
- Use code signing, knowing it does not protect against weaknesses already present in the control.
- Where possible, avoid marking the control as safe for scripting.
The best fix is removal. If a control no longer has a real business use, retire it instead of hardening it.
Quick check
Does code signing fix an unsafe exposed method?
No. MITRE notes that signing does not protect against weaknesses already in the control. It only helps establish where the control came from.
