| |||||||||||||
Gnash, Lightspark, and ShumwayGnash, Lightspark, and ShumwayPosted Nov 23, 2012 13:03 UTC (Fri) by kripkenstein (subscriber, #43281)In reply to: Gnash, Lightspark, and Shumway by dgm Parent article: Gnash, Lightspark, and Shumway
Yes, JS has security vulnerabilities. But it has no additional ones over C++, and has fewer (it is memory-safe, has an API designed for sandboxing, etc.).
(Log in to post comments)
Gnash, Lightspark, and Shumway Posted Nov 23, 2012 22:56 UTC (Fri) by khim (subscriber, #9252) [Link] The only thing which makes JS "safe" is browser's sandbox. It's perfectly compatible with C++, so I don't see what are you talking about. What awful additional "security hazards" exist in C++?
Gnash, Lightspark, and Shumway Posted Nov 24, 2012 23:45 UTC (Sat) by intgr (subscriber, #39733) [Link] > What awful additional "security hazards" exist in C++?Undefined behavior. It's the number 1 reason why computers are so insecure today.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 10:01 UTC (Sun) by khim (subscriber, #9252) [Link] Undefined behavior is a problem, yes, but JS and PHP have it's own answer to his problem: non-transitive comparisons. Practically speaking these produce similar number of vulnerabilities (well, PHP has SQL-injections which, of course dwarf both C and JS problems, but we are not comparing PHP and C, but JS and C).
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 14:02 UTC (Sun) by intgr (subscriber, #39733) [Link]
I agree that it's ugly, but... WTF, a similar number of vulnerabilities? I can see how PHP's comparison rules can cause vulnerabilities, but JavaScript is a great deal better.
On the other hand, NEARLY ALL security announcements these days are a result of undefined behavior in C code. In many cases, C undefined behavior leads to code execution, whereas that just cannot happen in JavaScript unless the coder explicitly calls eval() -- which is used almost never in real code.
Undefined behavior and intransitive comparisons aren't even in the same league.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 21:38 UTC (Sun) by khim (subscriber, #9252) [Link] I agree that it's ugly, but... WTF, a similar number of vulnerabilities? I can see how PHP's comparison rules can cause vulnerabilities, but JavaScript is a great deal better. No, it's not. There are about bazillion vulnerabilities found on web sites every day. I mean, XSS, data leaks, etc. Vulnerabilities which affect the web application itself, not the rest of the system. Rest of the system is not affected by JS vulnerabilities because web apps are sandboxed. Well, you can sandbox C++ application, too, so what's the big deal? On the other hand, NEARLY ALL security announcements these days are a result of undefined behavior in C code. Well, sure. That's because security-sensitive unsandboxed applications are written in C++. How many of them are written in JavaScript? In many cases, C undefined behavior leads to code execution, whereas that just cannot happen in JavaScript unless the coder explicitly calls eval() -- which is used almost never in real code. Is this a joke or are you really that dumb? Javascript programs have bazillion places where eval() can be injected. Do you add some data from user to the page? Thank you, thank you - that's eval right there, just add <script></script>. Do you change innerHTML? Thank you, thank you - that's another place for eval, just add "<script></script>". And so on. Javascript programs are actually more vulnerable then their C++ counterparts, but most problems are contained because of browser's sandbox. Well, you can add sandbox to C++, so what's the big deal?
Gnash, Lightspark, and Shumway Posted Nov 26, 2012 9:21 UTC (Mon) by intgr (subscriber, #39733) [Link]
Dafuq? In the last post you were trying to convince me how non-transitive comparisons in JavaScript *the language* is the worst security flaw ever.
Now you suddenly changed topic to HTML and web technologies and claim I'm "dumb" for not reading your mind? Remember, you were comparing C++ with JavaScript, not C++ with HTML or "the web" (does that even make sense?).
JavaScript is also used in Node.JS, Mozilla's XUL GUI, Gnome 3, PostgreSQL stored procedures, etc etc. None of these are vulnerable to the HTML vulnerabilities you describe.
And don't get me wrong -- I certainly agree that the way how web applications and JavaScript interact with HTML is a very generous place for security problems. But these aren't a problem of JavaScript *the language*.
> Do you change innerHTML?
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 20:26 UTC (Sun) by kripkenstein (subscriber, #43281) [Link]
It is possible to sandbox C++ to some extent, yes. However,
1. It was not designed for that from the beginning, so the result has some tradeoffs (not all C++ code can run in a sandbox, performance is not quite the same, etc.).
2. Practically speaking, if you have a web browser with one sandbox that you spent huge efforts on (and all do), adding another sandbox means a lot of additional effort and risk. The risk comes from the fact that each sandbox will have vulnerabilities, so having more sandboxes means more of them.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 21:22 UTC (Sun) by khim (subscriber, #9252) [Link] It was not designed for that from the beginning, so the result has some tradeoffs Well, of course. not all C++ code can run in a sandbox That's kinda definition of sandbox, you know. If all code (including malicious code) can run in sandbox then why will you need any sandbox at all? All correct ANSI C/C++ code should work in sandbox (as long as it does not try to do anything forbidden, that is). performance is not quite the same, etc. Without sandbox it's 100 times faster, with sandbox it's only 50 times faster. Not a big deal, really. Practically speaking, if you have a web browser with one sandbox that you spent huge efforts on (and all do), adding another sandbox means a lot of additional effort and risk. The risk comes from the fact that each sandbox will have vulnerabilities, so having more sandboxes means more of them. Not all sandboxes are created equal. If you compare 100'000 LOC of JS sandbox (with some handwaving which should explain that it works... if you are lucky) and formally proven C++ sandbox... I'm not sure amount of effort is relevant, really. Chrome example is pretty convincing: JS sandbox had more known vulnerabilities then C++ one, but, more importantly, most vulnerabilities are not in JS-specific parts or C++-specific parts but in common parts which work with WebKit.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 21:35 UTC (Sun) by kripkenstein (subscriber, #43281) [Link]
You are right that a small sandbox for C++ can be safer than a big one for JS. It's a fact that sandboxing a JS engine is a hard problem, it requires PICs and so forth to be fast.
But the web platform *forces* everyone to have a JS engine. So that work is already done (and the sandboxing is quite good these days). Adding another sandbox is a net increase in vulnerabilities. You can't not have the JS sandbox, but you can not have the C++ one.
Regarding 100x vs 50x - try 6x vs. 3x in modern JS engines on modern codebases.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 21:08 UTC (Sun) by cmccabe (guest, #60281) [Link]
Javascript has eval(), which C++ does not. This can be a security vulnerability in some cases. Not to mention the cross-site scripting attacks which can often be pulled off against JS code in the wild.
Safer than C++? Sure. "No additional vulnerabilities"? No.
Please don't turn this into yet another "my programming language is better than yours" thread.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 21:11 UTC (Sun) by kripkenstein (subscriber, #43281) [Link]
We are talking about different kinds of vulnerabilities. eval() can cause problems, sure, but eval in a sandbox still can't escape the sandbox. C++ code, on the other hand, can in general affect the outside system.
For a browser itself running Flash (not a website), one type of vulnerability is much more important.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 21:25 UTC (Sun) by khim (subscriber, #9252) [Link] We are talking about different kinds of vulnerabilities. eval() can cause problems, sure, but eval in a sandbox still can't escape the sandbox. C++ code, on the other hand, can in general affect the outside system. No, it can not do that. The most you can do is create some kind of logic fault in the program itself - exactly what eval() tends to do. Effects buffer overflows in C++ program and misquoting in eval() in JS tend to be surprisingly similar.
Gnash, Lightspark, and Shumway Posted Dec 1, 2012 11:50 UTC (Sat) by HelloWorld (guest, #56129) [Link]
> 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.
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?
|
|||||||||||||