Malicious download && code injection attack in <audio> element
Reported by
tiebuc...@gmail.com,
Aug 17
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce the problem: Exploit 1: When user click download button from the audio player,the browser will send a new request to the webserver. But when click play button,it read the audio from the cache. As a result, the file you download maybe not the file you are playing~ Exploit this feature can cause the malicious download attack based on the time gap. Put a normal audio format file with the .exe extension in the server. When the user visit the webpage,he can play the audio successfully. After loading,the attacker can replace the .exe audio with a malware of the same file name. When the user click download,he download the malware~ Exploit 2: 1.Put the poc.html && eval.html in the webserver. 2.open the poc.html in the Chrome. 3.click 'open audio in new tab',some unexpected situations will happen~ Exploit this feature can cause a xss attack. We can put some special content at the end of the audio file with a binary editor. What is the expected behavior? Only the legal audio file can be played. What went wrong? The browser doesn't detect the legality of a audio file, including the file format and the file extension. Did this work before? N/A Chrome version: 68.0.3440.106 Channel: stable OS Version: 10.0 Flash Version:
,
Aug 17
<media> should be <audio> in my previous comment.
,
Aug 17
Yep, confirm that if "open audio in new tab" triggers a download, download protection logic will kick-in.
,
Aug 18
,
Aug 20
I'm not very familiar with the web-facing stuff. Mounir, Dale: do you know what to do with this bug?
,
Aug 20
Eh, we get all sorts of URLs with crazy or no extensions since the data can be served from some generating page. I don't think there's anything we can do about this. Once someone clicks open in new tab it'll check the extension and fall back to download (which appears protected) if it's unrecognized. So I think this is WontFix.
,
Aug 22
I'm not entirely sure how the download part is related to this issue. Would it be similar if the file was being downloaded via other means than the <audio> or <video> UI?
,
Aug 22
I agree with #6, it should be a won'tfix. Re #7, yep, it's similar to other forms of downloads.
,
Aug 23
When I click the 'open audio in new tab', a picture or something else will be presented in a web page. It is not WYSIWYG. I know that other browsers have the same issue. Maybe that’s just some tricks.
,
Nov 29
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by carlosil@chromium.org
, Aug 17Components: UI>Browser>Downloads Blink>Media>Audio
Labels: Security_Impact-Stable Security_Severity-Low OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Mac
Owner: maxmorin@chromium.org