Comment by WithinReason
8 hours ago
It was already true that an attacker could trick a user into copying a malicious link inside a file opened in Notepad to their browser, was that also a Remote Code Execution Vulnerability?
8 hours ago
It was already true that an attacker could trick a user into copying a malicious link inside a file opened in Notepad to their browser, was that also a Remote Code Execution Vulnerability?
You can trick the user into copying the same malicious link, but browsers have generally already implemented the same mitigation that is Microsoft's fix for this issue inside Notepad (specifically, prompting before opening outside applications after the user enters or clicks a URL that isn't one of the built-in schemes).
It is also possible to use a different application as the http and file: url handler at the os level;
Write an app to display the (URL) argument passed and require the user to confirm or reject before running the browser using any of one or more default and configurable command line templates.
Add a "Install as default http, https, file:// uri handler" button in the settings gui. Prompt the user to install the app as default handler on first run.
Add opt-in optional debug logging of at least: {source_app_path:, url:, date_opened: } to a JSON lines log file
It looks like the exploit would cause notepad to retrieve and execute arbitrary code when a malicious link is clicked.
The worst part of enshittification is all these search tools erring on the side of too many results than not enough.