Closed Bug 88143 Opened 23 years ago Closed 22 years ago

javascript: URLs in address book run as chrome

Categories

(SeaMonkey :: MailNews: Address Book & Contacts, defect)

x86
Windows NT
defect
Not set
major

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 144704

People

(Reporter: jruderman, Assigned: dveditz)

References

Details

(Whiteboard: security)

If address book entry contains a javascript: URL, and the user clicks on the URL, the javascript code is run with system principal. I don't know how hard it would be for an attacker to create an address book card, but if he could do that, I don't think it would be very difficult to get a user to click on the link in the card. Steps to reproduce: 1. Open address book. 2. Click on "new card" 3. Under the "address" tab in the dialog, put the following URL: javascript:alert(Components.classes); /* :// */4. Click OK (add the card to your address book). 5. Go to the card and click on the URL. Result: you get an alert saying [object XPComponents_Classes]. That means the javascript code was able to get a reference to Components.classes, which can only happen if the script is running with system principal (or with UniversalXPConnect).
Group: netscapeconfidential?
Candice, is there any way for someone to automatically create a card for you with the url prepopulated? I don't think that there is. I don't think any of the add to address book functions would allow this to happen and I we don't have add to address book for vcards.
I don't think there's a way to add\delete\edit an address book card with a url, only printing address book card is using url.
The collected addresses stuff doesn't appear to pick up on vcards (I tried). It probably should, and one day will, I guess.
See also bug 72212, link in address book replaces addrbook chrome instead of opening a browser window.
Group: netscapeconfidential?
QA Contact: fenella → nbaca
This bug was moved away from nsconf, probably as part of the mass qa contact change. Moving back til we have a policy on security bugs.
Group: netscapeconfidential?
reassigning to racham.
Assignee: chuang → racham
See also bug 108399, url shown in "link properties" dialog runs as chrome when clicked.
assignee_accessible: 0 → 1
Group: netscapeconfidential? → security?
CC list accessible: true
qacontact_accessible: 0 → 1
Accessible to reporter
What happens, if a normal http url is opened via the Address Book? Dies the webpage run as chrome then? If so, does it have special access? (Sorry for the lame question, some basic knowledge of Mozilla's component security would probaly answer this.)
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
It sounds like this can't be done automatically. How bad is this if the user has to do this itself before encountering this?
Target Milestone: mozilla0.9.9 → ---
Well, it depends. Do we pick up urls from vcards attached to emails? We didn't when I tested this. I don't think it can happen automatically. Its probably better to fix this sooner rather than later, though.
We can't through Mozilla, but you could add an address card through 4.7 and that could be imported. What I don't know is if we added the url when adding a vcard in 4.7
Blocks: 123383
dveditz, is this a dup of bug 144704? /be
Assignee: racham → dveditz
Status: ASSIGNED → NEW
Yes, the utilityOverlay.js fix will fix this one as well. *** This bug has been marked as a duplicate of 144704 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Verified duplicate.
Status: RESOLVED → VERIFIED
Group: security?
Whiteboard: security
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.