One of the bugs we were thinking about for 1.8.1.6 will affect loading data: or javascript: URIs from chrome in content windows, so it will be good to know whether we have extensions that do that, and if so what behavior they expect for them. That could be handled by a grep for "javascript:" and "data:", followed by hand-examination of the (hopefully not many) hits.

I wrote a script that is running right now. It looks at all the files for each add-on, gets the most recent (by date) unzip's the xpi and greps for your keywords. I'll attach the output once it finishes, but I think your dreaming about "not many hits" :) If you have anything else you'd like to grep for, just let me know.

Does it also unzip jars inside the xpi? As for dreaming... <sigh>. If I find extensions that have security bugs as I look through these, can we blacklist them? ;)

(In reply to comment #2) > Does it also unzip jars inside the xpi? > > As for dreaming... <sigh>. If I find extensions that have security bugs as I > look through these, can we blacklist them? ;) > Nope, it just pipes unzip to grep. It's pretty simple, I'll just attach it here.

It'd be good to unzip jars too, since scripts often live in them...

Output is a lot shorter than I thought when I was watching the text scroll by. I have to link to it, because it's too large to attach here: Grepping for javascript: (307kb) http://people.mozilla.org/~clouserw/public/388393/javascript.out Grepping for data: (2.3MB gzipped, 13MB uncompressed) http://people.mozilla.org/~clouserw/public/388393/data.out.gz

Oh, CSS files. And incorrect security checks. Right, then. Maybe we can attack this from a different angle. Can you grep for attempts to set location or location.href? So something like: m/location\w*=/ and m/location\.href\w*=/ (in perl-speak)?

m/location\w*=/ (84k) http://people.mozilla.org/~clouserw/public/388393/location1.out m/location\.href\w*=/ (174k) http://people.mozilla.org/~clouserw/public/388393/location2.out I think looking in the .jar would be possible, but we'll need to install something that can extract them. If you want to go down that road, we can talk to IT to figure out the redhat way.

jars are just zips, same as xpi's.

(In reply to comment #9) > jars are just zips, same as xpi's. > Indeed, and that works. Thanks. I was hoping to pipe something like `unzip -c file.zip \*.jar` (which would only extract jar files) to funzip, and then grep through that. However, it appears funzip is pretty limited, and can only handle one file as input at a time. Doing more with this script is going take longer than I can stay awake tonight. If someone else has great ideas, feel free to take over. :)

I used zgrep in the past for this kind of stuff, but I also never had to open any jars when I was looking in install.rdf's. http://www.delorie.com/gnu/docs/gzip/zgrep.1.html

Mmm... oddly enough, I need to nominate this as blocking 1.8.1.6...

(In reply to comment #12) > Mmm... oddly enough, I need to nominate this as blocking 1.8.1.6... > I see how it is. :) I'll take the bug. Just to be clear, I'm only using the latest version of each add-on (total of 3008 files) in these greps. While I wait for these scripts to finish running, here are some random observations (not entirely relevant to this bug): Across all add-ons, there are currently 2062 .jar files, 30 .exe files (one of which is actually called firefox.exe), and 164 .dll files. When I extracted the "Nuke Anything Enhanced" add-on, the "chrome" directory had 000 permissions. This is the only add-on that had strange permissions - I wonder if firefox changes permissions when it installs an add-on, and if not, could this be an issue? Aside from dictionaries, the "AllPeers Beta" has the largest file included with it, libapFile.so, weighing in at 5.1MB. There are 5 add-ons that have .xpi files inside of the original .xpi files. </random stats>

Alright, I replaced these two files with updates, and they are now the combined grep of the .xpi's and the .jar's they contain. m/location\w*=/ (361k) http://people.mozilla.org/~clouserw/public/388393/location1.out m/location\.href\w*=/ (357k) http://people.mozilla.org/~clouserw/public/388393/location2.out Let me know if you need anything else.

> I see how it is. :) That was mostly a comment on the odd assortment of blocking flags available on this bug. ;) Thanks for getting that data! Looking at it now.

Huh. So for some of these I need to look at the surrounding code, but can't get the code of the extension. See https://addons.mozilla.org/en-US/firefox/addon/1011 for example.

er... oops. I wanted more like m/location\s*=/, not \w*=. Sorry about that confusion... :(

Will: ping? Could you do the modified grep?

(In reply to comment #16) > Huh. So for some of these I need to look at the surrounding code, but can't > get the code of the extension. See > https://addons.mozilla.org/en-US/firefox/addon/1011 for example. > If you don't want to create an account on AMO to view sandboxed add-ons, you can view them by add-on id here: http://releases.mozilla.org/pub/mozilla.org/addons/ > Will: ping? Could you do the modified grep? The following is the output for: egrep -r "location\s*=" * http://people.mozilla.org/~clouserw/public/388393/location3.out

> > Huh. So for some of these I need to look at the surrounding code, but can't > > get the code of the extension. See > > https://addons.mozilla.org/en-US/firefox/addon/1011 for example. > > > > If you don't want to create an account on AMO to view sandboxed add-ons, you > can view them by add-on id here: > http://releases.mozilla.org/pub/mozilla.org/addons/ I forgot we don't put sandboxed add-ons on releases.m.o now (the /1011/ directory on there is an older version I think). Anyway, I logged in to AMO, and I don't see files for that add-on either. Digging a little deeper, it looks like the add-on is in the sandbox, but all it's files are public (effectively blocking anyone from downloading any of them). I think this is a bug with AMO, and a result of our pulling add-ons that don't meet our standards back into the sandbox after they were initially public. I'll file a separate bug for that.

> The following is the output for: egrep -r "location\s*=" * Great! And same for "location.href\s*=" ?

(In reply to comment #21) > > The following is the output for: egrep -r "location\s*=" * > > Great! And same for "location.href\s*=" ? > http://people.mozilla.org/~clouserw/public/388393/location4.out Bug 389174 is the bug I mentioned before.

Thanks! That gives me what I need for bug 388121. And I must say that after skimming the hits I'm really glad I don't use any extensions. :(