CVE-2012-0464

IHNames

unread,

Apr 16, 2012, 10:48:29 AM4/16/12

to

Hello everybody,

I am currently working on my thesis, in which I try to evaluate the
security-implications of JIT-compilation (and ways to improve security
there).
I also made some slight modifications to the js-tracer (in particular,
I made nanojit mark its code-pages read/write instead of rwx). Now, I
would like to test my changes on a real bug. For this purpose, the
array.join("") problem revealed in the Pwn2Own contest looks
interesting.

However, information about it seems somewhat ...sparse. Could anybody
tell me some more about the causes of this particular problem and how
I might reproduce it?

The only real change I found in array_join itself seems to be a
replacement of js_ValueToString() with ToString(). The latter of
which, I believe, contains an additional check whether or not the
argument already is a string before further action (ToPrimitive and so
on) is taken. So... Is that the relevant change, or is there something
in array_toString_sub I missed, or was that bug fixed by a write-
barrier somewhere? Or is that information still strictly confidential?

Anyway, I would appreciate any hints and other input, if it possibly
can be given.
Best regards and thanks in advance,
Martin

Martin Stransky

unread,

Apr 16, 2012, 11:02:53 AM4/16/12

to dev-tech-...@lists.mozilla.org

You can find some info at
https://bugzilla.mozilla.org/show_bug.cgi?id=506693 which is the bug
"make JIT selinux compatible". I'm not sure how is the particular case
CVE-2012-0464 related here.

ma.

> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>

Joshua Cranmer

unread,

Apr 16, 2012, 11:29:11 AM4/16/12

to

On 4/16/2012 9:48 AM, IHNames wrote:
> Hello everybody,
>
> I am currently working on my thesis, in which I try to evaluate the
> security-implications of JIT-compilation (and ways to improve security
> there).
> I also made some slight modifications to the js-tracer (in particular,
> I made nanojit mark its code-pages read/write instead of rwx). Now, I
> would like to test my changes on a real bug. For this purpose, the
> array.join("") problem revealed in the Pwn2Own contest looks
> interesting.

From what I can tell of the relevant bug, the array.join("") problem
was caused by a GC hazard, which would mean that it has absolutely
nothing to do with JIT compilation.

IHNames

unread,

Apr 16, 2012, 1:48:33 PM4/16/12

to

On Apr 16, 5:02 pm, Martin Stransky <stran...@redhat.com> wrote:
> You can find some info athttps://bugzilla.mozilla.org/show_bug.cgi?id=506693which is the bug

> "make JIT selinux compatible". I'm not sure how is the particular case
> CVE-2012-0464 related here.
>
> ma.
>
>

Interesting thread! What happened to this patch? Is this code only
shipped with some SELinux-version of Firefox? It doesn't seem to exist
in the version I have.

Best regards,
Martin

IHNames

unread,

Apr 16, 2012, 1:57:04 PM4/16/12

to

On Apr 16, 5:29 pm, Joshua Cranmer <Pidgeo...@verizon.net> wrote:
>

> From what I can tell of the relevant bug, the array.join("") problem
> was caused by a GC hazard, which would mean that it has absolutely
> nothing to do with JIT compilation.

Hello,

I read that it was some sort of use after free issue, and I realized
that it is not directly related to the JIT-engine. Still, I thought
that I might use this vulnerability to test the viability (or lack
thereof) of my changes (the idea being that it would hopefully be
harder to find some executable code at the right time if the pages
produced by nanojit are not rwx all the time).

Thanks for the replies,
Martin

Martin Stransky

unread,

Apr 17, 2012, 8:01:00 AM4/17/12

to dev-tech-...@lists.mozilla.org

The patch is unused and I guess a bit outdated. JS folks do not want it
in trunk because of extra maintenance cost (AFAIK).

ma.

IHNames

unread,

Apr 18, 2012, 11:16:35 AM4/18/12

to

>
> The patch is unused and I guess a bit outdated. JS folks do not want it
> in trunk because of extra maintenance cost (AFAIK).
>
> ma.

I see... Well, it's curious that my first attempt at a modification
run along slightly similar tracks. I attempted to split the tracing-
engine into two separate processes (a page was mapped writable in one,
executable in the other, with shared memory in between). However,
keeping these two synchronized proved to be beyond my abilities.
Still, I wonder if the idea might have been feasible with more
knowledge about why the various invariants throughout the codebase are
the way they are.

Anyway, thank you for the information!
Best regards,
Martin