Google Chrome: A demonstration of how inadequate process can defeat any technical expertise

This was originally published on the CIO website and is reprinted with their permission.

While too much process in software development, as was satirized in the movie Office Space with its infamous TPS reports, can cause a product to grind to a halt, insufficient process can be as bad, if not worse. While it might be hard to imagine how less process can be worse, Google was kind enough to provide a wonderful example when they released a beta version of their own branded browser, Google Chrome. Within two hours of being released a critical vulnerability that allows arbitrary code execution was discovered and publicized along with a proof of concept demonstrating the vulnerablity. It is expected that any major piece of software, especially a beta version, will have some vulnerabilities. But in this case, this vulnerability was code not written by Google and Apple, the original writer of the code, had widely publicized the vulnerability and a patch before Google released Chrome. Independent of the compentency of Google's engineering, inadequacies in their security processes for Chrome led to this faux pax, the ongoing shenanigans and likely a reduced rate of adoption for what is obviously a major software effort for Google.

The problem arose because some parts of Chrome are using code from on Apple's Safari browser. Google began with a current version of the browser but never updated to a newer version and, more importantly, did not track security advisories for Safari. This was certainly embarrassing but far from a complete failure of process. On September 5th, three days after the release of Chrome, Google released a patch for the browser. Even after the patch, questions remained about whether the patch was sufficient or not to prevent all possible exploits of the vulnerability. On October 21st, without making any statement about the vulnerability, Google released a revised patch for the same vulnerability. Ignoring the fact that there is serious doubt as to whether or not they have completely fixed the vulnerability, Google is only distributing the updated patch to people who are downloading the developer browser versions rather than the user browser versions (besides potentially having extra code for developers, the developer browser versions tend to be less stable than the user version).

While Chrome only seems to have about 1% of the browser market, the actual number of users affected by this is large. The browser market is estimated to be 1.5 billion users worldwide. That means that about 1.5 million users are at risk of having a successful exploit of this attack occur while using Chrome. A successful exploit allows arbitrary code execution and likely turns the users computer into zombie that is part of a botnet.

It is this author's opinion that there is absolutely no excuse for the negligence Google has demonstrated in the handling of their Chrome browser. The brief summary is, Google released a software product that had at least one highly publicized and severe bug, produced an quick but inadequate patch, and took about seven weeks to produce an upadated but developer-only patch. Google's "developer-only" patch strategy suggests that even they are uncomfortable to release the fix to the general public.

Possible explanations for this problem include extreme deadline pressure from upper-management, a project that was taken lightly by management and incorrectly or inadequately staffed, a security knowledge base that was insufficiently allocated insufficiently to the project, or a score of other reasons. The one thing that is clear is that Google spent lots of effort on Chrome and, at best, have dramatically reduced its adoption rate due to a series of missteps that could easily have been avoided prior to releasing the browser had they only had a process in place to track Safari vulnerabilities.