A "software mule" is a computer program which embedded, and therefore is dependent on, code of many other programs and libraries.

Q: Ok, I understand the definition. But, why being a "software mule" is a security issue?

By definition, a software mule embeds the code of its "parents" programs and libraries, and therefore it inherits their genetic problems, also known as - software vulnerabilities.

If a security vulnerability was found in a program or a library that is part of the software mule, it makes the software mule in high probability of being vulnerable to this security too. The vendor of the software mule will need to deliver a patch for each and every fix that was the made for the embedded code. This will take time, and will put the software mule users at risk, because the vulnerability in the embedded program/library will be already publicly known.

Q: So, Because Google Chrome is a software mule it is vulnerable to "Carpet Bombing"?

Most likely. As I wrote in my previous post, Google Chrome is using a mix of code of other browsers and libraries (also documented by Google themselves). "Carpet Bombing" (aka automatic file download) is a vulnerability that was found in Apple Safari and was already fixed.

This vulnerability is partially fixed. They have added a check to make sure that the default download folder is not the user's desktop. This is a good security measure, but definitely not a full patch for this issue. The vulnerability can still be exploited for a remote code execution. The proof-of-concept I provided in my previous post still works.

Q: Is there a workaround which can be used to mitigate this vulnerability, at-least until Google fixes it?

Yes, there is. Click on the "wrench" icon and then "Options". Under the "Minor Tweaks" tab make sure that the "Ask where to save each file before downloading" checkbox is checked. This checkbox is unchecked by default, and therefore the automatic download of malicious files is possible.

Q: Well, this is a simple workaround, and I've applied it in my browser. Does it mean that it is now safe to use Google Chrome?

No. As I've mentioned before, Google Chrome is a software mule. This means that it probably inherits all the security vulnerabilities of the program's code it embeds. For example, it uses an old version of WebKit, so it is probably vulnerable to all the security vulnerabilities that were already fixed in the latest version of WebKit. Maybe even the latest vulnerability that was fixed in the latest WebKit version of the Safari for iPhone...

In real life, when you take two species, a horse and a donkey, and mix them up you get a mule. In the browsers world, when you take a horse (Firefox/IE) and a donkey (Safari) and mix them up, you get – Google Chrome.The new browser from Google tries to get the best from other browsers, but instead (well, at least in the current beta version), it seems to be doing quite the opposite.

The current beta uses an old version of WebKit - 525.13 - which is actually the same WebKit engine used by the old Safari v3.1. The current Safari version is v3.1.2, which fixed several critical issues, including the “blended threat” Carpet Bombing vulnerability. Google even mention that they use Safari v3.1 rendering engine in their own documentation (Thanks Yonatan Grabber for the information!)

On the other hand, Chrome borrowed (and modified) local resource files from the Mozilla project. And also, for some reason, in some cases there is an ActiveX plug-in loaded by Chrome, which might be an evidence of a capability of this browser to execute ActiveX controls.

I really wonder why Google have taken several features from other browsers and mixed them all together. Security wise, it’s very problematic. They’ll have to track all security vulnerabilities in those features, and fix them in Chrome too. This will probably be only after those vulnerabilities were fixed by the other vendors or were publicly reported. It will put Chrome users at risk for a long time.

Back to the WebKit issue. I’ve created a proof-of-concept which demonstrates the automatic download vulnerability that was already fixed by Apple. This PoC will automatically download a JAR file and place it in the the downloads folder (there are reports that in some cases it will download it to the Desktop, as in Safari. In those cases, the Safari-Pwns-IE exploit can be easily converted to Chrome-Pwns-IE exploit).

Unfortunately, whenever Google Chrome downloads a file, it creates a download bar at the bottom of the page, which seems, for the untrained eye, as part of the page. The downloaded filename is displayed as a button, and the one click on this button will execute the file. If the file is an executable (e.g. .EXE, .BAT, etc.), Windows Explorer will show a warning that this file was downloaded from the Internet. In this case, Google Chrome does a good job by setting the Zone.Identifier in the alternative data stream.

However, as was mentioned by pdp at his great Black Hat talk this August, when Windows Explorer will try to execute a JAR file, it will automatically run the associated application, which in most cases is the JRE (Java Runtime Environment). JRE will not check the Zone.Identifier in the alternative data stream, and will execute the JAR file with no warning. JAR file, of-course, should be treated as any other executable file. This is again a sort of a "blended threat". Two small issues in different products, when blended together create a much larger problem.

In conclusion, Chrome seems to be a very nice and slick browser, but it is far from being secured as it is advertised by Google. It borrows several insecure features from other browsers, and it has its own security design flaws.