Windows file-explorer#preview-pane-previewers DOS
Start
One day. when I was using file-explorer#preview-pane-previewers’s feature.I found it would parse some HTML code. There fore, I discovered a denia of ervice vulnerability, after the vulnerability is triggered,all text editors (including any IDE code editors) will not function properly. Here is my environment and verification steps.
1 | |
Prepare the POC file in advance: create a new HTML file, enter payload in the file:
1 | |
and in the Explorer,enable the preview. Then select the POC file，the preview pane will parse the HTML, at this point, the resource manager will experience a 1-2 second stuck.
Finally, we use Nodepad (or other editors) to open the POC file and input any character at will,for example: aaa, after entering any character, the file content is as follows:
1 | |
The time to trigger the vulnerability is coming! At this point, when we save the file, we will find that the text editor crashes, at this time, no text editor can be used normally, Unless the process ends in Task Manager, the lag will last for 10 minutes. After the editor returns to normal, you will find that the newly written content has not been saved.
By the way, if the initial content is <LINK REL="stylesheet" HREF="javascript:">aaa, theoretically the aaa character will appear in the preview, but the aaa character will not be displayed in the preview, which is not in line with science. After experiments, I found that it seems to be a denial of service caused by improper handling of the HREF attribute of LINK tag,the key trigger character is javascript:.
In addition to all editors (including IDE code editors, etc.) from running properly,after the vulnerability is triggered, renaming the POC file in the folder will also cause the resource manager to stop running, and cannot delete POC files.
Finally
Actually, this issue was first discovered on ‘everything’, and later it was discovered that ‘everything’ was using Windows Explorer.
This issue may will create other vulnerabilities as well.
Timeline
- May 27, 2024: Report the issue to MSRC.
- May 29, 2024: MSRC begins to deal with the issue.
- June 1, 2024: MSRC assesses the risk level as low risk and shares this report with the team responsible for maintaining the product or service.
VIDEO
声明：
本文章用于学习交流，严禁用于非法操作，出现后果一切自行承担，阅读此文章表示你已同意本声明。
Disclaimer:
This article is for study and communication. It is strictly forbidden to use it for illegal operations. All consequences shall be borne by yourself. Reading this article means that you have agreed to this statement.
