Google Native Client, Google Chrome OS & Coming Out of Beta
By Craig Balding
Google Chrome Operating System
Perhaps the biggest news is their plan to create a new operating system, based on the Linux kernel, running on X86 and ARM chipsets and targeted at the Netbook/Laptop/Desktop user:
“Google Chrome OS is an open source, lightweight operating system that will initially be targeted at netbooks. Later this year we will open-source its code, and netbooks running Google Chrome OS will be available for consumers in the second half of 2010.”
Talking of their goals:
“Speed, simplicity and security are the key aspects of Google Chrome OS. We’re designing the OS to be fast and lightweight, to start up and get you onto the web in a few seconds. The user interface is minimal to stay out of your way, and most of the user experience takes place on th web.”
And starting from a clean slate (and an obligatory swipe at Microsoft):
“And as we did for the Google Chrome browser, we are going back to the basics and completely redesigning the underlying security architecture of the OS so that users don’t have to deal with viruses, malware and security updates. It should just work.
<snip>
The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel. For application developers, the web is the platform. All web-based applications will automatically work and new applications can be written using your favorite web technologies. And of course, these apps will run not only on Google Chrome OS, but on any standards-based browser on Windows, Mac and Linux thereby giving developers the largest user base of any platform.
Google Chrome OS is a new project, separate from Android. Android was designed from the beginning to work across a variety of devices from phones to set-top boxes to netbooks. Google Chrome OS is being created for people who spend most of their time on the web, and is being designed to power computers ranging from small netbooks to full-size desktop systems. While there are areas where Google Chrome OS and Android overlap, we believe choice will drive innovation for the benefit of everyone, including Google.”
Wow, pretty big announcement with lots of potential market implications. One way to look at this is they just described a system with “embedded OS” properties running as a mainstream desktop OS with services delivered via the web instead of relying on locally hosted applications. I suppose in some ways this should come as no real surprise as it is entirely in-line with their cloud based strategy.
Whilst the target market would appear to be consumers, I can see enterprises jumping at a thin OS “that just works”. Ultimately, this is moving us closer to an age of disposable computing - low cost devices with low entry software footprints.
Organisations are keen to embrace smaller footprint client computers to cut costs and if the underlying hardware offers enterprise demanded features like full HD encryption (to protect that cached Cloud content), I could see enterprises taking a serious interest.
Do we *really* want to run the dozen endpoint agents we have today for configuration management, NAC, AV, HIPS (pah!) and bear all the costs they bring? With a static client, you won’t need many of these features. From a security point of view, this could be a very good thing - no AV headaches, significantly less attack surface (enterprise apps often demonstrate “brittle” security) and less PII to lose.
To deliver on a low-update OS, they will need to ship a subset of the Linux kernel that is considered “mature”, otherwise their users will be back on the “patch treadmill” - which is something they explicitly state they are trying to avoid.
I find it interesting they are designing a new windowing system when there are so many options available today (some with decent security too). I suspect this is to take advantage of advances in graphical chipsets. Perhaps they see this as a chance to boost Chrome browser page rendering speed even further.
Perhaps the more fundamental question is whether we want Google owning the last bastion - our desktops.
This brings us to the Chrome browser itself and associated technologies.
Google Native Client
Back in February, Google kicked off a security contest for a “research project” called Google Native Client (NaCl). First a quick recap on Native Client:
“Native Client is an open-source research technology for running x86 native code in web applications, with the goal of maintaining the browser neutrality, OS portability, and safety that people expect from web apps. We’ve released this project at an early, research stage to get feedback from the security and broader open-source communities. We believe that Native Client technology will someday help web developers to create richer and more dynamic browser-based applications. ”
This is Google’s ambitious attempt to provide a high-speed, browser hosted application alternative to Java or Flash. To do this securely, they designed a new security architecture and NaCl is the implementation.
Announcing the security contest, Henry Bridge from Google wrote:
“Exploits, bugs, vulnerabilities, security holes — for most programmers these terms are synonymous with fire drills and coding all-nighters. However, for the next 10 weeks, the Native Client team is inviting you to bring them on! We’re challenging you to find security exploits in Native Client.”
The judges, led by respected academic Ed Felton (Princeton), assessed the vulnerablities reported by each of the 600 participants based on “a) Quality (Severity, Scope, Reliability and Style) and b) Quantity”. Participants were limited to reporting on 10 bugs (Google claimed this was to avoid wasting the judges time).
Mark Dowd and Ben Hawkes won the contest, finding the bulk of the best bugs. Mark Dowd is well known in the security community - most often described as a humble genius (or a robot sent back in time :). I followed along at home and it was great fun reading the bug descriptions as the competition progressed. As this was a new security design, there were some unique vulnerabilities discovered along with novel exploit avenues. Despite all the implementation snafus, Google is taking comfort that no underlying architectural weaknesses were found.
“This contest helped us discover implementation errors in Native Client and some areas of our codebase we need to spend more time reviewing. More importantly, that no major architectural flaws were found provides evidence that Native Client can be made safe enough for widespread use. Toward that end, we’re implementing additional security measures, such as an outer sandbox…”
In other posts, Google has indicated the plan to bundle NaCl with the browser, rather than offer as a end-user download. There is some way to go before this happens, and the security contest is just one step on the journey before NaCl goes live. The NaCl team also submitted a detailed technical design paper to the IEEE 2009 Symposium on Security and Privacy. If anyone knows anything on the outcome of the peer review, please leave a comment.
Overall, it has to be said that the NaCl team at Google is doing a solid job trying to flush out security issues before “Primetime”.
Having said that, not all observers agree the architecture is a step in the right direction. Noted reverse engineer Halvar Flake responded to a post by Dave Aitel on the Daily Dave mailing list remarking that:
“The real beauty in NaCl is that it is certain to defeat DEP [Ed: Data Execution Prevention is an hardware and/or software enabled chipset technology design to throw an exception when an attempt is made to pass off data pages as code pages]. Not that DEP is much of an obstacle in browsers these days, but still. It’ll also almost certainly allow ASLR bypass.
Everyone who has even been to one of my classes has been tortured with the analogy that “writing an exploit is like trying to build a chair out of a number of random parts from the IKEA warehouse: Nothing ever fits, but the more pieces you have, the better your odds of success are.
The power to first execute Javascript to perform [Ed: memory] allocations/dealloctions, coupled with the ability to load arbitrary code into the address space that is only verified under alignment assumptions violated as soon as you can perform a control hijack, does look like a jar of superglue to me. And when you have a sufficiently large jar of superglue, you can essentially build a chair out of wood shavings.”
The point that Halvar is making is that the exploit coder has certain advantages when it comes to exploiting browser based weaknesses. Couple this with the very feature that NaCl introduces - loading Internet hosted native code - and any single implementation weakness makes way for reliable exploitation potential bypassing CPU anti-exploitation features. This kind of dialogue is very constructive and I look forward to seeing how the thinking around NaCl develops.
Google Apps: Beta Out, Enterprise Features In
Back to the Google announcements, and the day finally came Google dropped ‘Beta’ from Google Apps, Gmail, Google Calendar, Google Docs and Google Talk. This is clearly to please enterprise folks who take the traditional interpretation of “beta == buggy”. Its hard for a CIO to get buy-in with their own org to adopt a hosted service that has those 4 letters staring back at them (even if they agree with Google’s definition of “beta”. “Premium beta” anyone? ;-).
Google also added email delegation, retention, DR features to Google Apps, along with “special handling of business users’ data in our data center operations.” If anyone has any details on that last point, do share. Google is in catch-up mode and ticking the right boxes.
All in all, this was a big day for Google and their evolving Cloud strategy, enterprise security people should take note…