New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Macdown Version 0.7.1 (870) Remote Code Execution #1050
Comments
|
I'm not sure whether we can do anything about it other than prompting user not to open any random |
|
The app could refuse to open/launch executables. |
|
I personally don't use embedded HTML in my Markdown docs, partly because I don't know what the engine which renders the Markdown is going to know what to do with it (Macdown is one of several programs which "consume" my Markdown docs) and partly because it goes against the whole idea of separating content from presentation. If anything, I'd like to see a way to disable inline HTML rendering entirely. However, I can see where others might find it useful, so... The app could show some kind of placeholder where the HTML block would appear. When this placeholder is clicked, a pop-up menu would offer the user the following choices:
It makes sense for user's choice for each HTML item to be "remembered" when the rendering pane is reloaded. However, for security, these choices should be "forgotten" when the file is closed or the app quits, i.e. the per-item preferences should not be persisted anywhere other than in memory. Also, there should not be a way to store those per-item preferences in tags or other metadata within the file itself, since the "bad guy" would just add those tags/metadata to their malicious files and override the user's preferences. Other related app-wide preference settings would be:
You should also consider what to do with each block when the document is printed or exported. My suggestion is, If the item is being rendered or shown as text, then the exported content should do the same. If the item is being shown as a placeholder or not shown at all, then the exported content should not include anything for the item. |
|
Hi @FranklinYu, please note that CVE-2019-12138 was assigned to the issue. |
@pmetzger I’m not even sure whether it’s possible. There is no code in MacDown that really launches the application, of course. I think it’s simply handled by Finder. Update: WebView seems to allow delegate. I’m wondering whether I should use that, or I should first upgrade to |
|
The placeholder suggestion from @kg4zow sounds nice, but there are two difficulties:
|
This really does help on both WKWebView and WebView (which, I believe is actually now just WKWebView through a translation layer?). It always essentially comes down to the In general though, this is super unexploitable due to the mountains of other macOS mitigations. The main one here is quarantine since nearly every normal way of getting content off the internet will slap a quarantine attr and so |
Macdown Version 0.7.1 (870) Remote Code Execution
Macdown version 0.7.1 (870) is affected by a remote code execution vulnerability. Macdown fails to sanitize input on HTML attributes. Abusing the
file:\\URI scheme on HTML attributes can result in arbitrary code execution. The attached proof of concept will execute the MacOS Calculator.app when opened inside of Macdown.PoC (PoC.md):
Screenshot:
PoC.md.zip
The text was updated successfully, but these errors were encountered: