It suddenly hit me this morning. Google’s entire security model is based on not finding a single XSS hole in Google’s domain. The amazingly poorly thought out link between Google desktop and Google’s website creates one of the worst security holes I’ve seen. After reading Watchfire’s paper on “Overtaking Google Desktop” yesterday I too took a look at Google Desktop. For those of you who aren’t aware of how it works, it basically looks for certain strings in the Google domain and replaces them with a link to itself. It does this using a browser shim (not a network shim). This simple design decision is one of the few things that’s saving them from having a second vulnerability right now.
The link itself is to Google Desktop and it includes a nonce (a one time token). That one time token is the second reason that Google Desktop is briefly saved from exploitation. This one actually is a good design decision (not the integration with the website, but forcing the nonce to be there and validating it on each request). The nonce changes with each request, so knowing it once doesn’t mean knowing it for other requests. However, here is where things start falling apart pretty quickly.
Google Desktop is pretty much completely susceptible to a mixture of Anti-DNS pinning and header forging (also known as anti-anti-anti DNS Pinning) (and even that is only to make sure the Host: header reads “127.0.0.1:4664″). Okay, but what about the nonce? Doesn’t that make Google’s Desktop super uber secure? Hardly. Now all we need to do is find one XSS hole in allllll of Google where Google’s Desktop reads the header and overwrites it with its nonce. The XSS hole reads the nonce, pops an iframe with the data needed for the anti-DNS pinning, spoofs the header and voila, read/write access to Google Desktop.
You are may now be asking, “But if you have an XSS hole on Google there is a lot of other things you can do.” Maybe, but remember, Gmail is on another cname (mail.google.com). So if you can’t read their gmail, why not just read the files from their cache instead (which Google happily keeps for you)? Normally cache would be unavailable to your browser, but luckily for the attacker Google’s Desktop makes that matter rather trivial. “But that seems like a lot of work. I mean, why tip your hand if you aren’t even sure if they have Google Desktop installed?” Oh, I don’t know, why don’t we just detect if they have it installed just to save us some hassle? So I wrote a little detection mechanism to pull an image from Google Desktop (I guess the Google engineers got lazy and decided not to add nonces to their images). If it’s there, they have it installed and turned on, if not, don’t bother running your exploit.
Again, the heavy integration between web based and client based software is not a good thing. There are far too many unknowns and far too many holes out there right now. Just ask yourself this. If the security of every file on your computer rested in the hands of Google’s engineers never inadvertently creating a single input validation hole would that make you very comfortable knowing their history (1, 2, 3, 4, 5)?