5 ms·

I'm skeptical of the claim of improved security. Theoretically, if there were some horrible bugs in the JIT, one could craft malicious input data causing the JI

I'm skeptical of the claim of improved security. Theoretically, if there were some horrible bugs in the JIT, one could craft malicious input data causing the JIT to insert arbitrary code in the code heap. In practice, it doesn't seem possible. At least HotSpot has been JIT:ing code for decades and no one has been able to find such an exploit.

justincormack 8y ago
JIT spraying for ASLR defeat is a thing https://en.m.wikipedia.org/wiki/JIT_spraying https://en.m.wikipedia.org/wiki/JIT_spraying
samps 8y ago
Security bugs in HotSpot happen can and do happen. Check out the CVE list for the JRE: https://www.cvedetails.com/vulnerability-list.php?vendor_id=93&product_id=19117&version_id=0&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=1&trc=599&sha=e7bd4bdaede94939bbb984bced9c264b834fc20c https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
snek 8y ago
You can read more about the use cases and targeted user here: https://goo.gl/kRnhVe https://goo.gl/kRnhVe They mention Cobalt (to allow targeting playstation), react native, nativescript, pdfium, and chrome's proxy resolver.
saagarjha 8y ago
> Theoretically, if there were some horrible bugs in the JIT, one could craft malicious input data causing the JIT to insert arbitrary code in the code heap. In practice, it doesn't seem possible. This is very possible: just do a search for ${your favorite JIT} arbitrary code execution, and you'll almost certainly see a real-world vulnerability. > At least HotSpot has been JIT:ing code for decades and no one has been able to find such an exploit. Yeah, no. See for example https://www.syscan360.org/slides/2013_EN_ExploitYourJavaNativeVulnerabilitiesOnWin7JRE7InOneMinute_YukiChen.pdf https://www.syscan360.org/slides/2013_EN_ExploitYourJavaNati...
- bjourne 8y ago
  But the feature the exploit takes advantage of isn't just in time compilation, it is compilation! An ahead of time java compiler would have suffered from the exact same problem. In fact, any language compiling to machine code would be just as vulnerable.
  - pitaj 8y ago
    Yes, but when pre-compiling, you implicitly trust the code. JITs like V8 are used to execute arbitrary code on your device, where such an exploit is much more harmful.
    - bjourne 8y ago
      Untrue. Dart code for example is AOT compiled but untrusted. Various Javascript implementations are also AOT but also supposed to be used for untrusted code.
      - pitaj 8y ago
        I have no idea what you're talking about. Under what circumstances is Dart AOT compiled and run untrusted? No browsers support Dart as a first-class citizen. If you're talking about compiling Dart into JS, that's obviously not what anyone is talking about. There are no Ecmascript AOT compilers. By definition, Ecmascript must be run with an interpreter. AFAIK with the dynamic complexity of the language it's impossible to AOT compile even without things like `eval` and `new Function`. A better example would be NaCl which as I understand it runs native machine code in a sandbox.
        bjourne 8y ago
        What I'm talking about? "Yes, but when pre-compiling, you implicitly trust the code." Citation needed. It's not true at all.
        geofft 8y ago
stefan_ 8y ago
Meltdown and Spectre are only possible in the browser because the JIT allows you to write JavaScript that you know is then compiled (JITed) into a very tight assembly loop. Same for Rowhammer.
- kllrnohj 8y ago
  That's not really a good argument. Taken to the extreme that'd be saying that JS engines should intentionally be slow in order to be "secure". JIT the code then inject a bunch of nop loops everywhere - you'd still be "preventing" meltdown, spectre, and rowhammer, but waste less power doing it.
  - stefan_ 8y ago
    JS engines are already intentionally slow. Look at all the hacks done to avoid random JS getting its hands on a precise timing source. Last time they straight up did away with SharedArrayBuffer. This is all done to keep JIT around despite the obvious and massive security impact.
coldtea 8y ago
>In practice, it doesn't seem possible. At least HotSpot has been JIT:ing code for decades and no one has been able to find such an exploit. Tons of JITs have had exploits... https://en.wikipedia.org/wiki/JIT_spraying https://en.wikipedia.org/wiki/JIT_spraying
reaperhulk 8y ago
As others have already noted, JIT codegen bugs leading to exploits do indeed happen and your intuition is mistaken. Here's one from Firefox's JS JIT from just a few months ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1493900 https://bugzilla.mozilla.org/show_bug.cgi?id=1493900
aasasd 8y ago
Aside from the other replies, I'm baffled as to how you decided that Hotspot being safe would mean V8 is safe.
olliej 8y ago
If I recall correctly every browser security bug in recent years has used the RWX blocks to get full RCE. If a process is not able to ever get RWX memory your code has to be entirely ROP/JOP based which is a much higher barrier.

justincormack 8y ago

JIT spraying for ASLR defeat is a thing https://en.m.wikipedia.org/wiki/JIT_spraying https://en.m.wikipedia.org/wiki/JIT_spraying

samps 8y ago

Security bugs in HotSpot happen can and do happen. Check out the CVE list for the JRE: https://www.cvedetails.com/vulnerability-list.php?vendor_id=93&product_id=19117&version_id=0&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=1&trc=599&sha=e7bd4bdaede94939bbb984bced9c264b834fc20c https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

snek 8y ago

You can read more about the use cases and targeted user here: https://goo.gl/kRnhVe https://goo.gl/kRnhVe They mention Cobalt (to allow targeting playstation), react native, nativescript, pdfium, and chrome's proxy resolver.

saagarjha 8y ago

> Theoretically, if there were some horrible bugs in the JIT, one could craft malicious input data causing the JIT to insert arbitrary code in the code heap. In practice, it doesn't seem possible. This is very possible: just do a search for ${your favorite JIT} arbitrary code execution, and you'll almost certainly see a real-world vulnerability. > At least HotSpot has been JIT:ing code for decades and no one has been able to find such an exploit. Yeah, no. See for example https://www.syscan360.org/slides/2013_EN_ExploitYourJavaNativeVulnerabilitiesOnWin7JRE7InOneMinute_YukiChen.pdf https://www.syscan360.org/slides/2013_EN_ExploitYourJavaNati...

bjourne 8y ago
But the feature the exploit takes advantage of isn't just in time compilation, it is compilation! An ahead of time java compiler would have suffered from the exact same problem. In fact, any language compiling to machine code would be just as vulnerable.
- pitaj 8y ago
  Yes, but when pre-compiling, you implicitly trust the code. JITs like V8 are used to execute arbitrary code on your device, where such an exploit is much more harmful.
  - bjourne 8y ago
    Untrue. Dart code for example is AOT compiled but untrusted. Various Javascript implementations are also AOT but also supposed to be used for untrusted code.
    - pitaj 8y ago
      I have no idea what you're talking about. Under what circumstances is Dart AOT compiled and run untrusted? No browsers support Dart as a first-class citizen. If you're talking about compiling Dart into JS, that's obviously not what anyone is talking about. There are no Ecmascript AOT compilers. By definition, Ecmascript must be run with an interpreter. AFAIK with the dynamic complexity of the language it's impossible to AOT compile even without things like `eval` and `new Function`. A better example would be NaCl which as I understand it runs native machine code in a sandbox.
      - bjourne 8y ago
        What I'm talking about? "Yes, but when pre-compiling, you implicitly trust the code." Citation needed. It's not true at all.
        geofft 8y ago

stefan_ 8y ago

Meltdown and Spectre are only possible in the browser because the JIT allows you to write JavaScript that you know is then compiled (JITed) into a very tight assembly loop. Same for Rowhammer.

kllrnohj 8y ago
That's not really a good argument. Taken to the extreme that'd be saying that JS engines should intentionally be slow in order to be "secure". JIT the code then inject a bunch of nop loops everywhere - you'd still be "preventing" meltdown, spectre, and rowhammer, but waste less power doing it.
- stefan_ 8y ago
  JS engines are already intentionally slow. Look at all the hacks done to avoid random JS getting its hands on a precise timing source. Last time they straight up did away with SharedArrayBuffer. This is all done to keep JIT around despite the obvious and massive security impact.

coldtea 8y ago

>In practice, it doesn't seem possible. At least HotSpot has been JIT:ing code for decades and no one has been able to find such an exploit. Tons of JITs have had exploits... https://en.wikipedia.org/wiki/JIT_spraying https://en.wikipedia.org/wiki/JIT_spraying

reaperhulk 8y ago

As others have already noted, JIT codegen bugs leading to exploits do indeed happen and your intuition is mistaken. Here's one from Firefox's JS JIT from just a few months ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1493900 https://bugzilla.mozilla.org/show_bug.cgi?id=1493900

aasasd 8y ago

Aside from the other replies, I'm baffled as to how you decided that Hotspot being safe would mean V8 is safe.

olliej 8y ago

If I recall correctly every browser security bug in recent years has used the RWX blocks to get full RCE. If a process is not able to ever get RWX memory your code has to be entirely ROP/JOP based which is a much higher barrier.