| |||||||||||||
Gnash, Lightspark, and ShumwayGnash, Lightspark, and ShumwayPosted Nov 23, 2012 22:56 UTC (Fri) by khim (subscriber, #9252)In reply to: Gnash, Lightspark, and Shumway by kripkenstein Parent article: Gnash, Lightspark, and Shumway 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++?
(Log in to post comments)
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.
|
|||||||||||||