Headline

CVE-2021-43844: Build software better, together

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.

2 years ago

CVE

Open in Source

#vulnerability #web #ios #windows #git

Package

MSEdgeRedirect (AutoIt)

Affected versions

< 0.5.0.1

Impact

MSEdgeRedirect versions before 0.5.01 are vulnerable to Remote Code Execution via specifically crafted URLs. This vulnerability requires user interaction and the acceptance of a prompt similar to the one below:

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:

Scenario 1 (CVSS 7.5) - 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
RCE executes the payload the user previously downloaded, if the download path is successfully guessed

Scenario 2 (CVSS 8.8) - Not Yet Confirmed:

A user visits an attacked controlled webpage
The user is prompted with, and accepts, the aforementioned crafted URL prompt
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. Future lockdown to URLs are planned in upcoming versions:

Additional checks for indicators of non-HTTP/HTTPs URLs will be added to the _IsSafeURL() function
Any URLs will be passed directly to the default browser instead of allowing Windows to resolve the URL using _GetDefaultBrowser()

There is no currently known exploitation of this vulnerability in the wild.

Patches

A patched version, 0.5.0.1 has been released that checks for and denies these crafted URLs.

Workarounds

There are no workarounds for this issue. Users are advised not to accept any unexpected prompts from web pages.

References

CWE-610
CVE-2021-43844
https://positive.security/blog/url-open-rce

For more information

If you have any questions or comments about this advisory: