| |||||||||||||
Gnash, Lightspark, and ShumwayGnash, Lightspark, and ShumwayPosted Dec 1, 2012 11:50 UTC (Sat) by HelloWorld (guest, #56129)In reply to: Gnash, Lightspark, and Shumway by cmccabe Parent article: Gnash, Lightspark, and Shumway
> Javascript has eval(), which C++ does not.
What eval essentially does is to launch a compiler and run the resulting code in the context of the currently running program. This is perfectly possible in C++: invoke a compiler, compile to a shared object and dlopen it. There is no fundamental difference between the two in that regard.
Also, eval is much less of a problem than memory-safety, as you can simply avoid using it. You can't avoid using memory.
(Log in to post comments)
Gnash, Lightspark, and Shumway Posted Dec 2, 2012 23:51 UTC (Sun) by cmccabe (guest, #60281) [Link]
Do you have g++ installed on your production servers? I sure don't.
> Also, eval is much less of a problem than memory-safety,
I'm not trying to argue which is the bigger problem. I'm just responding to the bogus "no additional vulnerabilities" claim.
Incidentally, have fun searching every Javascript library that you use to make sure none of them happen to use eval(). What's that? You don't do that? Sounds like you can't "simply avoid using it" then.
Here's another piece of advice: "simply avoid writing buffer overflow exploits." Hmm. Perhaps you can't "simply avoid" a fundamental feature of the language just by pretending it doesn't exist.
Gnash, Lightspark, and Shumway Posted Dec 3, 2012 0:33 UTC (Mon) by HelloWorld (guest, #56129) [Link]
> Do you have g++ installed on your production servers? I sure don't.
That doesn't alter the fact that it's just as possible to generate code at run-time in C as it is in JavaScript. And besides, there are libraries to facilitate just that, such as libjit, Lightning or Orc.
> Incidentally, have fun searching every Javascript library that you use to make sure none of them happen to use eval().
> Here's another piece of advice: "simply avoid writing buffer overflow exploits."
> Hmm. Perhaps you can't "simply avoid" a fundamental feature of the language just by pretending it doesn't exist.
Gnash, Lightspark, and Shumway Posted Dec 9, 2012 16:24 UTC (Sun) by oak (subscriber, #2786) [Link]
>> Hmm. Perhaps you can't "simply avoid" a fundamental feature of the language just by pretending it doesn't exist.
> > eval isn't a fundamental language feature any more than libjit/Lightning/Orc are.
Do Gnash or Lightspark use libjit/Lightning/Orc?
Nowadays browsers run the Flash plugins in separate processes. Is Shumway stuff run in a separate process or within the same browser process?
If latter, HTML interaction with JS may also needs to be considered for security, not just JS in isolation.
PS. One difference between compiled C/C++ code and JS is that latter is JITted for performance reasons, and also for performance reasons, the JITted code is typically memory mapped both as executable and writable. Whereas the compiled C/C++ code isn't mapped as writable in to memory.
While the JIT compiler probably is safe, I would expect the huge amounts of extra write/execute mapped memory to make injected code execution attacks elsewhere in Browser easier...?
Gnash, Lightspark, and Shumway Posted Dec 9, 2012 18:03 UTC (Sun) by cortana (subscriber, #24596) [Link]
The pages that store the result of the JIT compilation can have their mode changed once the compilation is complete, no?
|
|||||||||||||