18 ms·

I'll be that guy. Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security. They sandbox their

I'll be that guy. Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security. They sandbox their code aggressively. They build this project with security in mind from day 1 - it's been architected for it. The Chrome security team(s) has a lot of power for a product security org. They fuzz. They invent new fuzzers. They cluster their fuzzers. They have a world class bounty program. They have a world class research team for finding vulns. They invent or otherwise aggressively adopt mitigation techniques. But someone out there did it. Their track record for security is something to really be proud of - this is the first public ITW exploit of its type that I am aware of. But users are getting owned because of, at the very least, a Use After Free vulnerability. Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. edit: (From a post below) To be clear, I'm not saying "Chrome should be rewritten in a memory safe language", I'm saying that Chrome is an excellent project to point to, say "Wow, no one does as much to secure a codebase as them", and to follow that up with "and they still got owned by UAF".

elorant 8y ago
So what language should they've written it in?
- deleted 8y ago
  [deleted]
- staticassertion 8y ago
  A memory safe one. There are many of them. They could build their own if they chose to - they've built multiple languages in the past. Picking a language for the Chrome team doesn't seem practical - we all know where your question is going to head. The point is they have to not pick C++. Again, they've invested many, many millions of dollars into security. Let's not pretend that they're priced out of using another language.
  - gpm 8y ago
    It doesn't even have to be memory safe, just less memory accident prone. D for example would have been an interesting choice (and I think it was usable back then).
    - flukus 8y ago
      D was released in 2001, KHTML in 1998, it's like suggesting they should have written vim in java.
      - jlgaddis 8y ago
        ... and Chrome in 2008.
        jsjohnst 8y ago
        Chrome wasn’t written from scratch in 2008. Chrome was a fork of WebKit, which was a fork of Konqueror, which was a fork of KHTML.
        kolme 8y ago
        KHTML is the rendering engine for the Konqueror browser. Webkit is a fork of KHTML. And Chrome's engine is called Blink (it used to be Webkit, but they forked it).
    - kllrnohj 8y ago
      D would be interesting but it's also not memory-safe. Not strictly. You can restrict yourself to SafeD, but then you're stuck with a GC you don't really want. Or you can tag all your functions as @Safe, but then it's just a "best practice" and you can't do it everywhere because you can't do things like make system calls. D has some interesting bits, but it did a lot of head-scratching stuff too. It seemed really confused about what target it was going after, like some middle ground between C#/Java & C/C++ that really doesn't seem to exist.
  - deleted 8y ago
- bauerd 8y ago
  Use-after-free is ruled out by e.g. Rust's type system
  - htfy96 8y ago
    Nope. It's only true when all your code use safe subset/built upon a perfectly correct unsafe base (which is inevitable in a project like Chromium) with correct usage. Otherwise a single misused external call with unsanitized value can ruin all of your security guarantee.
    - Ygg2 8y ago
      Not really. It's been proved that if your unsafe foundations are correct and don't break the rules (i.e. their precondition is correct), then anything safe built on top of that is also correct. Sure you could rely on a C/C++ library that causes problems, but then again you can either: A) fix that library B) replace that part with Rust or even stricter language.
- ancarda 8y ago
  C++, as that was a reasonable choice in <=2008. Today, perhaps new projects should pick something else (likely Rust). Bits of Firefox are written in Rust, so Chrome could in theory under go the same "oxidation" (gradually replace the C++ code with Rust). Edit: Clarify that Chrome was released in 2008 but was likely in development for some time before that.
  - core-questions 8y ago
    > Chrome was released in 2008 but was likely in development for some time before that. Well, sure, didn't it end up taking WebKit from Safari, which was C++, because it came from KDE Konqueror's KHTML?
    - catach 8y ago
      Yes, Chrome was a fork.
  - simcop2387 8y ago
    Yes, the KHTML base for the rendering engine was started back in 1998, so C++ was a fine choice then. It's grown up as a code base significantly since then.
- TimTheTinker 8y ago
  I'll be that guy. :) Rust. (I'm a front-end dev. I have no dog in this fight.)
  - asveikau 8y ago
    It's funny how we define terms like "front-end" and assume a specific meaning. A web browser is certainly the front of something.
- baby 8y ago
  Rust.
peterwwillis 8y ago
No codebase will ever be fully free of security bugs, but having 7 million lines of code definitely doesn't help.
- staticassertion 8y ago
  The question is, how much effort is it to keep users safe given language X vs C++. Apparently, when the language is C++, the value is somewhere above many millions of dollars, and we don't know what it is. Can we reasonably expect that price to be lower with language X? For many reasons, I would argue 'yes'.
  - kllrnohj 8y ago
    Sure, but is your goal maximal safety no matter the cost, or are you trying to strike a balance with other factors? If all you want is to keep users safe then it'd be easy - ban JavaScript wholesale. Bam, done, instantly made the web safer & faster. Don't even need to deal with the huge security can of worms that is WebGL, either. But safety is rarely the exclusive factor in play, now is it? Things like memory usage efficiency & performance also play large roles here.
    - staticassertion 8y ago
      To be clear, I'm not saying "Chrome should be rewritten in a memory safe language", I'm saying that Chrome is an excellent project to point to, say "Wow, no one does as much to secure a codebase as them", and to follow that up with "and they still got owned".
      - kllrnohj 8y ago
        But to what end? Pure-java apps get owned all the time, too. If you look over there you'd just give up on ever trying to transmit data, as the number of Java de-serialization exploits is nothing short of stunning. The only semi-proven way to not get owned at this point is to never go online.
stcredzero 8y ago
Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. Do they distrust their own coders to the same degree they distrust the processes they sandbox? I suspect the answer to this is "no" but I would like to hear from someone who actually codes there. I think the truth is more like this: You can write safe C++, just like you can keep a secret. It's just that the odds that you fail go up with the size of the team involved, and it does that by compounding. So by the time you get to the size of the Google Chrome team, the odds of failure are very, very close to 1.
- nothrabannosir 8y ago
  The number of people required was a function of the "this complex" qualifier. I can write a safe C++ app on my own. I can't write Chrome on my own.
  - Johnny555 8y ago
    I can write a safe C++ app on my own But only if you don't use any external libraries, once you link in someone else's code, you can no longer be sure your program is "safe".
    - stcredzero 8y ago
      once you link in someone else's code, you can no longer be sure your program is "safe" This also fits in with the "keeping a secret" analogy. Good luck keeping something secret, if it has to be shared between organizations.
    - chii 8y ago
      > I can write a safe C++ app on my own >> But only if you don't use any external libraries using an external library is not "on your own"
      - dymk 8y ago
        Can you use the STL? What boundary is considered trusted?
ru999gol 8y ago
if you think C or C++ programmers are ever going to admit this, you must never have met one
- monocasa 8y ago
  I feel like I can call myself a "C++ programmer"; I was the lead for C++14 RTOS. It's pretty hard to argue with the OP's logic.
- ciphergoth 8y ago
  What is a C/C++ programmer? I've written fairly large amounts of C/C++ over the course of my career and I continue to do so. I totally concur with this and am eager to see Rust take its place over time.
- pjmlp 8y ago
  I was mainly a C and C++ developer until 2006 and you will see me praise C++, but also be an heavy critic of the copy-paste security exploits it inherited from C.
flukus 8y ago
> According to the official release notes, this vulnerability involves a memory mismanagement bug in a part of Chrome called FileReader. That’s a programming tool that makes it easy for web developers to pop up menus and dialogs asking you to choose from a list of local files, for example when you want to pick a file to upload or an attachment to add to your webmail. It sounds like the bug occurs interacting with external code, win32 or equivalent. Even if chrome were written in a "safe" language this section would likely be in unsafe block.
- pcwalton 8y ago
  According to the patch, the problem involves memory management of DOM objects (specifically ArrayBuffers), not objects from native libraries.
bla3 8y ago
If there's ever a project as large as Chrome written in a non-C++ language, I guarantee you it will have these bugs as well -- due to use of `unsafe`, or bugs in the compiler, or what have you.
- pcwalton 8y ago
  How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one. †I explicitly say "not running arbitrary Java code" to emphasize the difference between this scenario and JS engine vulnerabilities. JS engine vulnerabilities are a problem because JS engines execute untrusted code, but I'm talking about compiler bugs in trusted code that can nevertheless be exploited remotely.
  - kllrnohj 8y ago
    > How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one. Seems like an odd restriction to impose here. How many C++ exploitable bugs arose from a C++ compiler bug? I think the answer to that is also zero. Doesn't really seem like a useful thing to consider? But in terms of Java runtime's security it's not particularly stellar. The entire category of "Java deserialization" is the never ending fountain of remotely exploitable security bugs in Java apps that don't run untrusted code.
    - pcwalton 8y ago
      > Seems like an odd restriction to impose here. How many C++ exploitable bugs arose from a C++ compiler bug? I think the answer to that is also zero. Doesn't really seem like a useful thing to consider? Right, and that's why the fact that the Rust compiler has bugs is irrelevant. The language is meaningfully more memory-safe than C++. > But in terms of Java runtime's security it's not particularly stellar. The entire category of "Java deserialization" is the never ending fountain of remotely exploitable security bugs in Java apps that don't run untrusted code. Java deserialization RCEs, while pernicious, are nowhere near as common as use-after-free and related bugs in C++ code. Furthermore, you can effectively mitigate them by statically banning OutputObjectStream and whatnot. There's no such easy foolproof static mitigation available for C++ UAF.
nitwit005 8y ago
In a general sense, I'd agree, but from the description in that article, it's interaction with native files or file dialogs. Even if you use Java, you're susceptible to this sort of bug, because your Java code calls into layer of C code to handle the native interaction. Realistically, any browser is probably going to have a decent amount of unsafe code surrounding the native windowing, files, graphics, and so on.
- pcwalton 8y ago
  Look at the patch; it's a use-after-free bug involving DOMArrayBuffer and ArrayBuffer, which are Chrome objects, not native OS objects.
deleted 8y ago
[deleted]
baby 8y ago
Hence why it is freaking amazing to follow what Firefox is doing with Rust.
wahern 8y ago
Without knowing more there's zero reason to blame C++. This looks like it implicates (a) a questionable but quite intentional performance optimization and (b) possibly a V8 GC race or otherwise an issue with reference consistency between the C++ code and the JIT'd JavaScript runtime. Both of those issues would exist regardless of the language chosen--D, Erlang, Java, Python, Rust, w'ever. Remove V8's JIT and GC and then one can have a meaningful discussion about memory safe languages. But remove those and the vast majority of Chrome bugs would also disappear. Those are the places of highest complexity while also being the areas which no language offers any meaningful assistance. And this is why I think it's crazy that the WebAssembly folks are dead set on a specification that presumes and requires tight, direct object bindings between the host and the WebAssembly VM, particularly wrt JavaScript GC integration, as opposed to using indirect references with a clear contract that employ proxy objects for anchoring--in effect a sort of runtime sandboxing which falls short of IPC but which substantially circumscribes system complexity (e.g. invisible data dependencies) and substantially preserves the ability for memory-safe host languages (compilers and runtimes) to meaningfully ensure their invariants. What we need more than yet another memory-safe language is the motivation and experience in multi-language integration. What we're getting are another generation of programmers recapitulating many unforced errors. Memory-safe languages aren't new. Nor are memory-safe and ergonomic languages. Nor is, for that matter, the thinking that one can throw a single language at a complex problem despite the entire history of computer science being an unending parade of new languages and optimization models with poor integration stories. Bare C FFI is only the most minimal and easiest requirement to get correct when it comes to integration. There's so much more to the problem.
- staticassertion 8y ago
  > there's zero reason to blame C++ Seems like UAF in C++? So, yes, I feel comfortable blaming C++. Anyways, I didn't mention memory safe languages in my post, and I'm not even suggesting that Google did anything wrong, or should change their posture in any way. They've been extremely successful.
  - wahern 8y ago
    UAF by whom? If it's through a bare reference held in the JavaScript VM where operations don't access the C++ object as a C++ object or as some shared primitive object as in the JVM or CLR, then the error is in maintaining state consistency across distinct environments. Such bugs look exactly the same in every language, although the risk is compounded by (a) JIT'd environments and (b) asynchronous execution. In the context of a bug involving JavaScript ArrayBuffers (where JIT compilers are designed to optimize away both FFI accessors and bounds checks) and asynchronous events I think it would be prudent to withhold judgment.
zrm 8y ago
> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. And so, as they say, we should all be using Rust. But allow me to explain why I don't yet. Rust has one really outstanding feature -- a borrower checker that makes it memory safe. Adding that to C++ would be a compatibility-breaking change. So then, while they were at it, they changed lots of other things. It's a whole different language, separate syntax, generics that work differently than templates, different standard library, etc. This interacts with the finite amount of time I have to learn a new language, making it take longer before I feel proficient enough in it to start using it for real work. Sufficiently long that the day that I do is still in the future. I understand the desire to make changes. Many of the changes are improvements, and C++ can be ugly. But it's the devil we know. A version of it with the minimum necessary changes to add a borrow checker would have me using it already, and I expect I am not the only such person.
- sanxiyn 8y ago
  Different standard library is kind of unavoidable because you need standard library interface understood by borrow checker.
  - zrm 8y ago
    That's the compatibility-breaking part. Doesn't mean the replacement function or object can't have the same name, purpose, time complexity, etc. You could potentially even continue to support the existing ones but regard them as unsafe and have the compiler warn if they're used.
  - pjmlp 8y ago
    Microsoft already does that with their SAL annotations. https://docs.microsoft.com/en-us/visualstudio/code-quality/using-sal-annotations-to-reduce-c-cpp-code-defects?view=vs-2015 https://docs.microsoft.com/en-us/visualstudio/code-quality/u... Which they are extending to also support their C++ lifetime checker.
- duneroadrunner 8y ago
  They are working on it. The analogue to the borrow checker in C++ is called the "lifetime profile checker" and (an incomplete version) is included in MS Visual C++, but last time I checked (in January) it seemed to still have too many false positives to be practical. In the mean time, I think "the minimum necessary changes" to achieve memory and data race safety is to replace all your unsafe C++ elements (pointers, arrays, vectors, string_views, etc.) with compatible substitutes from the SaferCPlusPlus library [1]. You don't even need to replace them all at once. You can replace them incrementally and your code will continue to compile and run throughout the process. And where needed, maintain maximal performance as well [2]. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksGame https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...
euske 8y ago
I think it's a time that we should get rid of this notion of "perfectly safe code in the perfect world". It might be possible if the code doesn't change for million years, but that's not how the world works - things keep changing, the specs, the requirements and the users. Bugs are created every day. It's not about safety as a static property, but it is about the safety in an ever-changing world. As Bruce Schneier put it, it's a process. And yes, C++ might be bad for it, but that's only a part of the whole picture. We should look at the process rather then the code itself.
- kasey_junk 8y ago
  The OP’s entire point is that effectively no one has looked at the whole process in a more robust way than the Google Chrome team. They are literally at the vanguard of that issue, yet they got owned up by a well known code problem.
zetafunction 8y ago
> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. I work on Chrome. The working assumption is there always exists a bug that allows remote code execution in the renderer.
- gsich 8y ago
  Slightly OT: revert the ugly design introduced in Chrome 71 (or 70).
- nneonneo 8y ago
  So what happened here? There's an in-the-wild exploit that's bypassing sandboxing - so there must be at least two bugs, or the sandbox isn't tight enough (which, for Chrome, would surprise the hell out of me).
  - aboodman 8y ago
    I used to work on Chrome. There have been periodic sandbox escapes, and chained exploits that escape to userland are routinely performed at pwn2own. This is just notable because there is a live exploit in the wild.
    - GordonAitchJay 8y ago
      There there any public information about what the live exploit does?
  - intherdfield 8y ago
    "The second vulnerability was in Microsoft Windows. It is a local privilege escalation in the Windows win32k.sys kernel driver that can be used as a security sandbox escape." https://security.googleblog.com/2019/03/disclosing-vulnerabilities-to-protect.html https://security.googleblog.com/2019/03/disclosing-vulnerabi...
- LukeB42 8y ago
  Bad time to ask for browser extensions on mobile then?
fooker 8y ago
That's a weird and dishonest point to make here. You can't write safe $ANYTHING for a codebase this complex. I am yet to see someone who has worked on a codebase this complex disagree. Security issues and crashes in general result from your program interacting with the outside world and something behaving in a way you did not account for.
- throwawaymath 8y ago
  What’s dishonest? No one has said language choice is a silver bullet for all classes of security vulnerabilities. The point under contention is that we have better options for memory corruption vulnerabilities in particular. In other words we’re not talking about whether or not something will be totally safe, but rather safer. Perfect is the enemy of good.
scoutt 8y ago
Is there an official explanation of the kind of bug? I cannot find it. "Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex." Pointing the finger and saying "see?" is a pretty low quality argument. So, I guess we should wait for the first Rust or managed language remote exploit (or whatever) to say "admit it, finally - you can't write safe... programs?".
- apta 8y ago
  Managed languages remove an entire class of exploits present in C and C++ programs. That alone is a very good start.
Grue3 8y ago
The real problem is that the web is now too complex to the point that it's impossible to safely implement it. And W3C keeps trying to add new features to it. At some point we have to stop and consider whether all this cruft is even necessary.
- sanxiyn 8y ago
  Of course all the cruft is necessary due to compatibility. (Browsers monitor usage statistics and do remove crufts when possible.)
  - chriswarbo 8y ago
    "Polyfills" are quite common in Web development, and are also proof that browsers do a whole bunch of unneeded stuff (if it were needed, there would be no way to polyfill it). I actually think polyfill usage is backwards: the current approach allows code targetting new features to be made compatible with old browsers, by the site providing polyfills. I think it's much better for new browsers to be leaner, simpler and more well-thought-out than their predecessors. Such browsers can provide polyfills to allow compatibility with code targetting old features that have been dropped. In other words, browsers should be getting smaller (e.g. a canvas, audio stream, input method and language interpreter); more and more functionality should be offloaded into interpreted libraries (parsing, text rendering, DOM, event loops, layout, Javascript, etc.)
    - detaro 8y ago
      Polyfills often are worse (slower, only provide parts of the functionality, ...) than the native implementation provided by newer browsers, so the browser implementation isn't strictly "unneeded".
    - collinmanderson 8y ago
      This _did_ successfully happen with MathML. It was on track to get native browser support, but they decided it the polyfill (mathjax) was good enough and wasn't worth native support for such a niche feature. As a web developer, I much appreciate native features and avoid polyfills as much as possible.
_pmf_ 8y ago
Then I'll be that guy that tells you that including side channels after side channels (WebGL, WebUSB, FileStream), each with byzantine security features haphazardly tacked on, is the actual problem.
pjmlp 8y ago
Linux is another good example how C doesn't cut it, even among top developers. They have a very strict patch review process in place. They have kernel static analysers. The kernel has been adding security gates through the years. Yet 68% of 2018 CVE's were caused by memory corruption bugs, with the others ones left out being UB, numeric conversions, and very tiny fraction remaining of the logic error kind that are bound to happen in any programming language. [1] Just the other day we had a Linux 5.0 pre-release bug caused by a GCC "optimization". Oracle went with hardware memory tagging for Solaris/SPARC, Apple is following along on iOS, Microsoft security advisory (as of Blue Hat conf) is C# + Rust + constrained C++ [2], Google is pushing for hardware memory tagging, Kernel Self Protection Project, constraining what the NDK is allowed to do and Fuchsia is getting more Rust/Go modules by the day. What is clear is that hoping for the best and the mythical 10x developers that write perfect C and C++ code won't ever happen. [1] Source, Google talk at Linux Kernel Summit 2018. [2] Following the Core Guidelines
- Teknoman117 8y ago
  I still wonder what the plans for Fuchsia are. Is Google really thinking about just throwing out the millions of man-years which have been sunk into Linux?
  - lallysingh 8y ago
    The kernel is mostly drivers. If they only support a bit of hardware, they'd be tossing a lot of stuff they don't need.
  - pjmlp 8y ago
    They don't need to please everyone, just make their use case work. Also porting the drivers to Fuschia should be relatively easy, thanks the Treble changes that kind of made their Android Linux kernel into a kind of hybrid-microkernel. Android is already being ported to run on top of Fuchsia. Google isn't the only one, the IoT space is getting crowed with BSD/MIT/Apache POSIX compatible OSes, including Zephyr from Linux Foundation, which is completly unrelated to Linux. 28 years ago no would would believe that Linux distributions would eventually kill commercial UNIX.
dspillett 8y ago
Isn't it more a case of "you have to do everything right to keep the attackers out, they have millions of attempts and only have to get one right once to beat you".
a13n 8y ago
> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. Well, humans can't. And computers can't, yet.
- chriswarbo 8y ago
  > And computers can't, yet. Yes they can. Computers have been writing safe code in various languages for decades: they're called compilers/transpilers. Maybe this is one of those situations where we define AI as "things we don't know how to program yet": we said being good at chess would require intelligence, once computers got good at chess they became 'just tree search'. It sounds like you're imagining that automating programming requires some currently-unknown approach, when others would say it's 'just compiling'. Of course, we need to tell the computer what code to write. We do that using a programming language. It could be the same language (C++), but that seems a bit pointless. Furthermore, since C++ allows unsafe code, using C++ to tell the computer what we want means that we're able to ask for unsafe things (if we want to). That makes the computer's job ambiguous: - Should it always do what it's told, and hence write unsafe code when asked? (In which case, it doesn't solve the "write safe code" task we're talking about) - Should it always write safe code, and hence not always do what it's told? (In which case, where do we draw the line? Would it be valid to ignore all input and always write out `int main() { return 0; }`?) We can avoid this ambiguity if we forbid ourselves from asking for unsafe things. In other words, providing a guarantee about the code that the computer writes is the same as providing that guarantee for the instructions we give it (i.e. the input programming language). For example, if we don't want the computer to ever write memory-unsafe code, that's the same as saying we can't ever tell it to write memory-unsafe code, which is the same as saying that we should instruct it using a memory-safe language. That way, it's possible for a computer to not only write safe C++ in a codebase of arbitrary complexity; but (more importantly) to write safe C++ code that does something we want, and the instructions specifying what we want can be arbitrarily complex.
blub 8y ago
Your claim that Chrome can be used a lesson in choosing programming languages is quite weak, because almost no one will build such a complex application and despite the risk all successful browsers still chose C++. An application that: a) has downloading and executing untrusted code as its main feature b) supports a ton of media formats, with DRM to boot c) is going through rapid changes, including adding very complex low-level features like WebUSB, WebGL or WebAssembly. ... will be insecure by design. It's also very likely that no one will create a browser in C++ again, or in any other language for that matter. Microsoft recently gave up and decided to use Chromium, Opera gave up a long time ago. Chromium itself was forked from WebKit, which is used by Safari. Firefox is the only odd one out, slowly but surely sliding into irrelevance.
- neoromantique 8y ago
  >Firefox is the only odd one out, slowly but surely sliding into irrelevance. That is very false.
  - tapoxi 8y ago
    The highest number I've seen for Firefox's marketshare is 5.8%, which is Wikipedia's metrics: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Summary_tables https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Su...
- sureaboutthis 8y ago
  Your last two sentences have nothing to do with language choice.
- staticassertion 8y ago
  You've missed my point entirely. This is not a plea to Chrome to rewrite their browser. My post has nothing to do with browsers. My claim is that Chrome is an interesting case study in the most hardened user-facing C++ codebase in the world being hacked because of memory unsafety. I also think that the strawman argument you've made is extremely weak for other reasons. This whole "insecure by design" thing is nonsense - everyone stating this seems to not understand that multitenant systems have existed for ages, under far more difficult constraints. An example - AWS Lambdas colocate your code with other companies' on the same hardware - if this were such an impossible task, that wouldn't be possible. But again, my argument is not about browsers, or even much about languages, and is merely me pointing out an interesting case where memory unsafety was the root cause of an attack, despite great efforts.
sureaboutthis 8y ago
> you can't write safe C++ in a codebase this complex. And yet they did. And it worked great for more than a decade. Until just today when someone found...one.
- throwawaymath 8y ago
  A cursory look at Chrome security disclosures shows many memory corruption vulnerabilities. The most recent release fixed twelve use after free vulnerabilities: https://chromereleases.googleblog.com/2019/01/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2019/01/stable-channel.... Go take a look at how many have been found in previous releases.
tha_nose 8y ago
There isn't a "safe or bug free" codebase in any language for any complex software project. The only code that you could possibly verify as "safe" are simplest of programs. There is always a trade-off between complexity, security and performance.
sciurus 8y ago
"Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security." Let's conservatively say Google pays 1,000 developers to work on Chrome, and on average those developers cost Google $300k each. That's $300 million a year just in payroll. Google has invested far more than a billion in Chrome by this point.
- SamBam 8y ago
  I'm amazed. Are there really, "conservatively," 1000 developers working on Chrome full-time, for years? That seems incredibly high to me, but maybe I just don't realize what it takes to build an app like Chrome.
  - krageon 8y ago
    As an estimate I think we can safely say it's not conservative. Especially if this is actually developers (ie straight up coders) and not also all of their supporting personnel.
    - deleted 8y ago
      [deleted]
randomsearch 8y ago
Completely agree. The refusal of us nerds to accept that our tools can be improved and replaced is a broken record that has been playing since the dawn of programming. It reminds me of how assembly programmers rejected high level languages; even with the glaring historical repetition, we are unable to recognise our loyalty to all languages is irrational. It’s patently obvious C/C++ is just a bad choice for many tasks, particularly where security is so important. I’ve never heard someone who works with those languages agree. However - if you’re reading this and feeling vindicated in your particular language choice - be prepared to accept that the language you favour right now is already or will soon be in the same position. That’s progress. Even if you love Haskell or Rust or Scala or Ocaml, if you think it’s anything but a stepping stone in language development then you’re just as wrong as those defending C/C++. As far as programming languages are concerned, we still don’t know what we’re doing. If you have managed to be open minded about languages, then test yourself further by telling yourself that emacs/vim is a local optima and will be superseded by better programming tools, and you should be exploring IDEs and imagining what a world than doesn’t code in plain text could look like. Because typing coding in text form is almost certainly not the best way to write programs, any more than assembler was. Hard to accept, ain’t it?

elorant 8y ago

So what language should they've written it in?

deleted 8y ago
[deleted]
staticassertion 8y ago
A memory safe one. There are many of them. They could build their own if they chose to - they've built multiple languages in the past. Picking a language for the Chrome team doesn't seem practical - we all know where your question is going to head. The point is they have to not pick C++. Again, they've invested many, many millions of dollars into security. Let's not pretend that they're priced out of using another language.
- gpm 8y ago
  It doesn't even have to be memory safe, just less memory accident prone. D for example would have been an interesting choice (and I think it was usable back then).
  - flukus 8y ago
    D was released in 2001, KHTML in 1998, it's like suggesting they should have written vim in java.
    - jlgaddis 8y ago
      ... and Chrome in 2008.
      - jsjohnst 8y ago
        Chrome wasn’t written from scratch in 2008. Chrome was a fork of WebKit, which was a fork of Konqueror, which was a fork of KHTML.
        kolme 8y ago
        KHTML is the rendering engine for the Konqueror browser. Webkit is a fork of KHTML. And Chrome's engine is called Blink (it used to be Webkit, but they forked it).
  - kllrnohj 8y ago
    D would be interesting but it's also not memory-safe. Not strictly. You can restrict yourself to SafeD, but then you're stuck with a GC you don't really want. Or you can tag all your functions as @Safe, but then it's just a "best practice" and you can't do it everywhere because you can't do things like make system calls. D has some interesting bits, but it did a lot of head-scratching stuff too. It seemed really confused about what target it was going after, like some middle ground between C#/Java & C/C++ that really doesn't seem to exist.
- deleted 8y ago
bauerd 8y ago
Use-after-free is ruled out by e.g. Rust's type system
- htfy96 8y ago
  Nope. It's only true when all your code use safe subset/built upon a perfectly correct unsafe base (which is inevitable in a project like Chromium) with correct usage. Otherwise a single misused external call with unsanitized value can ruin all of your security guarantee.
  - Ygg2 8y ago
    Not really. It's been proved that if your unsafe foundations are correct and don't break the rules (i.e. their precondition is correct), then anything safe built on top of that is also correct. Sure you could rely on a C/C++ library that causes problems, but then again you can either: A) fix that library B) replace that part with Rust or even stricter language.
ancarda 8y ago
C++, as that was a reasonable choice in <=2008. Today, perhaps new projects should pick something else (likely Rust). Bits of Firefox are written in Rust, so Chrome could in theory under go the same "oxidation" (gradually replace the C++ code with Rust). Edit: Clarify that Chrome was released in 2008 but was likely in development for some time before that.
- core-questions 8y ago
  > Chrome was released in 2008 but was likely in development for some time before that. Well, sure, didn't it end up taking WebKit from Safari, which was C++, because it came from KDE Konqueror's KHTML?
  - catach 8y ago
    Yes, Chrome was a fork.
- simcop2387 8y ago
  Yes, the KHTML base for the rendering engine was started back in 1998, so C++ was a fine choice then. It's grown up as a code base significantly since then.
TimTheTinker 8y ago
I'll be that guy. :) Rust. (I'm a front-end dev. I have no dog in this fight.)
- asveikau 8y ago
  It's funny how we define terms like "front-end" and assume a specific meaning. A web browser is certainly the front of something.
baby 8y ago
Rust.

peterwwillis 8y ago

No codebase will ever be fully free of security bugs, but having 7 million lines of code definitely doesn't help.

staticassertion 8y ago
The question is, how much effort is it to keep users safe given language X vs C++. Apparently, when the language is C++, the value is somewhere above many millions of dollars, and we don't know what it is. Can we reasonably expect that price to be lower with language X? For many reasons, I would argue 'yes'.
- kllrnohj 8y ago
  Sure, but is your goal maximal safety no matter the cost, or are you trying to strike a balance with other factors? If all you want is to keep users safe then it'd be easy - ban JavaScript wholesale. Bam, done, instantly made the web safer & faster. Don't even need to deal with the huge security can of worms that is WebGL, either. But safety is rarely the exclusive factor in play, now is it? Things like memory usage efficiency & performance also play large roles here.
  - staticassertion 8y ago
    To be clear, I'm not saying "Chrome should be rewritten in a memory safe language", I'm saying that Chrome is an excellent project to point to, say "Wow, no one does as much to secure a codebase as them", and to follow that up with "and they still got owned".
    - kllrnohj 8y ago
      But to what end? Pure-java apps get owned all the time, too. If you look over there you'd just give up on ever trying to transmit data, as the number of Java de-serialization exploits is nothing short of stunning. The only semi-proven way to not get owned at this point is to never go online.

stcredzero 8y ago

Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. Do they distrust their own coders to the same degree they distrust the processes they sandbox? I suspect the answer to this is "no" but I would like to hear from someone who actually codes there. I think the truth is more like this: You can write safe C++, just like you can keep a secret. It's just that the odds that you fail go up with the size of the team involved, and it does that by compounding. So by the time you get to the size of the Google Chrome team, the odds of failure are very, very close to 1.

nothrabannosir 8y ago
The number of people required was a function of the "this complex" qualifier. I can write a safe C++ app on my own. I can't write Chrome on my own.
- Johnny555 8y ago
  I can write a safe C++ app on my own But only if you don't use any external libraries, once you link in someone else's code, you can no longer be sure your program is "safe".
  - stcredzero 8y ago
    once you link in someone else's code, you can no longer be sure your program is "safe" This also fits in with the "keeping a secret" analogy. Good luck keeping something secret, if it has to be shared between organizations.
  - chii 8y ago
    > I can write a safe C++ app on my own >> But only if you don't use any external libraries using an external library is not "on your own"
    - dymk 8y ago
      Can you use the STL? What boundary is considered trusted?

ru999gol 8y ago

if you think C or C++ programmers are ever going to admit this, you must never have met one

monocasa 8y ago
I feel like I can call myself a "C++ programmer"; I was the lead for C++14 RTOS. It's pretty hard to argue with the OP's logic.
ciphergoth 8y ago
What is a C/C++ programmer? I've written fairly large amounts of C/C++ over the course of my career and I continue to do so. I totally concur with this and am eager to see Rust take its place over time.
pjmlp 8y ago
I was mainly a C and C++ developer until 2006 and you will see me praise C++, but also be an heavy critic of the copy-paste security exploits it inherited from C.

flukus 8y ago

> According to the official release notes, this vulnerability involves a memory mismanagement bug in a part of Chrome called FileReader. That’s a programming tool that makes it easy for web developers to pop up menus and dialogs asking you to choose from a list of local files, for example when you want to pick a file to upload or an attachment to add to your webmail. It sounds like the bug occurs interacting with external code, win32 or equivalent. Even if chrome were written in a "safe" language this section would likely be in unsafe block.

pcwalton 8y ago
According to the patch, the problem involves memory management of DOM objects (specifically ArrayBuffers), not objects from native libraries.

bla3 8y ago

If there's ever a project as large as Chrome written in a non-C++ language, I guarantee you it will have these bugs as well -- due to use of `unsafe`, or bugs in the compiler, or what have you.

pcwalton 8y ago
How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one. †I explicitly say "not running arbitrary Java code" to emphasize the difference between this scenario and JS engine vulnerabilities. JS engine vulnerabilities are a problem because JS engines execute untrusted code, but I'm talking about compiler bugs in trusted code that can nevertheless be exploited remotely.
- kllrnohj 8y ago
  > How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one. Seems like an odd restriction to impose here. How many C++ exploitable bugs arose from a C++ compiler bug? I think the answer to that is also zero. Doesn't really seem like a useful thing to consider? But in terms of Java runtime's security it's not particularly stellar. The entire category of "Java deserialization" is the never ending fountain of remotely exploitable security bugs in Java apps that don't run untrusted code.
  - pcwalton 8y ago
    > Seems like an odd restriction to impose here. How many C++ exploitable bugs arose from a C++ compiler bug? I think the answer to that is also zero. Doesn't really seem like a useful thing to consider? Right, and that's why the fact that the Rust compiler has bugs is irrelevant. The language is meaningfully more memory-safe than C++. > But in terms of Java runtime's security it's not particularly stellar. The entire category of "Java deserialization" is the never ending fountain of remotely exploitable security bugs in Java apps that don't run untrusted code. Java deserialization RCEs, while pernicious, are nowhere near as common as use-after-free and related bugs in C++ code. Furthermore, you can effectively mitigate them by statically banning OutputObjectStream and whatnot. There's no such easy foolproof static mitigation available for C++ UAF.

nitwit005 8y ago

In a general sense, I'd agree, but from the description in that article, it's interaction with native files or file dialogs. Even if you use Java, you're susceptible to this sort of bug, because your Java code calls into layer of C code to handle the native interaction. Realistically, any browser is probably going to have a decent amount of unsafe code surrounding the native windowing, files, graphics, and so on.

pcwalton 8y ago
Look at the patch; it's a use-after-free bug involving DOMArrayBuffer and ArrayBuffer, which are Chrome objects, not native OS objects.

deleted 8y ago

[deleted]

baby 8y ago

Hence why it is freaking amazing to follow what Firefox is doing with Rust.

wahern 8y ago

Without knowing more there's zero reason to blame C++. This looks like it implicates (a) a questionable but quite intentional performance optimization and (b) possibly a V8 GC race or otherwise an issue with reference consistency between the C++ code and the JIT'd JavaScript runtime. Both of those issues would exist regardless of the language chosen--D, Erlang, Java, Python, Rust, w'ever. Remove V8's JIT and GC and then one can have a meaningful discussion about memory safe languages. But remove those and the vast majority of Chrome bugs would also disappear. Those are the places of highest complexity while also being the areas which no language offers any meaningful assistance. And this is why I think it's crazy that the WebAssembly folks are dead set on a specification that presumes and requires tight, direct object bindings between the host and the WebAssembly VM, particularly wrt JavaScript GC integration, as opposed to using indirect references with a clear contract that employ proxy objects for anchoring--in effect a sort of runtime sandboxing which falls short of IPC but which substantially circumscribes system complexity (e.g. invisible data dependencies) and substantially preserves the ability for memory-safe host languages (compilers and runtimes) to meaningfully ensure their invariants. What we need more than yet another memory-safe language is the motivation and experience in multi-language integration. What we're getting are another generation of programmers recapitulating many unforced errors. Memory-safe languages aren't new. Nor are memory-safe and ergonomic languages. Nor is, for that matter, the thinking that one can throw a single language at a complex problem despite the entire history of computer science being an unending parade of new languages and optimization models with poor integration stories. Bare C FFI is only the most minimal and easiest requirement to get correct when it comes to integration. There's so much more to the problem.

staticassertion 8y ago
> there's zero reason to blame C++ Seems like UAF in C++? So, yes, I feel comfortable blaming C++. Anyways, I didn't mention memory safe languages in my post, and I'm not even suggesting that Google did anything wrong, or should change their posture in any way. They've been extremely successful.
- wahern 8y ago
  UAF by whom? If it's through a bare reference held in the JavaScript VM where operations don't access the C++ object as a C++ object or as some shared primitive object as in the JVM or CLR, then the error is in maintaining state consistency across distinct environments. Such bugs look exactly the same in every language, although the risk is compounded by (a) JIT'd environments and (b) asynchronous execution. In the context of a bug involving JavaScript ArrayBuffers (where JIT compilers are designed to optimize away both FFI accessors and bounds checks) and asynchronous events I think it would be prudent to withhold judgment.

zrm 8y ago

> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. And so, as they say, we should all be using Rust. But allow me to explain why I don't yet. Rust has one really outstanding feature -- a borrower checker that makes it memory safe. Adding that to C++ would be a compatibility-breaking change. So then, while they were at it, they changed lots of other things. It's a whole different language, separate syntax, generics that work differently than templates, different standard library, etc. This interacts with the finite amount of time I have to learn a new language, making it take longer before I feel proficient enough in it to start using it for real work. Sufficiently long that the day that I do is still in the future. I understand the desire to make changes. Many of the changes are improvements, and C++ can be ugly. But it's the devil we know. A version of it with the minimum necessary changes to add a borrow checker would have me using it already, and I expect I am not the only such person.

sanxiyn 8y ago
Different standard library is kind of unavoidable because you need standard library interface understood by borrow checker.
- zrm 8y ago
  That's the compatibility-breaking part. Doesn't mean the replacement function or object can't have the same name, purpose, time complexity, etc. You could potentially even continue to support the existing ones but regard them as unsafe and have the compiler warn if they're used.
- pjmlp 8y ago
  Microsoft already does that with their SAL annotations. https://docs.microsoft.com/en-us/visualstudio/code-quality/using-sal-annotations-to-reduce-c-cpp-code-defects?view=vs-2015 https://docs.microsoft.com/en-us/visualstudio/code-quality/u... Which they are extending to also support their C++ lifetime checker.
duneroadrunner 8y ago
They are working on it. The analogue to the borrow checker in C++ is called the "lifetime profile checker" and (an incomplete version) is included in MS Visual C++, but last time I checked (in January) it seemed to still have too many false positives to be practical. In the mean time, I think "the minimum necessary changes" to achieve memory and data race safety is to replace all your unsafe C++ elements (pointers, arrays, vectors, string_views, etc.) with compatible substitutes from the SaferCPlusPlus library [1]. You don't even need to replace them all at once. You can replace them incrementally and your code will continue to compile and run throughout the process. And where needed, maintain maximal performance as well [2]. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksGame https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

euske 8y ago

I think it's a time that we should get rid of this notion of "perfectly safe code in the perfect world". It might be possible if the code doesn't change for million years, but that's not how the world works - things keep changing, the specs, the requirements and the users. Bugs are created every day. It's not about safety as a static property, but it is about the safety in an ever-changing world. As Bruce Schneier put it, it's a process. And yes, C++ might be bad for it, but that's only a part of the whole picture. We should look at the process rather then the code itself.

kasey_junk 8y ago
The OP’s entire point is that effectively no one has looked at the whole process in a more robust way than the Google Chrome team. They are literally at the vanguard of that issue, yet they got owned up by a well known code problem.

zetafunction 8y ago

> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. I work on Chrome. The working assumption is there always exists a bug that allows remote code execution in the renderer.

gsich 8y ago
Slightly OT: revert the ugly design introduced in Chrome 71 (or 70).
nneonneo 8y ago
So what happened here? There's an in-the-wild exploit that's bypassing sandboxing - so there must be at least two bugs, or the sandbox isn't tight enough (which, for Chrome, would surprise the hell out of me).
- aboodman 8y ago
  I used to work on Chrome. There have been periodic sandbox escapes, and chained exploits that escape to userland are routinely performed at pwn2own. This is just notable because there is a live exploit in the wild.
  - GordonAitchJay 8y ago
    There there any public information about what the live exploit does?
- intherdfield 8y ago
  "The second vulnerability was in Microsoft Windows. It is a local privilege escalation in the Windows win32k.sys kernel driver that can be used as a security sandbox escape." https://security.googleblog.com/2019/03/disclosing-vulnerabilities-to-protect.html https://security.googleblog.com/2019/03/disclosing-vulnerabi...
LukeB42 8y ago
Bad time to ask for browser extensions on mobile then?

fooker 8y ago

That's a weird and dishonest point to make here. You can't write safe $ANYTHING for a codebase this complex. I am yet to see someone who has worked on a codebase this complex disagree. Security issues and crashes in general result from your program interacting with the outside world and something behaving in a way you did not account for.

throwawaymath 8y ago
What’s dishonest? No one has said language choice is a silver bullet for all classes of security vulnerabilities. The point under contention is that we have better options for memory corruption vulnerabilities in particular. In other words we’re not talking about whether or not something will be totally safe, but rather safer. Perfect is the enemy of good.

scoutt 8y ago

Is there an official explanation of the kind of bug? I cannot find it. "Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex." Pointing the finger and saying "see?" is a pretty low quality argument. So, I guess we should wait for the first Rust or managed language remote exploit (or whatever) to say "admit it, finally - you can't write safe... programs?".

apta 8y ago
Managed languages remove an entire class of exploits present in C and C++ programs. That alone is a very good start.

Grue3 8y ago

The real problem is that the web is now too complex to the point that it's impossible to safely implement it. And W3C keeps trying to add new features to it. At some point we have to stop and consider whether all this cruft is even necessary.

sanxiyn 8y ago
Of course all the cruft is necessary due to compatibility. (Browsers monitor usage statistics and do remove crufts when possible.)
- chriswarbo 8y ago
  "Polyfills" are quite common in Web development, and are also proof that browsers do a whole bunch of unneeded stuff (if it were needed, there would be no way to polyfill it). I actually think polyfill usage is backwards: the current approach allows code targetting new features to be made compatible with old browsers, by the site providing polyfills. I think it's much better for new browsers to be leaner, simpler and more well-thought-out than their predecessors. Such browsers can provide polyfills to allow compatibility with code targetting old features that have been dropped. In other words, browsers should be getting smaller (e.g. a canvas, audio stream, input method and language interpreter); more and more functionality should be offloaded into interpreted libraries (parsing, text rendering, DOM, event loops, layout, Javascript, etc.)
  - detaro 8y ago
    Polyfills often are worse (slower, only provide parts of the functionality, ...) than the native implementation provided by newer browsers, so the browser implementation isn't strictly "unneeded".
  - collinmanderson 8y ago
    This _did_ successfully happen with MathML. It was on track to get native browser support, but they decided it the polyfill (mathjax) was good enough and wasn't worth native support for such a niche feature. As a web developer, I much appreciate native features and avoid polyfills as much as possible.

_pmf_ 8y ago

Then I'll be that guy that tells you that including side channels after side channels (WebGL, WebUSB, FileStream), each with byzantine security features haphazardly tacked on, is the actual problem.

pjmlp 8y ago

Linux is another good example how C doesn't cut it, even among top developers. They have a very strict patch review process in place. They have kernel static analysers. The kernel has been adding security gates through the years. Yet 68% of 2018 CVE's were caused by memory corruption bugs, with the others ones left out being UB, numeric conversions, and very tiny fraction remaining of the logic error kind that are bound to happen in any programming language. [1] Just the other day we had a Linux 5.0 pre-release bug caused by a GCC "optimization". Oracle went with hardware memory tagging for Solaris/SPARC, Apple is following along on iOS, Microsoft security advisory (as of Blue Hat conf) is C# + Rust + constrained C++ [2], Google is pushing for hardware memory tagging, Kernel Self Protection Project, constraining what the NDK is allowed to do and Fuchsia is getting more Rust/Go modules by the day. What is clear is that hoping for the best and the mythical 10x developers that write perfect C and C++ code won't ever happen. [1] Source, Google talk at Linux Kernel Summit 2018. [2] Following the Core Guidelines

Teknoman117 8y ago
I still wonder what the plans for Fuchsia are. Is Google really thinking about just throwing out the millions of man-years which have been sunk into Linux?
- lallysingh 8y ago
  The kernel is mostly drivers. If they only support a bit of hardware, they'd be tossing a lot of stuff they don't need.
- pjmlp 8y ago
  They don't need to please everyone, just make their use case work. Also porting the drivers to Fuschia should be relatively easy, thanks the Treble changes that kind of made their Android Linux kernel into a kind of hybrid-microkernel. Android is already being ported to run on top of Fuchsia. Google isn't the only one, the IoT space is getting crowed with BSD/MIT/Apache POSIX compatible OSes, including Zephyr from Linux Foundation, which is completly unrelated to Linux. 28 years ago no would would believe that Linux distributions would eventually kill commercial UNIX.

dspillett 8y ago

Isn't it more a case of "you have to do everything right to keep the attackers out, they have millions of attempts and only have to get one right once to beat you".

a13n 8y ago

> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. Well, humans can't. And computers can't, yet.

chriswarbo 8y ago
> And computers can't, yet. Yes they can. Computers have been writing safe code in various languages for decades: they're called compilers/transpilers. Maybe this is one of those situations where we define AI as "things we don't know how to program yet": we said being good at chess would require intelligence, once computers got good at chess they became 'just tree search'. It sounds like you're imagining that automating programming requires some currently-unknown approach, when others would say it's 'just compiling'. Of course, we need to tell the computer what code to write. We do that using a programming language. It could be the same language (C++), but that seems a bit pointless. Furthermore, since C++ allows unsafe code, using C++ to tell the computer what we want means that we're able to ask for unsafe things (if we want to). That makes the computer's job ambiguous: - Should it always do what it's told, and hence write unsafe code when asked? (In which case, it doesn't solve the "write safe code" task we're talking about) - Should it always write safe code, and hence not always do what it's told? (In which case, where do we draw the line? Would it be valid to ignore all input and always write out `int main() { return 0; }`?) We can avoid this ambiguity if we forbid ourselves from asking for unsafe things. In other words, providing a guarantee about the code that the computer writes is the same as providing that guarantee for the instructions we give it (i.e. the input programming language). For example, if we don't want the computer to ever write memory-unsafe code, that's the same as saying we can't ever tell it to write memory-unsafe code, which is the same as saying that we should instruct it using a memory-safe language. That way, it's possible for a computer to not only write safe C++ in a codebase of arbitrary complexity; but (more importantly) to write safe C++ code that does something we want, and the instructions specifying what we want can be arbitrarily complex.

blub 8y ago

Your claim that Chrome can be used a lesson in choosing programming languages is quite weak, because almost no one will build such a complex application and despite the risk all successful browsers still chose C++. An application that: a) has downloading and executing untrusted code as its main feature b) supports a ton of media formats, with DRM to boot c) is going through rapid changes, including adding very complex low-level features like WebUSB, WebGL or WebAssembly. ... will be insecure by design. It's also very likely that no one will create a browser in C++ again, or in any other language for that matter. Microsoft recently gave up and decided to use Chromium, Opera gave up a long time ago. Chromium itself was forked from WebKit, which is used by Safari. Firefox is the only odd one out, slowly but surely sliding into irrelevance.

neoromantique 8y ago
>Firefox is the only odd one out, slowly but surely sliding into irrelevance. That is very false.
- tapoxi 8y ago
  The highest number I've seen for Firefox's marketshare is 5.8%, which is Wikipedia's metrics: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Summary_tables https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Su...
sureaboutthis 8y ago
Your last two sentences have nothing to do with language choice.
staticassertion 8y ago
You've missed my point entirely. This is not a plea to Chrome to rewrite their browser. My post has nothing to do with browsers. My claim is that Chrome is an interesting case study in the most hardened user-facing C++ codebase in the world being hacked because of memory unsafety. I also think that the strawman argument you've made is extremely weak for other reasons. This whole "insecure by design" thing is nonsense - everyone stating this seems to not understand that multitenant systems have existed for ages, under far more difficult constraints. An example - AWS Lambdas colocate your code with other companies' on the same hardware - if this were such an impossible task, that wouldn't be possible. But again, my argument is not about browsers, or even much about languages, and is merely me pointing out an interesting case where memory unsafety was the root cause of an attack, despite great efforts.

sureaboutthis 8y ago

> you can't write safe C++ in a codebase this complex. And yet they did. And it worked great for more than a decade. Until just today when someone found...one.

throwawaymath 8y ago
A cursory look at Chrome security disclosures shows many memory corruption vulnerabilities. The most recent release fixed twelve use after free vulnerabilities: https://chromereleases.googleblog.com/2019/01/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2019/01/stable-channel.... Go take a look at how many have been found in previous releases.

tha_nose 8y ago

There isn't a "safe or bug free" codebase in any language for any complex software project. The only code that you could possibly verify as "safe" are simplest of programs. There is always a trade-off between complexity, security and performance.

sciurus 8y ago

"Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security." Let's conservatively say Google pays 1,000 developers to work on Chrome, and on average those developers cost Google $300k each. That's $300 million a year just in payroll. Google has invested far more than a billion in Chrome by this point.

SamBam 8y ago
I'm amazed. Are there really, "conservatively," 1000 developers working on Chrome full-time, for years? That seems incredibly high to me, but maybe I just don't realize what it takes to build an app like Chrome.
- krageon 8y ago
  As an estimate I think we can safely say it's not conservative. Especially if this is actually developers (ie straight up coders) and not also all of their supporting personnel.
  - deleted 8y ago
    [deleted]

randomsearch 8y ago

Completely agree. The refusal of us nerds to accept that our tools can be improved and replaced is a broken record that has been playing since the dawn of programming. It reminds me of how assembly programmers rejected high level languages; even with the glaring historical repetition, we are unable to recognise our loyalty to all languages is irrational. It’s patently obvious C/C++ is just a bad choice for many tasks, particularly where security is so important. I’ve never heard someone who works with those languages agree. However - if you’re reading this and feeling vindicated in your particular language choice - be prepared to accept that the language you favour right now is already or will soon be in the same position. That’s progress. Even if you love Haskell or Rust or Scala or Ocaml, if you think it’s anything but a stepping stone in language development then you’re just as wrong as those defending C/C++. As far as programming languages are concerned, we still don’t know what we’re doing. If you have managed to be open minded about languages, then test yourself further by telling yourself that emacs/vim is a local optima and will be superseded by better programming tools, and you should be exploring IDEs and imagining what a world than doesn’t code in plain text could look like. Because typing coding in text form is almost certainly not the best way to write programs, any more than assembler was. Hard to accept, ain’t it?