
JITSploitation I: A JIT Bug - gok
https://googleprojectzero.blogspot.com/2020/09/jitsploitation-one.html
======
saagarjha
Don't miss part 2
([https://googleprojectzero.blogspot.com/2020/09/jitsploitatio...](https://googleprojectzero.blogspot.com/2020/09/jitsploitation-
two.html)) and part 3
([https://googleprojectzero.blogspot.com/2020/09/jitsploitatio...](https://googleprojectzero.blogspot.com/2020/09/jitsploitation-
three.html)), which demonstrate bypassing Gigacage and StructureID
randomization for arbitrary R/W and then getting PC control in the face of
PAC/APRR respectively.

~~~
pjmlp
Very interesting read, thanks.

------
MaxBarraclough
A king's game, to hunt JIT bugs for sport.

The crux of the bug is described in a code-comment ( _CSE_ stands for _common
subexpression elimination_ ):

> As _n_ is known to be negative here, this ArithAbs will become a
> ArithNegate. That negation will be checked, but then be CSE'd for the
> previous, unchecked one. This is the compiler bug.

~~~
saagarjha
To be clear, the ArithNegate implementation in CSE that had the bug, as its
implementation failed to take into account that the current mode might require
checking for an overflow (which is required for the tricky case of
-INT_MAX)–perhaps a typo or a copy/paste oversight. I wonder if anyone
(clearly not the JavaScriptCore team) has done the work to lift the semantics
of these optimizations to something formal and prove that they are correct…

~~~
pizlonator
As Groß correctly states in his post, the bug was in how clobberize models
that instruction. It’s not that this is a bug in CSE, since this analysis is
shared by (many) other passes.

It’s sort of also a bug in the IR design. The fact that opcodes have modes has
always caused bugs. It’s too easy to forget about that when modeling.

But that structure - separation of modeling and CSE - is designed to make the
whole thing easier to reason about despite the underlying semantics being
quite nasty.

It’s weird to say that JSC team clearly wouldn’t try to prove this right by
lifting the semantics out or what have you. What makes you say that?

~~~
saagarjha
> It’s not that this is a bug in CSE, since this analysis is shared by (many)
> other passes.

Is DFGClobberize not part of CSE? I read the post and glanced at the code and
I’m not sure if I understand your clarification otherwise.

Do note that my comment is not the team “clearly wouldn’t try to prove this
right” but is really “hasn’t proved this right”, the “clearly” part being a
reference to this bug ;) I would be extremely surprised if there hasn’t been
work done by the team to partially verify instruction side effects given how
often they lead to bugs in the JIT (I haven’t seen much writing much about it,
though, so if there’s something on the WebKit blog about this I’d love to give
it a read). However, what I’m suggesting is some sort of proof that the
semantics encoded in JavaScriptCore are complete and correct; maybe with some
formal language specification involved. Or maybe you could have the CI
machines churn through the entire state space for the unary instructions
during the holidays or something :)

~~~
pizlonator
Clobberize is an effect analysis used by many phases including CSE. It is not
“part” of CSE.

------
sloshnmosh
Never enable JavaScript in safari for iOS while browsing the web.

There is something very, very wrong and you will see some disturbing crash
logs.

~~~
Google234
Never connect to the internet either. You will see disturbing logs in your
firewall.

