bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

ScribeFire extension evaluates JSON data in an unsafe way

RESOLVED FIXED

Status

addons.mozilla.org Graveyard
Administration
RESOLVED FIXED
10 years ago
2 years ago

People

(Reporter: Wladimir Palant, Unassigned)

Tracking

Details

(URL)

(Reporter)

Description

10 years ago
Looking at the file content/performancing_api.js, the method populateHistoryList() goes like this:

		var url = SCRIBEFIRE_BLOG.url + "api/read/json?start=0&num=50&type=regular";
		
		var req = new XMLHttpRequest();
		req.open("GET", url, true);
		
		req.onreadystatechange = function () {
			if (req.readyState == 4) {
				eval(req.responseText);
				
				var json = tumblr_api_read;

This means that the JSON data received from that blog URL (typically not even HTTPS I guess) is evaluated in chrome context and can take over the browser. There is similar code in content/zemanta.js, method getRelated(). For reference: https://developer.mozilla.org/en/JSON#Using_JSON
(Reporter)

Comment 1

10 years ago
There is more of this in content/quickblogging/add_from_flickr.xul and content/quickblogging/add_from_youtube.xul that communicate with http://api.flickr.com/ and http://gdata.youtube.com/ respectively.
(Reporter)

Comment 2

10 years ago
And yet some more. The file content/xmlrpc.js contains this code in method processReturnData():

  window.setTimeout("performancingUI.sendTrackBacks('"+theTitle+"','"+thePostLink+"','"+blogName+"')", 2500, true);

The values inserted here have been received from the website and apparently haven't been sanitized in any way. So if the server returns "http://foo/'+Components.classes+'/bar" as post URL it should be sufficient to run code in privileged context here. This is trivially solved by using closures:

window.setTimeout(function() {
  performancingUI.sendTrackBacks(theTitle, thePostLink);
}, 2500);

Comment 3

10 years ago
(In reply to comment #2)
> And yet some more. The file content/xmlrpc.js contains this code in method
> processReturnData():

I've fixed this bug; I'll be addressing the others you reported later today, as well as checking the rest of the codebase for similar indiscretions.

Comment 4

10 years ago
I've fixed all of the vulnerabilities mentioned above (thanks for bringing them to my attention), and I've gone through the rest of the code fixing for similar constructs that might have been taken advantage of.

Latest code changes can be seen at http://code.google.com/p/scribefire/source/list

Comment 5

10 years ago
Thanks Chris. Please test it and upload the fix to AMO. Email me directly once that's done and I'll push the update.

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Reporter)

Comment 6

10 years ago
I looked over the changes - all issues seem to be fixed, thanks a lot. Nice catch in monetize.js, I missed that one.
(Assignee)

Updated

2 years ago
Product: addons.mozilla.org → addons.mozilla.org Graveyard
(Reporter)

Comment 7

2 years ago
I think that this should be public by now.
Flags: needinfo?(jorge)
Group: client-services-security
Flags: needinfo?(jorge)
You need to log in before you can comment on or make changes to this bug.