470353 - TM: Potential LIR buffer overflow during compilation

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Graydon Hoare :graydon]

TraceMonkey writes native stack "snapshots" to LIR buffers any time it's generating a guard. These stack snapshots are ostensibly bounded in size by MAX_NATIVE_STACK_SLOTS, but it seems we only check that we stayed within that limit at the end of compilation (throwing out the trace if any snapshot was too big). This is a problem. If in the interim someone has convinced us to write a particularly large stack snapshot -- such as in bug 464862, where the reported condition involves a 2008 byte write, accidentally -- they can possibly convince us to write more than can fit on a single LIR page. 

I have no idea what happens when you write past the end of a LIR page, but I imagine it's something like "scribbling over the internals of the compiler", which is the sort of thing that makes me think it's a security issue. The stack frames written are, to some extent, under the control of an attacker, though they mostly consist of typemaps, which are bytes in the range 0x00 - 0x0f; with some careful reverse engineering of the compilation pipeline I can squint and imagine it turning into an exploit nonetheless.

There is a NanoAssert() that any ::commit() to a LIR buffer occurs on the same page, but of course, that's turned off when shipping! I can't find any other checks.

I did not accompany the original bug with a fix because it requires a certain amount of auditing before I'm comfortable saying I found all the places that perform such writes, and the first spot I looked at doesn't have an obvious way to bail out anyway (::shapshot).

Comment 1

[Graydon Hoare :graydon]

Attachment: An attempt to avoid the arbitrary-skip cases

Comment 2

[Andreas Gal :gal]

Comment on attachment 357251 [details] [diff] [review]
An attempt to avoid the arbitrary-skip cases

This will collide with david's global patch.

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

Looks like it'll merge okay.

Comment 4

[Graydon Hoare :graydon]

http://hg.mozilla.org/tracemonkey/rev/0a9626d5642c

Comment 5

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/0a9626d5642c

Comment 6

[Robert Sayre]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/95cb681049e7