CVE-2021-43844 in MSEdgeRedirect
Summary
by MITRE • 12/21/2021
MSEdgeRedirect is a tool to redirect news, search, widgets, weather, and more to a user's default browser. MSEdgeRedirect versions before 0.5.0.1 are vulnerable to Remote Code Execution via specifically crafted URLs. This vulnerability requires user interaction and the acceptance of a prompt. With how MSEdgeRedirect is coded, parameters are impossible to pass to any launched file. However, there are two possible scenarios in which an attacker can do more than a minor annoyance. In Scenario 1 (confirmed), a user visits an attacker controlled webpage; the user is prompted with, and downloads, an executable payload; the user is prompted with, and accepts, the aforementioned crafted URL prompt; and RCE executes the payload the user previously downloaded, if the download path is successfully guessed. In Scenario 2 (not yet confirmed), a user visits an attacked controlled webpage; the user is prompted with, and accepts, the aforementioned crafted URL prompt; and a payload on a remote, attacker controlled, SMB server is executed. The issue was found in the _DecodeAndRun() function, in which I incorrectly assumed _WinAPI_UrlIs() would only accept web resources. Unfortunately, file:/// passes the default _WinAPI_UrlIs check(). File paths are now directly checked for and must fail. There is no currently known exploitation of this vulnerability in the wild. A patched version, 0.5.0.1, has been released that checks for and denies these crafted URLs. There are no workarounds for this issue. Users are advised not to accept any unexpected prompts from web pages.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 12/25/2021
The MSEdgeRedirect vulnerability represents a critical remote code execution flaw in versions prior to 0.5.0.1 that exploits a fundamental misconfiguration in URL validation mechanisms. This tool, designed to redirect various web services to a user's default browser, contains a dangerous assumption in its codebase that has created a significant security gap. The vulnerability stems from the _DecodeAndRun() function where the developers incorrectly assumed that _WinAPI_UrlIs() would only validate web resources, failing to account for file:// protocol handling that could bypass security checks entirely. This oversight creates a dangerous pathway for attackers to execute malicious code through crafted URLs that appear legitimate to users. The vulnerability requires user interaction and acceptance of prompts, making it a prime example of a user-initiated attack vector that leverages social engineering elements.
The technical implementation of this vulnerability demonstrates a classic case of improper input validation and protocol handling within Windows API integration. When the _WinAPI_UrlIs() function processes file:/// URLs, it fails to properly distinguish between legitimate web resources and potentially malicious file paths that could be exploited for code execution. The flaw exists because the application's code path does not adequately validate that the URL protocol being processed is appropriate for the intended functionality. This represents a CWE-20: Improper Input Validation vulnerability where the system fails to properly validate input parameters before processing them. The vulnerability's design flaw allows attackers to craft URLs that pass the initial validation but then execute malicious code through the file:// protocol, which is typically restricted in web contexts but not properly handled in this application's validation logic.
The operational impact of this vulnerability is significant as it enables attackers to perform remote code execution through user interaction, making it a serious concern for system security. In Scenario 1, the attack chain involves a user visiting a malicious webpage, downloading an executable payload, and then accepting a crafted URL prompt that executes the previously downloaded malware. This demonstrates a sophisticated attack pattern that combines multiple exploitation techniques including web-based payload delivery and user interaction manipulation. The second scenario, while not yet confirmed, suggests even more dangerous implications where remote SMB server payloads could be executed directly through the vulnerability. Both scenarios represent different attack vectors that exploit the same fundamental flaw in URL handling, with the potential for system compromise ranging from local privilege escalation to full system control. The vulnerability's exploitation requires user acceptance of prompts, which makes it a hybrid attack that combines technical exploitation with social engineering elements.
The mitigation for this vulnerability required a fundamental code change in the application's URL validation mechanism. Version 0.5.0.1 addresses the issue by implementing direct file path checking that explicitly rejects crafted URLs, eliminating the bypass opportunity that existed in previous versions. This fix aligns with security best practices for input validation and protocol handling, ensuring that only appropriate URL schemes are processed through the application's redirection logic. The vulnerability's resolution demonstrates the importance of proper API usage and the dangers of making assumptions about how system functions behave under different input conditions. Security researchers have noted that this vulnerability falls into the ATT&CK framework category of T1203: Exploitation for Client Execution, where adversaries leverage application vulnerabilities to execute code on target systems. The lack of workarounds means users must rely entirely on the patched version, emphasizing the critical importance of keeping software updated and the dangers of using outdated applications that may contain undiscovered vulnerabilities. The vulnerability serves as a reminder of how seemingly minor code assumptions can create significant security risks in applications that handle user input and system resources.