Weekly Edition
Return to the Security page
| |||||||||||||
A Tale of Two Pwnies (Part 1)
For those interested in complex exploits: the Chromium Blog describes
how a sequence of six independent bugs was exploited to execute code
within the Chromium browser. "Even though Chrome’s renderers execute
inside a stricter sandbox than the GPU process, there is a special class of
renderers that have IPC interfaces with elevated permissions. These
renderers are not supposed to be navigable by web content, and are used for
things like extensions and settings pages. However, Pinkie found another
bug (117417) that allowed an unprivileged renderer to trigger a navigation
to one of these privileged renderers, and used it to launch the extension
manager. So, all he had to do was jump on the extension manager’s IPC
channel before it had a chance to connect."
(Log in to post comments)
A Tale of Two Pwnies (Part 1) Posted May 23, 2012 4:03 UTC (Wed) by bradfitz (subscriber, #4378) [Link]
I'm not sure you can quote any part of that blog post to adequately capture the awesomeness of that exploit.
A Tale of Two Pwnies (Part 1) Posted May 23, 2012 6:44 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] Yes, it goes to show that even the most minor security bugs can't be ignored (as in: we can ignore the hole in sandbox A, because it only gets you into sandbox B so you're still contained). Many exploits have at least two steps: first trick a user into running a command as that user, then escalate using some local root exploit. But six steps is very impressive, and helps to show the limits of multi-layer security: you only have to break in one level at a time.
A Tale of Two Pwnies (Part 1) Posted May 23, 2012 8:04 UTC (Wed) by job (guest, #670) [Link]
Also, you get a glimpse of just how complicated a web browser is these days. Seriously, downloading insecure machine code and just executing it? Downloading shaders into the GPU?
Piling complex stuff on top of each other and trying to get it secure sounds like building a fail safe space shuttle. No matter how hard you try there's always going to be some combination of valves that gets you an unexpected outcome.
Mindblowing exploit though. Seriously humbling. There is nothing to make me doubt my own competence more than reading about what is likely some insanely hard work by a complete genius.
A Tale of Two Pwnies (Part 1) Posted May 23, 2012 9:40 UTC (Wed) by epa (subscriber, #39769) [Link] Yes, it goes to show that even the most minor security bugs can't be ignoredAmen to that. And let's hope everyone remembers this example next time we get more nonsense arguments about how security bugs aren't special, and can be treated the same way as any other bug, etc etc.
A Tale of Two Pwnies (Part 1) Posted May 23, 2012 10:19 UTC (Wed) by ms (subscriber, #41272) [Link]
Is not the point of this that every bug, no matter how innocuous it might appear has the potential to be used as part of a wider sequence of bugs to build security exploits? In which case every bug is potentially a security bug. Maybe we're just strenuously agreeing here...?
A Tale of Two Pwnies (Part 1) Posted May 23, 2012 10:40 UTC (Wed) by mpr22 (subscriber, #60784) [Link] All bugs in programs exposed to untrustworthy input are security bugs unless provable otherwise.
Trustworthy input? Posted May 23, 2012 12:00 UTC (Wed) by man_ls (subscriber, #15091) [Link] Your statement is harder than it looks: all input is untrustworthy unless proved otherwise.
Trustworthy input? Posted May 23, 2012 12:16 UTC (Wed) by mpr22 (subscriber, #60784) [Link] Your statement regarding the trustworthiness of input is a true and useful counterpart to my statement about bugs; thank you.
Trustworthy input? Posted May 25, 2012 10:26 UTC (Fri) by bricef (guest, #80336) [Link]
Conclusion: All bugs are security bugs unless your program takes no input.
Trustworthy input? Posted May 25, 2012 10:42 UTC (Fri) by man_ls (subscriber, #15091) [Link] A heuristic refinement of your statement would be: confine processing of user input to a specific module inside your program, and treat bugs in that module as security bugs. The remaining bugs should have lower priority (but they might also be security bugs if the input module doesn't do a good job).
A Tale of Two Pwnies (Part 1) Posted May 23, 2012 11:21 UTC (Wed) by ovitters (subscriber, #27950) [Link]
You don't always know if something is a security bug. Something which might just fix a compiler warning (unsigned comparison) might actually result in an exploit.
As long as you cannot easily tell that something is a security bug, you should focus on all bugs. Because in all those normal bugs might lie various security bugs as well.
Are they using the right technology? Posted May 23, 2012 12:41 UTC (Wed) by NAR (subscriber, #1313) [Link] 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.
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.
Let's see the big picture Posted May 23, 2012 13:34 UTC (Wed) by proski (subscriber, #104) [Link]
Chromium developers should be proud that it takes six bugs to exploit their code.
Let's see the big picture Posted May 23, 2012 14:09 UTC (Wed) by jonabbey (subscriber, #2736) [Link]
And that they had the confidence and good sense both to open source it and to give away prizes for breaking it, yes.
Things *ARE* getting better, in a few places Posted May 23, 2012 14:36 UTC (Wed) by david.a.wheeler (guest, #72896) [Link]
Absolutely. There are still lots of programs where a single defect - trivially found - breaks everything. Obviously, it'd be great if there were no vulnerabilities at all, but having to string together six weaknesses is still an improvement.
Things *ARE* getting better, in a few places Posted May 24, 2012 0:20 UTC (Thu) by nix (subscriber, #2304) [Link]
Quite. This is on a similar order to the number of failures needed to take down an airliner. Impressive.
Things *ARE* getting better, in a few places Posted May 24, 2012 13:53 UTC (Thu) by ean5533 (subscriber, #69480) [Link]
>This is on a similar order to the number of failures needed to take down an airliner.
I'm don't think "on a similar order" is really the comparison you meant to use. 1 is on the same order as 6.
Things *ARE* getting better, in a few places Posted May 24, 2012 15:46 UTC (Thu) by apoelstra (subscriber, #75205) [Link]
>I'm don't think "on a similar order" is really the comparison you meant to use. 1 is on the same order as 6.
Perhaps nix was thinking in base 2, in which case 6 is on the same order as 4 ;).
Things *ARE* getting better, in a few places Posted May 24, 2012 17:13 UTC (Thu) by dgm (subscriber, #49227) [Link]
Base e seems more "natural"...
Things *ARE* getting better, in a few places Posted May 25, 2012 8:32 UTC (Fri) by micka (subscriber, #38720) [Link]
You just made me discover non-integral representations. And I thought I was reasonably proficient in math...
Things *ARE* getting better, in a few places Posted May 28, 2012 13:26 UTC (Mon) by nix (subscriber, #2304) [Link]
No, I was thinking in English rather than in pedant. My mistake, on this site. :)
Let's see the big picture Posted May 23, 2012 19:47 UTC (Wed) by ballombe (subscriber, #9523) [Link]
At the same time the first bug is really nasty, so maybe they could improve their QA process.
How about the 10 bugs exploit? Posted May 24, 2012 14:20 UTC (Thu) by southey (subscriber, #9466) [Link]
You do realize that that part 2 will have Sergey Glazunov's "roughly 10 distinct bugs" (as mentioned at the end of the blog), right?
Having two exploits suggests that they still need to keep their 'pride' in check.
|
|||||||||||||