| |||||||||||||
Are they using the right technology?Are they using the right technology?Posted May 23, 2012 12:41 UTC (Wed) by NAR (subscriber, #1313)Parent article: A Tale of Two Pwnies (Part 1) It's 2012. Why is a security critical application written in a language that tolerates integer overflow/underflow? Not to mention buffer overflow? Is performance so critical on today's hardware that we can't afford a runtime environment that checks for these kind of stuff? In my experience most of the waiting during browsing comes from network latency and no amount of hacking in the browser can make that faster... OK, the browser startup is also slow, but that depends on disk and I/O speed mostly.
(Log in to post comments)
Are they using the right technology? Posted May 23, 2012 13:03 UTC (Wed) by mpr22 (subscriber, #60784) [Link] Because if you ask ten different programmers which safe language should be the ubiquitous successor to $UBIQUITOUS_UNSAFE_LANGUAGE, you'll get ten different answers probably including "my completely perfect language that has never been used for any real-world application except its own compiler and in which you need a PhD to write 'Hello World'", "none of them because if you need a safe language to write safe programs you shouldn't be allowed to program", and conceivably "none of them because no programming language should be allowed to achieve ubiquity".
Are they using the right technology? Posted May 23, 2012 13:22 UTC (Wed) by NAR (subscriber, #1313) [Link]
And how is that relevant to my comment? The Chrome team could use one language that can avoid buffer overflows and integer overflows/underflows. There are decades old technologies out there with millions of users, making millions of dollars, just choose one. Or invent one (it's not like Google didn't create a language before). It doesn't have to be the "right for all cases" language, it just has to be able to avert these silly mistakes.
Are they using the right technology? Posted May 23, 2012 15:14 UTC (Wed) by Yorick (subscriber, #19241) [Link] You are perfectly right — no, they are clearly not using the right language for a security-critical program (which many of them are nowadays). The problem is that, even assuming that Google are free from the common prejudices and management stupidities that plague many companies (language X is unproven, it is too difficult to find programmers who know X, we are an all-Y shop, and so on), the choice is limited for the kind of application they want to write.There are languages that would do, at least ones that come close enough for a resource-rich company with the right ideas to build on and improve on in the directions required. It's not that we don't know how to avoid C's faults if we get to design something new, and decades of language implementation have also taught us one or two things. Of course C is difficult to replace in a world that is built around it — OS interfaces, libraries, third-party middleware, IDEs and tools. A modern web browser is formidably complex, being a hybrid of a large-scale GUI application, an embedded language runtime with a native code compiler, and a low-level system component. C and C++ are inadequate for all aspects of it, but can at least be used for all of it and are readily available. To take an example, the Rust developers may have the right level of ambition. Their design is conservative, avoiding too much fancy language technology, but enough for something that feels reasonably modern and avoids some well-known "billion-dollar" mistakes. I don't believe that C or C++ can be "fixed", either by extending the language or by inventing new tools. There are simply too many problems and they are too deeply engrained in the design.
Are they using the right technology? Posted May 23, 2012 13:33 UTC (Wed) by hp (subscriber, #5220) [Link]
It would be harder to write something like the Chrome core in any non-C/C++ language I know of. And I bet it would be noticeably slower. You could easily write some of the higher-level parts in something else (say, V8 JS) and for all I know they already do (along lines of http://blog.ometer.com/2008/08/25/embeddable-languages/ or Firefox).
But the multi-process, IPC, UI toolkit abstraction, native client, and graphics driver aspects almost require some kind of C/C++ core because you're messing with so many OS-provided C/C++ APIs. The higher-level languages all abstract these things away too much, or don't expose them at all, so you wouldn't have enough control to do what Chrome does.
If you think about it, in many ways the whole point of Chrome is to be a "device driver" and OS abstraction for the high-level platform (JavaScript, or perhaps Dart) that Google wants to use to write apps. So naturally it's in C/C++ in order to cope with all those lowlevel OS details and map them up into the high-level platform.
Something like C#/Mono that provides a fairly easy way to invoke C/C++ APIs would probably be a feasible C/C++ alternative, but it would drag in a pretty big hunk of extra code, which is probably enough to slow things down quite a bit just due to size and thus time to suck it off the disk.
Anyway, everyone especially Google I'm sure agrees that not everything should be in C/C++, but Chrome is the "OS" layer in a lot of ways, that's why it's in C/C++. It enables all the _apps_ to use the web platform instead of C/C++ but it can't be turtles all the way down.
Are they using the right technology? Posted May 23, 2012 22:13 UTC (Wed) by khim (subscriber, #9252) [Link] The higher-level languages all abstract these things away too much, or don't expose them at all, so you wouldn't have enough control to do what Chrome does. The reality is even worse. All such high-level supersafe languages are either slow as molasses or have huge core with JITs and other PhD-worthy components which in practice end up even less secure then Chrome. Don't forget that number one attack vector is not even MSIE nowadays, but JRE plugin and the second one is Adobe's Flash (which supposedly uses 100% safe ActionScript). Talk about safe languages :-)
Are they using the right technology? Posted May 23, 2012 23:19 UTC (Wed) by dashesy (subscriber, #74652) [Link]
I always learn from good comments like this. I should bookmark this, I think it will come handy, thanks.
Are they using the right technology? Posted May 24, 2012 0:17 UTC (Thu) by nix (subscriber, #2304) [Link]
The key here is that translators, optimizers, and language runtimes are all very complex beasts -- more complex than almost anything else written in them (other than some scientific code, I suppose). Since complexity brings insecurity, any translator designed to accept arbitrary code from potentially malicious sources is going to be a source of insecurity in and of itself, before you start considering the security properties of the languages it translates to or from.
Are they using the right technology? Posted May 24, 2012 16:47 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
That's why there is interest in pushing type safety down to assembly with TALs (typed assembly languages). It'll help to eliminate at most of the 'buffer overflow' type bugs.
And TAL checkers are fairly simple and small, so they can be thoroughly audited.
Are they using the right technology? Posted May 24, 2012 7:59 UTC (Thu) by epa (subscriber, #39769) [Link]
You could write it in C++ and use a checked_int class that traps all overflow. Or better, a bounded_int<1000> which stores a number between 0 and 1000 and throws an exception if you go outside that range - with some compile-time support for checking that arithmetic cannot overflow (e.g. adding two bounded_int<500>s produces a bounded_int<1000>, and can never overflow).
That doesn't in any way excuse the insane decision not to do overflow checking for standard integer types. The compiler should check overflow by default and offer an -funsafe-integer-overflow optimization switch for the small sections of performance-critical code where you want to turn it off.
Are they using the right technology? Posted May 24, 2012 8:52 UTC (Thu) by ncm (subscriber, #165) [Link]
A C++ or C compiler that generates code to check signed-integer overflow by default, and do anything at all (call a handler, throw an exception, dump core, close your network connection, erase your disk) is completely standard-conforming. Gcc and Clang could have such a feature in no time, if any of you-all cared to code it. Firefox and Chrome could use it immediately after. Probably the speed would not be noticeably affected.
But of course then the ground would shift to plug-ins and libraries. Most of those could be compiled using the same compiler option, for the same benefit, just as we-all already use our compilers' built-in stack-smashing protection (don't we?).
Likewise, any C or C++ compiler may do anything it likes with out-of-bound accesses to native array types. Code it, and anyone using Gcc or Clang can use it for free. Again, the resulting programs would still be miles faster than your favorite wanklage.
Do you run valgrind on code you are responsible for? Why not? Even in production use, C or C++ code running under valgrind is still faster than in most "advanced", "high-level" languages. Valgrind can also respond to violations it detects in programmed ways, independent of compiler or library.
The fault, dear brute, is not in our languages, but in ourselves, that we code insecurely.
Are they using the right technology? Posted May 25, 2012 4:03 UTC (Fri) by foom (subscriber, #14868) [Link]
> A C++ or C compiler that generates code to check signed-integer overflow by default, and do anything at all [...] is completely standard-conforming
Nice trick you pulled there, slipped "signed" in! Yes, that's true about signed overflow, but *NOT* unsigned overflow. Which makes the whole safety thing rather half-baked...
> Gcc and Clang could have such a feature in no time
In fact, that option already exists in GCC:
Except, it doesn't work; it's been totally broken for over 5 years and nobody has stepped up to fix it yet.
Are they using the right technology? Posted May 28, 2012 6:52 UTC (Mon) by ncm (subscriber, #165) [Link]
Unsigned ints don't overflow. They implement well-defined modular arithmetic. No operations on unsigned int yield undefined results.
If anybody actually had any use for range-checked C, that mode in Gcc would work. Likewise, array bounds checking. The reason that people don't have any use for them is that they would fail to catch the overwhelming majority of overflow and overindexing bugs. A program that fails to keep a short int less than 32768 is a program that also fails to keep it below 10000. A program that overindexes its built-in arrays also overindexes variable-sized storage.
Are they using the right technology? Posted May 28, 2012 13:25 UTC (Mon) by nix (subscriber, #2304) [Link] Unsigned ints don't overflow. They implement well-defined modular arithmetic. No operations on unsigned int yield undefined results.... which, if unexpected, can be and often is a security hole. You haven't solved anything.
Are they using the right technology? Posted May 23, 2012 14:35 UTC (Wed) by renox (subscriber, #23785) [Link]
> It's 2012. Why is a security critical application written in a language that tolerates integer overflow/underflow?
Even *new langages* such as D (and it isn't the only one) doesn't treat correctly integer overflow/underflow..
> Is performance so critical on today's hardware that we can't afford a runtime environment that checks for these kind of stuff?
Probably not: remember that we also use very slow langages..
I blame "mind" inertia: C did it this way, so we should also do it like this, nevermind that nowadays most of the time the bottleneck is the memory's access time not the CPU..
Are they using the right technology? Posted May 23, 2012 17:17 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] Besides, only one of the six bugs was a classic C/C++ bug with integer overflow allowing writing beyond the end of the array. The others were either timing attacks or failures to properly check input, and such bugs are language-independent.Switching to a "safe" language would eliminate one out of the six bugs, but then the expert cracker could look for flaws in the language implementation (bugs in the VM or the JIT) that might allow for an out-of-bounds write.
Are they using the right technology? Posted May 23, 2012 17:20 UTC (Wed) by lopgok (guest, #43164) [Link]
How is D a new language? It is 11 years old.
Writting a complex thing like a web browser in C/C++ is idiotic.
Are they using the right technology? Posted May 23, 2012 19:09 UTC (Wed) by renox (subscriber, #23785) [Link]
D is 11 year old, but D2 (which had many change) is younger and anyway it is much more young that Ada which has a sane way to handle integers..
Are they using the right technology? Posted May 23, 2012 20:05 UTC (Wed) by job (guest, #670) [Link]
Yeah, why not write it in a managed language where buffer overflows are impossible... you know, like PHP? I mean, security problems must be completely unheard of there. ;)
Are they using the right technology? Posted May 24, 2012 7:07 UTC (Thu) by eduperez (guest, #11232) [Link]
To be super-safe, I write all my critical applications in HTML / JS; now I just need a reliable browser...
Are they using the right technology? Posted May 24, 2012 8:02 UTC (Thu) by elanthis (guest, #6227) [Link]
Yes, performance is too much of a problem.
Remember, Chrome is partly so popular because it's so blazingly fast, even on very non-impressive hardware.
Even today, here in 2012, with all the mighty hardware we have, and even with the very latest cutting-edge safe managed no-sharp-edges languages and tools mankind has yet invented, C/C++ still can offer such an overwhelming improvement as to be worth it.
Especially when you consider just how few exploits Chrome has had, and how incredibly complex this one was to pull off. Clearly, C++ can be used to write highly secure software just fine, thank you.
Whatever theoretical academic super-secure language you're thinking of as a C++ replacement, at this point I'd be willing to bet that there's more exploitable holes in that language's compiler/VM/runtime than there are in Chrome's C++ codebase. :)
Are they using the right technology? Posted Jun 13, 2012 1:06 UTC (Wed) by sethml (subscriber, #8471) [Link]
Note that the Chrome project was started by former Firefox developers, so they were quite familiar with the concept of using a safe language (Javascript) to implement UI. Given that performance seems to be the main driver of Chrome usage, I think they made a reasonable decision.
|
|||||||||||||