Issue metadata
Sign in to add a comment
|
Security: Chrome allow on-the-fly binary files creation via document.createElement
Reported by
skydive...@gmail.com,
Jul 14 2017
|
||||||||||||||||||||
Issue descriptionThis template is ONLY for reporting security bugs. If you are reporting a Download Protection Bypass bug, please use the "Security - Download Protection" template. For all other reports, please use a different template. Please READ THIS FAQ before filing a bug: https://www.chromium.org/Home /chromium-security/security-faq Please see the following link for instructions on filing security bugs: http://www.chromium.org/Home/chromium-security/reporting-security-bugs NOTE: Security bugs are normally made public once a fix has been widely deployed. VULNERABILITY DETAILS It is possible to create a binary files with "document.createElement". To achieve this you only need to base64 encode a binary in the URI field of "element.setAttribute". As you will see in the provided PoC exploit, the file download will automatically prompt on loading the HTML. As you can create a text file with .bat extension, exploitation is straight forward. .bat file can directly run system commands, anyway, to have a more clear exploitation scenario the PoC exploit will create this sample malware (https://testsafebrowsing.appspot.com/s/content.exe) and then will try to execute it (of course it is a sample so doesn't work). The impact of this behavior is that every perimeter firewall, gateway antivirus and gateway sandboxes can be bypassed as the malware can be create locally on the target from Chrome without having to download it from the Internet. On Firefox 54.0.1 (32 bit) the download prompt offers the default app to open the file (Notepad) and makes this exploit useless. On Microsoft Edge 40.15063.0.0 there's even no download prompt. VERSION Chrome Version: 59.0.3071.115 (Build oficial) (64 bits) Operating System: Windows 10 Pro Version 1703 OS Build 15063.483 x64 based processor REPRODUCTION CASE See attached PoC exploit. To exploit this I used "certutil" tool of Windows and embedded the malware with a fake certificate format in the created file then extracted it using the same tool. There are other ways to achieve that but this one looked creative to me. FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION Type of crash: [tab, browser, etc.] Crash State: [see link above: stack trace, registers, exception record] Client ID (if relevant): [see link above]
,
Jul 14 2017
Incidentally, if you don't want firefox to rename your file to funnygame.bat.txt, simply change "data:text/plain" to "data:application/octet-stream".
,
Jul 15 2017
Yes, of course Download Protection is there, but it still looks to me a dangerous feature (of HTML5). This gives too much "power" to the client side and allows to trivially bypass any security perimeter solution. How perimeter solutions can fight that if browsers allow dynamic file creation...?? There's no way to stop that as the malware payload can be obtained (in very small pieces) from many side channels and then it can be reassembled in the locally created file... It is scaring. It opens a wide attack surface. I don't think that a feature is more or less secure just because it has been there for years... So, I understand from your response that there's no problem if I made this malware creation vector public and openly write about that. Isn't it?
,
Jul 15 2017
Sure, feel free to talk about this; it's not in any way secret, and is a feature commonly used by popular sites. For instance, see https://en.wikipedia.org/wiki/Mega_(service)#Data_encryption as one service that dynamically generates downloads from JavaScript-built blob URLs.
,
Jul 16 2017
Yes, it is clear that the feature it is not secret :). I mean the way this feature is exploited in my example for creating malware locally (thus bypassing all the perimeter based security solutions) is scaring. There have been a lot of "features" of javascript, HTML, and the HTTP protocol itself that have been there for years and massively used that at some point have been "hardened" in some way, some times improving RFC's, some times having browser vendors changing the way they implement RFC's, etc. You probably remember many years ago it was possible to do many things from Javascript that are nowadays not allowed (cross domain requests, access to HTTP headers, etc) just because those "features" where exploited many times with bad intentions by attackers to compromise systems. I could post many examples of such kind of "features" I used to exploit at that time that do not work nowadays. And this is good as many of those "features" where a bit bizarre in terms of security. This is how usually specs of technology get improved. It is not a matter of discussing if this is a widely used feature, it is a matter of thinking if this is a safe feature. Do you honestly think it is safe...? I don't think so... ;) Anyway I can understand that you, as browser vendor, can think that "this is not your problem". But this doesn't solves the root problem and my question: is it a safe feature? I absolutely think it is not. The same I used to think XMLHTTP was not safe may years ago and finally changes were made to have it a more secure implementation. Think that we are not talking about Java or Flash, we are talking about Javascript, something that every decent browser will support. Without Javascript the modern Internet is broken so I think it should be as much safe as we can. If browsers don't care about the whole picture (there's security life beyond OS and web browsers...) and forget about perimeter solution vendors then we have a problem... The Internet security is a responsibility and a team work of all of the actors. If we HTML5 allows arbitrary local file creation and browser vendors don't care about that then we can think about the next step of insecurity: directly allowing command execution from browsers... will you still think this is secure also? I know you give an alert from a locally generated file the same as if it was remotely downloaded, but this is not enough, and I'm pretty sure you agree with me. Will you allow local system commands execution protected only with a similar alert? No, for sure. So why don't we make some team effort and try to change this behavior? You as leading browser vendor have power to do this. I just can publish a paper with a cook-book of more elaborated exploitation examples that will be used in the wild to spread more malware but the Internet reaction will be very slow (the same happened with XMLHTTP and tons of exploits being published until vendors reacted...). Maybe we can go a step ahead and try to change this now. You can help on this. Let me know your impressions about that topic and sorry for the long post.
,
Oct 30
Issue 899742 has been merged into this issue.
,
Nov 5
This (one year old paper) may help you understand the problem: http://www.pentest.es/luturbia/chrome_welcomes_malware.pdf |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Jul 14 2017Status: WontFix (was: Unconfirmed)
3.5 KB
3.5 KB View Download