grep against add-ons for usage of javascript: or data: URIs

RESOLVED FIXED

Status

RESOLVED FIXED
11 years ago
3 years ago

People

(Reporter: beltzner, Assigned: clouserw)

Tracking

Details

Attachments

(1 attachment)

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.
(Assignee)

Comment 1

11 years ago
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?  ;)
(Assignee)

Comment 3

11 years ago
(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.
(Assignee)

Comment 4

11 years ago
Created attachment 272601 [details]
Grep the remora add-on tree for a word
It'd be good to unzip jars too, since scripts often live in them...
(Assignee)

Comment 6

11 years ago
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)?
(Assignee)

Comment 8

11 years ago
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.
(Assignee)

Comment 10

11 years ago
(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...
(Assignee)

Comment 13

11 years ago
(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>
Assignee: nobody → clouserw
(Assignee)

Comment 14

11 years ago
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?
(Assignee)

Comment 19

11 years ago
(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
(Assignee)

Comment 20

11 years ago
> > 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*=" ?
(Assignee)

Comment 22

11 years ago
(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.  :(
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Component: Add-ons → Administration
QA Contact: add-ons → administration
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.