289171 - Chrome JS code injection possible using pluginspage attribute

Status: RESOLVED FIXED

(Toolkit Graveyard :: Plugin Finder Service, defect)

Description

[Doron Rosenberg (IBM)]

Similar to bug 288556 (not fixed by the patch though) :

Code injection into an xul:button's oncommand for manual urls is possible
because a oncommand attribute is set.

Solution: use event listeners.

Comment 1

[Doron Rosenberg (IBM)]

Attachment: testcase

Comment 2

[Doron Rosenberg (IBM)]

Attachment: patch

Comment 3

[Doron Rosenberg (IBM)]

Steps to reproduce:

- Load testcase
- Click on the missing plugin piece
- It should say no suitable plugins found, and give a manual install button.
- Clicking the manual install button will open a new window and an dialog saying
"Code Injection!".

When fixed, the dialog should now show (new window is fine).

Comment 4

[Doron Rosenberg (IBM)]

Correction to above:
  When fixed, the dialog should _NOT_ show (new window is fine).

Comment 5

[Jay Patel [:jay]]

Doron:  I can't reproduce this with your testcase using Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050403 Firefox/1.0.3 .  Do I need any
special prefs set to see this problem?

Comment 6

[Doron Rosenberg (IBM)]

Attachment: new testcase

The patch to 288556 made this a bit harder to exploit after all, new testcase
attached.

Comment 7

[Doron Rosenberg (IBM)]

Attachment: fix another theoretical issue

Fixed the theoretical issue of injection via the link to update for missing
plugins.  In reality, the server chokes on the malformed url though :)

Comment 8

[Doron Rosenberg (IBM)]

Comment on attachment 179748 [details] [diff] [review]
fix another theoretical issue

sorry, missed a file.

Comment 9

[Johnny Stenback (:jst)]

Comment on attachment 179737 [details] [diff] [review]
patch

sr=jst

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 179737 [details] [diff] [review]
patch

r=dbaron too, although worth noting that this currently leaks (bug 241518).  We
can live with that, though.

Comment 11

[Doron Rosenberg (IBM)]

Attachment: fix theoretical issue and remove onclick attribute

Comment 12

[Doron Rosenberg (IBM)]

I could remove the listeners onunload if needed.

Comment 13

[Johnny Stenback (:jst)]

Comment on attachment 179756 [details] [diff] [review]
fix theoretical issue and remove onclick attribute

sr=jst

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

You (In reply to comment #12)
> I could remove the listeners onunload if needed.

You actually can't, since you don't have the listener object anymore.  But don't
worry about it -- we have this leak all over, and plugin install is basically a
one-time thing.

Comment 15

[Daniel Veditz [:dveditz]]

Fix released

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 179756 [details] [diff] [review]
fix theoretical issue and remove onclick attribute

Please don't forget to land this on the trunk.

Comment 17

[Doron Rosenberg (IBM)]

fixed on trunk.