Paid Advertising
web application security lab

Google Desktop - The Saga Continues

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 “″). 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 ( 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)?

21 Responses to “Google Desktop - The Saga Continues”

  1. Spider Says:

    Your right the injection seems to be happening on the browser level, not the network.

    The link shows up in IE, firefox, and opera when the desktop is running, but not in more obscure browsers like amaya or through wget.

    Does anyone have more information about what exactly browser shims are? And how the heck do you disable them?

  2. Google Desktop - Still too Scary to Use Says:

    […] Since I didn’t have Google Desktop installed, I figured I’d give it a shot. It all seemed a little too Orwellian for me. Then after reading Rsnakes last two posts about a single xss hole in Google allowing an intrusion vector into your PC, it felt time to turn the thing off. 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 it’s 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.   […]

  3. Hong Says:

    Sometimes, it can interchange with e.g. and, and, etc. So, I think if you have an XSS hole on, you can read their gmail if it can replace the subdomain by “mail”.

  4. nEUrOO Says:

    Few days ago there was also another XSS in google, I posted it in the Full Disclosure:,44,page=40#msg-7126

  5. RSnake Says:

    @Hong - even better… that widens the places to look for more XSS as well. Extremely insecure design. Clearly I don’t go to Google enough, I should have known that.

    @nEUrOO - of course you did. There’s been hundreds, those are just the few I wrote about. I was sorta being facetious. They are terribly insecure.

  6. Danny Says:

    Actually, Google Desktop does not uses one-time tokens. Every user has a specific key (found in the registry at HKCU\Software\Google\Google Desktop\fuse_data) that is used to generate a signature for each URL request. As the search form uses GET, every query would have a different signature. However, the home page and the search form have specific signatures that do not change and can be found in the registry at HKCU\Software\Google\Custom Search\Google Desktop Search named Site and Url respectively. These are the links that are injected via the browser shim into the Google site. If I can capture that signature once, it’s all I need …

    Signatures are a good protection mechanism against XSS and XSRF, but the link from the public web server to the local web server creates the window of opportunity.

  7. RSnake Says:

    @Danny - yes, that’s what I meant (may have phrased it wrong). But for all intents and purposes it is unique per page making it one time. If you can fix another way to pull reg keys from the system that would be a whole different sort of vulnerability. :)

  8. .mario Says:

    Did any of you guys also get the Watchfire ‘warnig email’ - if yes I don’t have to say anything more :)

  9. RSnake Says:

    No, I didn’t see that. Was it a typo or was there something else?

  10. fré Says:

    I don’t remember i ever have installed google desktop, and says it’s not running.

    But what bothers me is this.

    Snippet form Firefox plugin ‘Live HTTP Headers’

    GET /search?client=navclient-auto&ch=6731864913&features=Rank& HTTP/1.1
    User-Agent: Mozilla/4.0 (compatible; GoogleToolbar 2.0.114-big; Windows XP 5.1)
    Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    Accept-Language: nl,en-us;q=0.7,en;q=0.3
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 300
    Connection: keep-alive
    Cookie: PREF=ID=84212c20d5fa10ee:TM=1170597104:LM=1170597104:S=9SeApMq2DJkzxetX

    HTTP/1.x 200 OK
    Cache-Control: private
    Content-Type: text/html
    Server: GWS/2.1
    Transfer-Encoding: chunked
    Date: Fri, 23 Feb 2007 08:18:14 GMT

    I requested , and with all the normal headers coming along, there always seems to be al request to / ? And i dunno why!!??

  11. LinkLifter » Google Desktop etwas löchrig? Says:

    […] Für alle Fans vom Google Desktop hat RSnake da ein paar ganz schöne Dinge zusammengeschrieben. Irgendwie beängstigend. […]

  12. RSnake Says:

    @fré - what you have uncovered is Google’s spyware. I believe that is if you have the search toolbar plugin installed. You can also see similar requests if you have their web accelerator installed. Those are unrelated to this attack, but they definitely are stealing your information. Yay for spyware!

  13. Matan Says:

    This is basically a rehash of an attack againt Google Desktop that I demonstrated more than a year ago:

    The Watchfire paper describes and uses the technique I showed in my proof of concept to gain access to the local GDS web server.

    The only thing that changed is the vector for bypassing the same origin policy. They also added a sticky XSS vulnerability which is a nice touch.


  14. RSnake Says:

    When you say “this” I assume you are referring to the Watchfire issue and not the anti-anti-anti DNS Pinning issue I’m talking about (which requires no XSS on the desktop itself at all to work).

  15. RSnake Says:

    This has hit the Wall Street Journal (sorry, need a login for access - you can try bugmenot):

  16. n00bie Says:

    being new to this stuff, here’s the question…
    If I don’t use google desktop, should I be scared of the issues raised here?


  17. RSnake Says:

    If you don’t use Google desktop you would not be vulnerable to the google desktop issue. You may be vulnerable to other issues - I can’t comment there, but not of this particular issue no.

  18. Wladimir Palant Says:

    RSnake, not sure you have seen this blog entry:
    Note the date. I guess “Show Desktop Search results on Google Web Search result pages” option is no more?

  19. Cross-site scripting bugs « Andrew Whitehouse’s Weblog Says:

    […] has been widely written about; the idea is that if a web site will display unescaped user-submitted data then this […]

  20. The Current Truth Says:

    […] over at ha.ckers shows early signs that additional Google Desktop attacks are in the […]

  21. RSnake Says:

    A good writeup on how to disable the link between Google’s website and Google Desktop. While I’m not 100% certain this is all it takes to shut off this vector, it definitely would require re-thinking the flow, considerably: