28 ms·

Chromium project finds that 70% of security defects are memory safety problems

467 points by solarengineer 6y ago

Barrin92 6y ago
Reminded me of an article I read last year (https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...) Interestingly enough Microsoft arrived at the same number. I think it really stresses how hard it is to reason about memory manually. I'm still surprised how much stuff is being written in non-safe languages even if people could get away with a managed language. One thing that I just recently noticed when scrolling through some github repos is how much new software in the linux ecosystem is still written in C despite it being probably avoidable, like flatpak.
- ackbar03 6y ago
  I get the feeling it's because it's impossible to get away without using c for low level high performance stuff
  - saagarjha 6y ago
    As Rust shows, it’s not really impossible from a technical standpoint in many areas. The issues are more to do with convention and legacy and familiarity, for the most part. (Technically, C does have a couple of advantages: it’s stable, familiar, and extremely well supported in most places, and has basically had the world revolve around it for a couple decades at least. But there are a number of domains where these are surmountable.)
    - CameronNemo 6y ago
      C is also much better at dynamically linking, and results in much smaller binaries. Still not good justification for flatpak. Or crun (the reimplementation of runc in C) for that matter. The Red Hat crew has a problem with their reliance on C, Python, and Go. They need something like Rust (or even Vala, which does ARC from what I can tell) in their arsenal.
      - boccko 6y ago
        It's rather easy to dynamically link something that's not polymorphic.
      - eptcyka 6y ago
        What exactly is the issue with Rust and dynamic linking? Is it that it can't dynamically load Rust interfaces? There's nothing wrong with linking plain old symbols from shared objects in Rust.
        adev_ 6y ago
        Rust has no stable ABI contrary to C and also support much higher concept like polymorphism or high order functions which are much harder to represent in a simple ABI. Real dynamic linking on that (dlopen-style) can be a real nightmare, specially between compiler versions. You can also add that Rust do not have a runtime, which is in many cases an advantage, but also tend to make libraries bigger.
        Groxx 6y ago
        Similar to C++ though, e.g. explosions of template expansions, you don't have to use those higher-level and harder-to-keep-concise features. Other fancy languages have stable ABIs, it's not impossible, nor does it require that it's complex to use. Though the average one is probably harder, yes. I'd wager that it's mostly lack of care or motivation though, made a bit worse by common language features.
        adev_ 6y ago
        > Similar to C++ though, e.g. explosions of template expansions, you don't have to use those higher-level and harder-to-keep-concise features. C++ has a stable ABI. Fragile, but stable. Or doing things like updating libQt on your Linux distribution without recompiling half of the world would be close to impossible :)
        6y ago
  - lmm 6y ago
    It's not, people are just incapable of making realistic assessments of what level of performance they require. If you're using C or C++ "for performance" and not using a profiler in day-to-day development, you don't need to be using C or C++ and should be using a memory-safe language instead.
    - throwaway17_17 6y ago
      I will agree in part, if you aren’t using C or C++ in performance critical software you probably could use another language. I think your profiler-every-day requirement is, maybe, a tiny bit too restrictive, but not by much. There is certainly a need for the industry (and hobbyists) to take stock of both what is necessary and what is just desired. I just don’t want to see the bar for using a language that doesn’t handle all aspects of memory usage and performance to be restricted to soft real-time applications and infrastructure projects. Digging into low level programming can be fun and rewarding. My problem is essentially that even if I am not absolutely concerned with maximum performance across memory usage, binary size, CPU efficiency, bandwidth, etc. I still truly enjoy the options for control (or the illusion of it) that is provided by C. I enjoy memory layout design, allocator design, cache-efficiency considerations and the like; while at the same time, I don’t have a huge love of malloc and free or having to track down segfaults. I think ‘performance-by-default’ is a viable language design goal and want more of it in my tools. I keep posting comments mentioning my pet language project, mostly in hopes that when I see it on my threads display I can continue to shame myself into getting it released on time, and this is one of those. These kinds of concerns motivated me to design a language for personal use that gives me what I want, but doesn’t require (but can) allow me to deal with other things. I enjoy using Coq, Haskell, Idris, Lisp, ATS, and Clean. But those language deprive me of things I really do enjoy. So I’m going for a low level language (in the Perlis sense) that has an experimental type theory. This will certainly allow for a memory safe subset and is the kind of thing I want to see more of from others.
    - danielscrubs 6y ago
      "Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware is becoming faster. The adage is named after Niklaus Wirth, who discussed it in his 1995 article "A Plea for Lean Software".[1][2]" We could do better languages. But it just takes insane resources to compete with the others ecosystem. IDE's, the Pandas, the format on save. I've been a professional C++-developer in the past and one of the great things is the tooling and the just sheer knowledge of my past C++ colleagues. They know what happens in the kernel, they know the performance optimisation tricks, they know a lot, because the knowledge they gather just have a longer lifespan. Ask a JS-developer and they will tell you all the web frameworks that came before React and their quirks...
- keithwinstein 6y ago
  You know, I totally buy that 70% of the vulnerabilities in complex C++ code relate to memory safety, especially in something like Chromium, which is incredibly complex and includes a lot of third-party code that wasn't always designed at first to be robust to untrusted input, and also fast-moving with a ton of code added or churning every week. But I'm not sure I buy that memory-safe languages will consequently be as beneficial for safety (especially in other kinds of software) as that fact would suggest. For one, not all software is like Chromium. If you look at something like OpenSSH, the vast majority of their security holes have nothing to do with memory safety and are just logic bugs (often caused by features that somebody added that aren't core to the basic SSH experience, e.g. code that interfaces with X11 or something) or protocol weaknesses. (http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh) The other effect is that in practice, memory-safe languages can come with security baggage of their own. If you look at the zillions of security holes in something like Rails or Wordpress or Django, a fair portion of them relate to an attacker's ability to invoke sophisticated-but-unintended behaviors that are more likely to be hiding in these managed languages (and their support libraries) than in something like C++. E.g. CVE-2013-0156 or CVE-2013-0277 or apparently any current Python or Ruby program that, even today, calls yaml.load on untrusted input. That kind of "security hole from unwanted latent functionality" is less likely to exist in C++. (I realize this is a contrarian view not shared by the vast majority of PL/security experts, but the ones I hang out with seem to interpret "memory-safe language" to mean "expert-written Haskell or, if you want to slum it, Rust" and are not thinking "random Ruby/Python/JavaScript/enterprise Java".) Not to mention the countless high-profile security holes that have nothing to do with memory safety, e.g. Shellshock, "goto fail", Lucky Thirteen, BEAST, CRIME, POODLE, FREAK, Logjam, etc. Or bugs that are very relevant to Chromium but aren't really Chromium's fault and probably don't appear on their own list, e.g. Meltdown/Spectre etc.
  - saagarjha 6y ago
    Yes, it is important to note that switching to a memory safe language does not magically solve all your bugs. My own personal anecdote: when I found multiple bypasses in the sandboxing mechanism on macOS, it was not because the relevant code was written in C++, but because the dynamic linker is a really complex system; the things I found clearly flew under the engineer’s radar when they were designing it and they didn’t think beforehand about how those components interacted together. Still, being able to reduce the attack surface area to solely be logic errors is much better than having to deal with memory safety thrown in as well. (Similarly, languages with stricter type systems magically get rid of issues like “you gave me a string and I wanted an int”, but the problems of “you forgot to check the password in this one case” still remain.)
- msla 6y ago
  The problem with memory management is a problem with lifetime management, which Rust reasons about in terms of ownership management, which it attempts to reason about statically, with help from the programmer. GC attempts to do the same thing, dynamically, with less help from the programmer. Both of those methods still allow leaks, which is why Rust encourages RAII. [1] Are there other structured lifetimes we can get compilers to enforce for us, like they enforce certain invariants about flow control using control structures? [1] https://users.rust-lang.org/t/memory-leaks-in-rust/18187/2 https://users.rust-lang.org/t/memory-leaks-in-rust/18187/2 http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-safe/ http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-... https://doc.rust-lang.org/nomicon/leaking.html https://doc.rust-lang.org/nomicon/leaking.html
- dependenttypes 6y ago
  > I'm still surprised how much stuff is being written in non-safe languages even if people could get away with a managed language. The distinction between unsafe and managed languages does not make any sense. You can for example have a safe C implementation. No need to move to another language.
  - doomjunky 6y ago
    But in managed languages the safety comes by default and in unmanaged languages the safety comes by exception.
    - dependenttypes 6y ago
      In both ways safety comes by the implementation. It just so happens that so called "safe" languages tend to have a single safe implementation while "unsafe" ones tend to have multiple unsafe and one or two safe ones. Does the amount of unsafe implementations matter?
- mister_hn 6y ago
  Just imagine that SQLite is written in C and the major of bugs are logical/optimization ones, not related to memory management. And when talking about C++, since 2011 there are smart pointers to help developers managing memory kind of automatically. I believe most of the problems are due the people typing on those keyboards such bad code, especially when it comes to "smart" code. In 2020 we have plenty of tools supporting the developer job (memory sanitizers, static analysis tools, linting, profilers, etc.): The big problem is failing to / ignoring to use such tools.
  - saagarjha 6y ago
    Chrome is a heavy user of such tools and has many talented engineers working on it.
    - aylp 6y ago
      Citation needed. I never see the same level of dedication in big Google or Facebook projects as in well run smaller projects like SQLite. You are directly rewarded for "new" features (i.e. plagiarizing or rewriting old ones and selling them as new). So I don't think the engineers are particularly talented, and the incentives are not the same as for SQLite.
      - ReactiveJelly 6y ago
        If using Rust results in fewer bugs for less money, shouldn't we still do it? The reason SQLite can test so thoroughly is that their requirements never change. I have tried to browse the web with SQLite but so far no luck.
        alpp 6y ago
        If one has to deal with boring Rust zealots all day, the answer is no.
  - boccko 6y ago
    Do you think issue at google is not knowing about/not using the proper tools?
- kungtotte 6y ago
  C on Unix-like systems isn't so surprising. The K&R book devotes a large section to the Unix system interface for example, the Linux kernel is one of the biggest C projects in the world, and even when using a higher level language to write your programs you're ultimately calling into libc or wrapping other C libraries or syscalls. It's a case of "When in Rome, do as the Romans do".
- sseth 6y ago
  The "Rule of 2" link in the article actually says this : "A recent study by Matt Miller from Microsoft Security states that “~70% of the vulnerabilities addressed through a security update each year continue to be memory safety issues”.
dstaley 6y ago
Not to be snarky, but my initial response to this was "Large project that uses language known for memory safety issues discovers that most of their security bugs stem from memory safety issues". In a more serious note, I hope this motivates the Chromium team to invest more in Rust. While the other options sound like good "in the meantime" solutions, switching to a language that, at its core, is designed to prevent these sorts of issues would be a huge benefit to society as a whole considering that Chromium is the most popular browser engine in the world.
- rosstex 6y ago
  70% of security defects in memory-safe languages are probably also memory safety problems.
  - _bxg1 6y ago
    That doesn't make any sense at all
    - robobro 6y ago
      The world doesn't make sense. That's why we humans suffer.
    - rosstex 6y ago
      please laugh i'm trying my best
      - antonvs 6y ago
        70% of all failed jokes on HN were best efforts. But not this one.
        nullc 6y ago
        70% of all failed jokes on HN are due to memory safety problems.
mkj 6y ago
To me it seems likely the percentage is even higher in other programs - a web browser has a pretty complicated privacy/isolation model compared with most other programs so that increases the 23.9% "Other" here. Normal "logic" bugs would be more likely to have security implications.
jariel 6y ago
Question to C++ pros: are there not idioms that can be used and ruthlessly enforced to avoid such problems entirely? Is this the result of 'open use of pointers' that inevitably causes problems here and there? Or is this problem due to the fact is just impossible to use even hard idioms to avoid such problems? (Or hard to enforce them?) On some small-to-midsized projects I've seen narrow and rigorously enforced rules around pointers that seemed to work well. So what's up?
- necubi 6y ago
  If you try to strictly enforce memory safety in C++, you end up with code that looks a lot like Rust. But the Rust compiler will fail to compile code that has memory-safety issues (outside of unsafe blocks), while your C++ compiler will happily ignore them.
  - jandrewrogers 6y ago
    The challenge is that the Rust compiler will fail to compile many codes that are strictly and provably memory safe but fall outside Rust’s narrow model of “memory safe”, and which are required for performance reasons. You’d have to wrap most of the code in unsafe blocks. In C++17 you can directly write type infrastructure that transparently enforces memory safety models that Rust doesn’t grok, which is a pretty nice feature. Many people underestimate what is possible using C++ these days. Complex for sure, but also very powerful.
    - kelnos 6y ago
      > Many people underestimate what is possible using C++ these days. Complex for sure, but also very powerful. And that's the problem. There are very few true C++ experts, and most people will run into these issues as a matter of course. This just feels like a reduction to the usual: if you are perfect, you will write perfect code, and never have memory-safety bugs. Thanks, but I'm not perfect, and I'd rather write in a language with a compiler that rejects programs with memory-safety bugs. And yes, that does mean sometimes it'll reject some programs that are perfectly ok, but the Rust borrow checker is getting better all the time, and sometimes you just have to accept being hamstrung a little for the greater good.
Animats 6y ago
And that's new code, not legacy. Embarrassing. I would have expected better from something written in this century. C++ does sort of have a safe subset. If you're passing raw pointers all over the place today, you're doing it wrong.
- fabrice_d 6y ago
  "sort of" is the key. If the language doesn't prevent you from shooting yourself in the foot, on any large project bad things will happen. Safer languages are better tools because they make obvious when you're stepping out of the safe zone, which is not the case with C++, even modern releases.
- _se 6y ago
  Passing raw (non-owning) pointers is fine, even if references would be better. Heap allocating with new instead of a smart pointer is the problem.
  - zetafunction 6y ago
    Non-owning pointers are absolutely a problem if the object graph is large and complex enough. Many objects in Chromium have lifetimes managed by smart pointers, but unfortunately, that doesn't do anything to protect against code that mistakenly violates an invariant like "object X must always outlive Y due to these non-owning pointers". The problem is C++ turns a violation of lifetime invariants into undefined behavior rather than safely crashing.
- scarmig 6y ago
  At some point, the idea that a tool is fine, it's just that everyone is using it wrong starts to become a reason to look for alternatives to the tool. Chromium is a large cpp project, with lots of resources behind it, but people still fail to write safe code for it. There are small bore efforts that can be done to tangibly improve things, but in the end it seems like the real solution is to start writing components in a language that offers better memory safety and maintains high performance. That is a huge, risky effort as well, of course.
- 6y ago
sumanthvepa 6y ago
C++ can be used safely without memory safety issues. But it requires expertise with the language, which is a very steep barrier for most programmers, even ones on the Chrome team to pass successfully. In a project as large as Chrome the vast majority of programmers will not have the necessary expertise. And sadly, in this case, what you don't know will hurt you. Is that a reason for not using C++: maybe. But you would be hard pressed to find a more performant language that is mature and stable.
- saagarjha 6y ago
  Even the best software engineers make memory safety mistakes.
- summerlight 6y ago
  No, even world-class C++ experts can and will make subtle memory safety bugs across abstraction boundaries. Think about millions of lines of C++ codes which have their own assumptions on invariant and contract. Their time is a limited resource and for many cases memory safety is not the most valuable thing to put their efforts.
- kbumsik 6y ago
  > In a project as large as Chrome the vast majority of programmers will not have the necessary expertise. Wait, then what kind of devs would have enough expertise?
- nindalf 6y ago
  We need to let go of this idea that there are godlike engineers out there who can write perfect code. Everyone makes mistakes. As long as the compiler allows it, such mistakes will continue to happen. > in a project as large as Chrome the vast majority of programmers will not have the necessary expertise. Then how do we staff such projects? Hire only people with a track record of never writing such bugs? It’s not possible.
- phkahler 6y ago
  There is a big difference between "theoretically C++ could be written safely" and "Rust is safe."
rb808 6y ago
I gave up C++ 10 years ago and switched to more modern languages. I figured the language would die off, so am a bit shocked its still so prevalent. I really dont think there is any reason to use C or C++ any more, except perhaps some low level layer that interacts with the hardware.
- dmortin 6y ago
  Even if C++ is used less than before it won't die off and C++ experts can demand more money especially because there are fewer of them as most programmers move to more modern languages.
  - lsofzz 6y ago
    COBOL
    - dmortin 6y ago
      Yep, the same case. Only I read that those old COBOL programs are a huge mess of spaghetti code, so you are well paid, but you have to put up with ugly, hard to maintain code. I'd rather work on something nicer for less money.
- pjmlp 6y ago
  Depending on which domains you are it is still unavoidable. For example, I hardly do any C++ nowadays, it is however what I get to use to integrate with OS native libraries and GPGPU shaders.
- jve 6y ago
  Even if there are 0 lines of code written in C from now on, existing codebase (huge) still has to be maintained. C wont be dead in our lifetime. Rewriting everything is also not an option. Imagine rebuilding your house with modern materials, because old ones may have some shortcomings. Who will pay for that?
foobar_ 6y ago
Can't we just enable bounds checking and gc and live with slowness. Shouldn't that be a choice, a compiler flag ? Every time there is a security issue, someone can see your naked pictures.
- _ph_ 6y ago
  Neither automatic bounds checking nor GC really add slowness. Any reasonably safe program will check the bounds explicitly, so there is no speed gained vs. guaranteed bounds checking via the compiler. Actually any good compiler can remove most bounds checks, if it can proove that the access is in bounds. Also GC can be quite faster than manual dynamic memory management.
- GordonS 6y ago
  Do you know of any fully-featured Web browsers that have been implemented with "safe" language, such as C# or Java? Would be a really interesting project to see!
  - _ph_ 6y ago
    Very early on, Sun had a web browser implemented in Java. Unfortunately, this was dropped before Java got Hotspot and with that the decisive speed up. (They also had a web server implemented in Java, which sounds like an excellent idea too)
- zetafunction 6y ago
  There's actually been quite a bit of work to bounds check accesses for containers implemented inside Chromium, such as span and optional, but it's harder to get these checks into upstream libc++. GC is one way to reduce the number of memory safety issues, but there are often tricky interactions between GC and non-GC code. Another issue with GC is it's often much harder to reason about object lifetimes.
m463 6y ago
What if with "dangerous languages" like C you could turn off pointers, or make only functional subroutines? For instance, perl has this construct, to make your programs better: a program foo.pl: $c = 1; runs fine. Now turn on strict: use strict; $c = 1; and $ perl ./foo.pl Global symbol "$c" requires explicit package name at ./foo.pl line 2. Execution of ./foo.pl aborted due to compilation errors. you must declare $c: my $c = 1; the idea would be... write your program and you can opt-in to various constructs. NOTE: my first example didnt' work. use strict; $a = 1; won't throw an error. Turns out the variables "$a" and "$b" are exempt from "use strict;" ha. wow.
- scarmig 6y ago
  `use stricter;` is the obvious solution.
- snicker7 6y ago
  Not being allowed to use pointers means not having control of memory layout.
  - m463 6y ago
    the idea would be routine by routine you could turn on features. So make this function functional with no side effects. This function doesn't (overtly) use pointers. etc... At various jobs, we've done things like this with warnings. Get a source file to compile warning free, then turn on -Werror (this is done via compile flags, a different mechanism)
- lmm 6y ago
  You have to be very careful that the looser language doesn't break the rules that the stricter language relies on. Have a look at the Noether design for a serious effort at doing this kind of stratified language.
- raverbashing 6y ago
  > What if with "dangerous languages" like C you could turn off pointers You can't. C is a fundamentally defective language because it doesn't have the "memory slice"/"array" construct. Of course you can work around it, but if you eliminate pointers then you can't do much with C. Heck you can't even print "Hello World" with it (well, ok, technically you can but not in the usual way).
phillipcarter 6y ago
Why haven't they just started to rewrite it in rust yet?
- pjmlp 6y ago
  Indeed, however Google's usage of C and C++ sometimes is quite interesting. For example, Android source code is also not a very good example of modern usage of C++ security features. After 10 years, the NDK keeps having a C only API space, with all the memory corruption issues that it entails, even though the actual implementations are in C++ or Java (via JNI). So their workaround, starting with Android 11, is requiring hardware memory tagging in all ARM devices, while having kernel fuzzing support for other platforms lacking such hardware capabilities.
  - gmueckl 6y ago
    The C only interface is an absolute necessity. Only C++ can properly interface with C++ while C can interface with the rest of the world. And system libraries are there for whole world to use. if the system interfaces were converted to C++, all applications need to be written in C++ as well. You can wrap some features in other languages, but definitely not all of them.
    - pjmlp 6y ago
      Right, but in 10 years they surely would have the time to offer a type safe C++ API in addition, just like in other platforms. Instead, they have been postponing it since NDK was introduced in Android 2.0 until after the introduction of native packages, which will only arrive with Android 11. There are open tickets related to it.
- blargmaster33 6y ago
  Because : 1 : Rust syntax is weird, why not go with c/c++/java/c# like syntax? 2 : Rust has SJW bagage that turns alot of closet conservatives/libertarians off the language. There are two genders and a bunch of people with mental problems.
- 6y ago
riquito 6y ago
Matches closely the number of memory related security issues Firefox had in their CSS parser before the rewrite in Rust [1] > Over the course of its lifetime, there have been 69 security bugs in Firefox’s style component. If we’d had a time machine and could have written this component in Rust from the start, 51 (73.9%) of these bugs would not have been possible Also interesting on the topic of memory safety https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/ https://hacks.mozilla.org/2019/01/fearless-security-memory-s... [1] https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/ https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon...
- asjw 6y ago
  In this context I believe that the rewrite benefitted Firefox more than Rust At Firefox they already knew the problem they were trying to solve using Rust, they already wrote that software, already discovered many of the overlooked complications involved in writing a modern browser, so, in conclusion, even a rewrite in plain C would have solved many of the bugs. The simple operation of rewriting the same software with previous knowledge of how it works usually leads to simpler code (at the cost of developers time) Firefox is also the entity that invented Rust, so it's in their best interest to publicize it as "the final weapon" against bug, but "if we had used Rust from the beginning these bugs would not have been possible" is just wishful thinking. Rust itself could not be there without the browser war and the pressure that contemporary web puts on software that runs it And it'been C/C++ that has driven us there
  - k__ 6y ago
    To me it leads to exactly the opposite conclusion. C/C++ or it's developers couldn't deliver, so they went a very risky direction that led to success.
  - alex_duf 6y ago
    I think Rust is pretty much a meta-rewrite. The same way you describe a team learning from an existing product (CSS parser) what needed to be addressed, they applied the same logic but one level higher: on the very tool they were using. I think it's clever, it was risky but it seems to be paying off.
blintz 6y ago
It's funny how prescient "Eternal War in Memory" feels: https://people.eecs.berkeley.edu/~dawnsong/papers/Oakland13-SoK-CR.pdf https://people.eecs.berkeley.edu/~dawnsong/papers/Oakland13-... Of course, it's slightly dated, but a lot of the points feel truly 'eternal'. All of the SoK papers from Oakland are good, but this one is great.
fpoling 6y ago
Chromium initial design was a very simple main process and few untrusted relatively fat processes for web pages each holding set of tabs. That could have worked with C++. However the need for site isolation, performance considerations and hardware vulnerabilities later put an end to it. For example, initially Chromium had no support from isolating iframes from the main document. Everything was in Blink. But isolating iframes required extremely complex code in the main process to properly forward all DOM events between process. Then that code had to be made asynchronous so web pages could not block main UI. Then OS interfaces to GPU and it’s architecture rules out having GPU accelerated graphics and decoders in a per-site process. So that must be put in single a GPU process. Surely it is heavy sandboxed. But, as with the recent Networking process, it is still a shared component with very complex C++ code and fat platform libraries in C/Objective-C for interfacing with GPU. So at the end the original idea of writing everything in C++ and using sandboxed processes to make memory-safety bugs harmless just does not work. One needs a memory-safe language. The article mentioned various library-based approaches. But those, as having such foreign C++ usage, are becoming essentially domain-specific-languages that one needs to learn. That leads to boilerplating as the host language is not well-suited for that.
- blub 6y ago
  The idea of writing a constantly changing application and feeding it only untrusted content over the network while exposing more and more of the OS to that application does not work. It doesn't work in Firefox with its small block of Rust code, doesn't work in Chrome nor Safari. Because it's the dumbest fucking idea ever. But sure, at this point we don't have anything to lose by rewriting it in Rust/Swift/whatever.
  - asiachick 6y ago
    And that alternative is what? you run no software on your computer? Native apps have way more access to your system then a webpage so I'm glad there are 100s or 1000s of web apps I can run rather then being forced to install native apps to get the same functionality.
    - 6y ago
mkj 6y ago
What is the "//base" mentioned here? It's kinda hard to google... "//base is already getting into shape for spatial memory safety"
- tambre 6y ago
  Chromium's base library. Includes basic utilities useful across the codebase, e.g. hash maps, containers, pointer wrappers, logging, metaprogramming utilities, etc.
- maccam94 6y ago
  Chromium uses a build tool called bazel. //base is a bazel path, where // is the root of a workspace (which is usually a version controlled repository). Thus it is referring to https://chromium.googlesource.com/chromium/src/+/refs/heads/master/base/ https://chromium.googlesource.com/chromium/src/+/refs/heads/...
  - onekorg 6y ago
    Chromium actually uses GN, not bazel. https://docs.google.com/presentation/d/15Zwb53JcncHfEwHpnG_PoIbbzQ3GQi_cpujYwbpcbZo/edit?usp=drivesdk https://docs.google.com/presentation/d/15Zwb53JcncHfEwHpnG_P...
    - maccam94 6y ago
      Oh interesting, TIL. The syntax looked similar and it's a Google project, so I assumed gn was just some BUILD file generator on top.
- esprehn 6y ago
  Inside Google there's a C++ library of many common utilities called "base". The base in Chromium is an ancient fork of it that's evolved within the Chromium codebase over many years. Abseil is another descendant of the Google internal base library. WTF (Web Template Framework) is the similar library from WebKit, that also exists in Blink, though the two are quite different these days.
rurban 6y ago
That's why in the early 90ies people stepped back and created Java. Lisp was in its AI winter, but memory safety was still top priority for the industry.
Yuioup 6y ago
This is why C++ should be put to pasture and replaced by properly managed languages. It's time.
- cgrealy 6y ago
  Sure, all we need to do is rewrite billions of lines of code in some of the most popular software on the planet. And then replace it with... a language that is exactly as performant, is available on every known platform and has replacements for all the existing libraries (including all the ones written in C!).
  - titzer 6y ago
    I'll pay 15% performance for safety[1]. It's just that we have the wrong priorities, and you betrayed that default attitude again with the requirement that everything be "exactly as fast" as before. I still do not understand this focus on performance above everything else. It is absolutely unquestioned. We can't even talk about it. And it's constantly an argument that is undone by time. Machines are still getting faster. In the heydays of Moore's law, when performance was doubling literally every 12 months, if we were arguing about 15% of CPU performance, that's 2--TWO--months of performance. Now, it might be 1-2 years to get 15% single-core performance. But almost no one is limited by single-core performance anymore. We got stuck with the worst of all possible worlds--long compile times, long debugging times, long bugtails, horrible security, rickety and hard to refactor, ugly code. Oh, but it's fast. Fast and broken. Wonderful. Wonderful. Grandma is so much happier with her 15% faster something or other that spends 95% of its time idle waiting for user input. Oh, but that 15% of 5%...man that 0.8% is keeping me up at night! We forgot to zoom out to see that people need and depend on reliable software and utterly failed at that. It's as if we removed seatbelts, airbags, windshields, and mounted knives in random places in cars because we thought everyone wanted to go fast. No other disciple in all of engineering is so wrong with their priorities. God, society should be hopping mad at us for being so hostile to them. [1] Obviously, performance differences between "fast" languages and "safe" languages are so variable that we might as well be talking about comparing Fords to Ferraris--without specifying whether we are talking racecars (Ford makes some fast ones)! But 15% is a number we see often in the JVM world. After years in this field, I think the fastest safe language is not more than 15% off the fastest unsafe language, across the wide spectrum. Sometimes, you can get absolutely the same performance for the innermost hot loop out of a safe language vs unsafe language in some situations, you can get 2x slower. But people get terrified they'll never figure out why, that there is some kind of hidden, unknowable "language cost" they'll never get offer. Which is of course hogwash. Every program can be tuned and improved. Offer tools to find and remove bottlenecks and stop being sloppy with allocating memory.
VSPrw3C1yK 6y ago
Does Chromium test with valgrind, various sanitizers and static checkers? Since when? This is 5 years of bugs. How many would be caught by modern tools? Could those tools be improved to catch those bugs? I'm surprised this isn't mentioned in what they're trying, but maybe they're at the practical limit.
pmarreck 6y ago
Would immutable variables (or as they call them in functional langs, just “values”) ameliorate this problem?
- frou_dh 6y ago
  That's just begging for completion of the circle with "or as they call them in maths, variables" :)
hr0m 6y ago
There is an proposal for a GC-library: https://docs.google.com/document/d/1Cv2IcsiokkGc2K_5FBTDKekNzTn3iTEUyi9fDOud9wU/edit#heading=h.i5ibcxqde9h2 https://docs.google.com/document/d/1Cv2IcsiokkGc2K_5FBTDKekN... That is just like programming in D with extra steps.
WalterBright 6y ago
D has been steadily focusing on solving memory safety problems. It now has a prototype ownership/borrowing system incorporated into the language.
- eatonphil 6y ago
  C++ also has ownership/borrowing system (i.e. smart pointers) now though too, right? I'm a fan of D but isn't the problem about 1) defaults (or even required behavior) and 2) existence of libraries following good paradigms more so than just support for static memory management?
idoby 6y ago
Not at all surprising, but it's not like Rust (and others like it) are going to be a silver bullet against this. Any complex enough program running on a stored-program computer (where code is data and data is code) will be vulnerable. You can reduce the attack surface, but never eliminate it.
- 95th 6y ago
  Yes. But at least 70% bugs will be gone
deleted 6y ago
[deleted]
The_rationalist 6y ago
They should contribute and use https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-posted/ https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-post...
thePunisher 6y ago
The biggest problem is we are using systems programming languages to develop applications. We need to use application programming languages to develop applications. C and C++ are systems programming languages, to be used for developing operating systems, device drivers and other low level stuff. The problem is, we haven't had a real application programming language since the demise of Pascal / Delphi. And Java / C# have been able to pick-up some of the slack, but not nearly enough as there are still tons of software being written in unsafe languages.
- miohtama 6y ago
  The browsers have become systems themselves. Browsers need GPU, IO, media, etc. subsystems.
alfiedotwtf 6y ago
Every time someone tells me something along the lines of "you don't need Rust, just be a better programmer", I lookup CVEs for the projects they've worked on and sure enough there's memory safety issues. Just because you're a good driver doesn't mean you should forgo a seat belt!
johndoe42377 6y ago
Switching to a safe language is, obviously, not an option. However, it is possible, especially with resources of Google and other C++ shops to develop an advanced lint, which could be just a ripoff of compile time borrow checking from Rust (taking into account complexity of c++ memory model). Flagging simple things like use after free would already be a big deal. Nowadays it probably should be a plugin for clang or something similar instead of lint.
- steveklabnik 6y ago
  This is what the Core Guidelines are trying to do. Well, it's only attempting to tackle part of what Rust does.
- titzer 6y ago
  We should have more courage and attempt big things. Like writing the program we already wrote....again. We take this option off the table. Cannot rewrite. Definitely not in a safe language! Surely we have ceased to dream?
  - adev_ 6y ago
    > We should have more courage and attempt big things. > Like writing the program we already wrote....again. That's not named courage, that's named stupidity. Specially when the program you talk about is several millions lines of code and the results of years en engineering of entire teams. > We take this option off the table. Cannot rewrite. Definitely not in a safe language! Surely we have ceased to dream? There is people that dreams and there is the one that code. Evolution are (almost) always preferrable to Revolution. In this case, Evolution can mean: - Rewrite progressively the security sensible part in Rust mixed with the legacy (aka the Mozilla way) - Develop the tooling to make C++ safer/ or even better safe. That has already been done for a subset in the aeronautic industry - Work with the comitte to make C++ itself safer, which Google is already doing.
- mamcx 6y ago
  > Switching to a safe language is, obviously, not an option. Forever, never, ever, ever? Switch, right now, is not a good idea, but NEVER switch is the cobol curse. And not forget: C/C++ cause BILLONS of damage and costs in this industry. Is WELL KNOW, for DECADES that is the wrong tool for the job. Yet, the persisten myth that "lets not rewrite to something better" hold everything back. Imagine how stupid will any of us look if a customer ask us for build a new version of the software (or port to the web, or to mobile or cloud) and we say "nope, sorry. Is not good. Not rewrite sir!" Or if the software WE build have be caught, OFTEN with severe security and reliability bugs and we answer equally "we can't do anything better, is not a option". Dumb, right? Why rewrite is ok, normal and good for others, but not us? And why the excuse that the MOST PROFITABLES COMPANIES IN THE WORLD (Apple, Google, MS, ...) can't do rewrite, is too costly.... and then the rest PAY the cost anyway, with not solution on sight...
kerng 6y ago
Hopefully Microsoft starts porting some of the code over to Rust soon. That should help.

467 points by solarengineer 6y ago

Reminded me of an article I read last year (https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...) Interestingly enough Microsoft arrived at the same number. I think it really stresses how hard it is to reason about memory manually. I'm still surprised how much stuff is being written in non-safe languages even if people could get away with a managed language. One thing that I just recently noticed when scrolling through some github repos is how much new software in the linux ecosystem is still written in C despite it being probably avoidable, like flatpak.

ackbar03 6y ago
I get the feeling it's because it's impossible to get away without using c for low level high performance stuff
- saagarjha 6y ago
  As Rust shows, it’s not really impossible from a technical standpoint in many areas. The issues are more to do with convention and legacy and familiarity, for the most part. (Technically, C does have a couple of advantages: it’s stable, familiar, and extremely well supported in most places, and has basically had the world revolve around it for a couple decades at least. But there are a number of domains where these are surmountable.)
  - CameronNemo 6y ago
    C is also much better at dynamically linking, and results in much smaller binaries. Still not good justification for flatpak. Or crun (the reimplementation of runc in C) for that matter. The Red Hat crew has a problem with their reliance on C, Python, and Go. They need something like Rust (or even Vala, which does ARC from what I can tell) in their arsenal.
    - boccko 6y ago
      It's rather easy to dynamically link something that's not polymorphic.
    - eptcyka 6y ago
      What exactly is the issue with Rust and dynamic linking? Is it that it can't dynamically load Rust interfaces? There's nothing wrong with linking plain old symbols from shared objects in Rust.
      - adev_ 6y ago
        Rust has no stable ABI contrary to C and also support much higher concept like polymorphism or high order functions which are much harder to represent in a simple ABI. Real dynamic linking on that (dlopen-style) can be a real nightmare, specially between compiler versions. You can also add that Rust do not have a runtime, which is in many cases an advantage, but also tend to make libraries bigger.
        Groxx 6y ago
        Similar to C++ though, e.g. explosions of template expansions, you don't have to use those higher-level and harder-to-keep-concise features. Other fancy languages have stable ABIs, it's not impossible, nor does it require that it's complex to use. Though the average one is probably harder, yes. I'd wager that it's mostly lack of care or motivation though, made a bit worse by common language features.
        adev_ 6y ago
        > Similar to C++ though, e.g. explosions of template expansions, you don't have to use those higher-level and harder-to-keep-concise features. C++ has a stable ABI. Fragile, but stable. Or doing things like updating libQt on your Linux distribution without recompiling half of the world would be close to impossible :)
        6y ago
- lmm 6y ago
  It's not, people are just incapable of making realistic assessments of what level of performance they require. If you're using C or C++ "for performance" and not using a profiler in day-to-day development, you don't need to be using C or C++ and should be using a memory-safe language instead.
  - throwaway17_17 6y ago
    I will agree in part, if you aren’t using C or C++ in performance critical software you probably could use another language. I think your profiler-every-day requirement is, maybe, a tiny bit too restrictive, but not by much. There is certainly a need for the industry (and hobbyists) to take stock of both what is necessary and what is just desired. I just don’t want to see the bar for using a language that doesn’t handle all aspects of memory usage and performance to be restricted to soft real-time applications and infrastructure projects. Digging into low level programming can be fun and rewarding. My problem is essentially that even if I am not absolutely concerned with maximum performance across memory usage, binary size, CPU efficiency, bandwidth, etc. I still truly enjoy the options for control (or the illusion of it) that is provided by C. I enjoy memory layout design, allocator design, cache-efficiency considerations and the like; while at the same time, I don’t have a huge love of malloc and free or having to track down segfaults. I think ‘performance-by-default’ is a viable language design goal and want more of it in my tools. I keep posting comments mentioning my pet language project, mostly in hopes that when I see it on my threads display I can continue to shame myself into getting it released on time, and this is one of those. These kinds of concerns motivated me to design a language for personal use that gives me what I want, but doesn’t require (but can) allow me to deal with other things. I enjoy using Coq, Haskell, Idris, Lisp, ATS, and Clean. But those language deprive me of things I really do enjoy. So I’m going for a low level language (in the Perlis sense) that has an experimental type theory. This will certainly allow for a memory safe subset and is the kind of thing I want to see more of from others.
  - danielscrubs 6y ago
    "Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware is becoming faster. The adage is named after Niklaus Wirth, who discussed it in his 1995 article "A Plea for Lean Software".[1][2]" We could do better languages. But it just takes insane resources to compete with the others ecosystem. IDE's, the Pandas, the format on save. I've been a professional C++-developer in the past and one of the great things is the tooling and the just sheer knowledge of my past C++ colleagues. They know what happens in the kernel, they know the performance optimisation tricks, they know a lot, because the knowledge they gather just have a longer lifespan. Ask a JS-developer and they will tell you all the web frameworks that came before React and their quirks...
keithwinstein 6y ago
You know, I totally buy that 70% of the vulnerabilities in complex C++ code relate to memory safety, especially in something like Chromium, which is incredibly complex and includes a lot of third-party code that wasn't always designed at first to be robust to untrusted input, and also fast-moving with a ton of code added or churning every week. But I'm not sure I buy that memory-safe languages will consequently be as beneficial for safety (especially in other kinds of software) as that fact would suggest. For one, not all software is like Chromium. If you look at something like OpenSSH, the vast majority of their security holes have nothing to do with memory safety and are just logic bugs (often caused by features that somebody added that aren't core to the basic SSH experience, e.g. code that interfaces with X11 or something) or protocol weaknesses. (http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh) The other effect is that in practice, memory-safe languages can come with security baggage of their own. If you look at the zillions of security holes in something like Rails or Wordpress or Django, a fair portion of them relate to an attacker's ability to invoke sophisticated-but-unintended behaviors that are more likely to be hiding in these managed languages (and their support libraries) than in something like C++. E.g. CVE-2013-0156 or CVE-2013-0277 or apparently any current Python or Ruby program that, even today, calls yaml.load on untrusted input. That kind of "security hole from unwanted latent functionality" is less likely to exist in C++. (I realize this is a contrarian view not shared by the vast majority of PL/security experts, but the ones I hang out with seem to interpret "memory-safe language" to mean "expert-written Haskell or, if you want to slum it, Rust" and are not thinking "random Ruby/Python/JavaScript/enterprise Java".) Not to mention the countless high-profile security holes that have nothing to do with memory safety, e.g. Shellshock, "goto fail", Lucky Thirteen, BEAST, CRIME, POODLE, FREAK, Logjam, etc. Or bugs that are very relevant to Chromium but aren't really Chromium's fault and probably don't appear on their own list, e.g. Meltdown/Spectre etc.
- saagarjha 6y ago
  Yes, it is important to note that switching to a memory safe language does not magically solve all your bugs. My own personal anecdote: when I found multiple bypasses in the sandboxing mechanism on macOS, it was not because the relevant code was written in C++, but because the dynamic linker is a really complex system; the things I found clearly flew under the engineer’s radar when they were designing it and they didn’t think beforehand about how those components interacted together. Still, being able to reduce the attack surface area to solely be logic errors is much better than having to deal with memory safety thrown in as well. (Similarly, languages with stricter type systems magically get rid of issues like “you gave me a string and I wanted an int”, but the problems of “you forgot to check the password in this one case” still remain.)
msla 6y ago
The problem with memory management is a problem with lifetime management, which Rust reasons about in terms of ownership management, which it attempts to reason about statically, with help from the programmer. GC attempts to do the same thing, dynamically, with less help from the programmer. Both of those methods still allow leaks, which is why Rust encourages RAII. [1] Are there other structured lifetimes we can get compilers to enforce for us, like they enforce certain invariants about flow control using control structures? [1] https://users.rust-lang.org/t/memory-leaks-in-rust/18187/2 https://users.rust-lang.org/t/memory-leaks-in-rust/18187/2 http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-safe/ http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-... https://doc.rust-lang.org/nomicon/leaking.html https://doc.rust-lang.org/nomicon/leaking.html
dependenttypes 6y ago
> I'm still surprised how much stuff is being written in non-safe languages even if people could get away with a managed language. The distinction between unsafe and managed languages does not make any sense. You can for example have a safe C implementation. No need to move to another language.
- doomjunky 6y ago
  But in managed languages the safety comes by default and in unmanaged languages the safety comes by exception.
  - dependenttypes 6y ago
    In both ways safety comes by the implementation. It just so happens that so called "safe" languages tend to have a single safe implementation while "unsafe" ones tend to have multiple unsafe and one or two safe ones. Does the amount of unsafe implementations matter?
mister_hn 6y ago
Just imagine that SQLite is written in C and the major of bugs are logical/optimization ones, not related to memory management. And when talking about C++, since 2011 there are smart pointers to help developers managing memory kind of automatically. I believe most of the problems are due the people typing on those keyboards such bad code, especially when it comes to "smart" code. In 2020 we have plenty of tools supporting the developer job (memory sanitizers, static analysis tools, linting, profilers, etc.): The big problem is failing to / ignoring to use such tools.
- saagarjha 6y ago
  Chrome is a heavy user of such tools and has many talented engineers working on it.
  - aylp 6y ago
    Citation needed. I never see the same level of dedication in big Google or Facebook projects as in well run smaller projects like SQLite. You are directly rewarded for "new" features (i.e. plagiarizing or rewriting old ones and selling them as new). So I don't think the engineers are particularly talented, and the incentives are not the same as for SQLite.
    - ReactiveJelly 6y ago
      If using Rust results in fewer bugs for less money, shouldn't we still do it? The reason SQLite can test so thoroughly is that their requirements never change. I have tried to browse the web with SQLite but so far no luck.
      - alpp 6y ago
        If one has to deal with boring Rust zealots all day, the answer is no.
- boccko 6y ago
  Do you think issue at google is not knowing about/not using the proper tools?
kungtotte 6y ago
C on Unix-like systems isn't so surprising. The K&R book devotes a large section to the Unix system interface for example, the Linux kernel is one of the biggest C projects in the world, and even when using a higher level language to write your programs you're ultimately calling into libc or wrapping other C libraries or syscalls. It's a case of "When in Rome, do as the Romans do".
sseth 6y ago
The "Rule of 2" link in the article actually says this : "A recent study by Matt Miller from Microsoft Security states that “~70% of the vulnerabilities addressed through a security update each year continue to be memory safety issues”.

dstaley 6y ago

Not to be snarky, but my initial response to this was "Large project that uses language known for memory safety issues discovers that most of their security bugs stem from memory safety issues". In a more serious note, I hope this motivates the Chromium team to invest more in Rust. While the other options sound like good "in the meantime" solutions, switching to a language that, at its core, is designed to prevent these sorts of issues would be a huge benefit to society as a whole considering that Chromium is the most popular browser engine in the world.

rosstex 6y ago
70% of security defects in memory-safe languages are probably also memory safety problems.
- _bxg1 6y ago
  That doesn't make any sense at all
  - robobro 6y ago
    The world doesn't make sense. That's why we humans suffer.
  - rosstex 6y ago
    please laugh i'm trying my best
    - antonvs 6y ago
      70% of all failed jokes on HN were best efforts. But not this one.
      - nullc 6y ago
        70% of all failed jokes on HN are due to memory safety problems.

mkj 6y ago

To me it seems likely the percentage is even higher in other programs - a web browser has a pretty complicated privacy/isolation model compared with most other programs so that increases the 23.9% "Other" here. Normal "logic" bugs would be more likely to have security implications.

jariel 6y ago

Question to C++ pros: are there not idioms that can be used and ruthlessly enforced to avoid such problems entirely? Is this the result of 'open use of pointers' that inevitably causes problems here and there? Or is this problem due to the fact is just impossible to use even hard idioms to avoid such problems? (Or hard to enforce them?) On some small-to-midsized projects I've seen narrow and rigorously enforced rules around pointers that seemed to work well. So what's up?

necubi 6y ago
If you try to strictly enforce memory safety in C++, you end up with code that looks a lot like Rust. But the Rust compiler will fail to compile code that has memory-safety issues (outside of unsafe blocks), while your C++ compiler will happily ignore them.
- jandrewrogers 6y ago
  The challenge is that the Rust compiler will fail to compile many codes that are strictly and provably memory safe but fall outside Rust’s narrow model of “memory safe”, and which are required for performance reasons. You’d have to wrap most of the code in unsafe blocks. In C++17 you can directly write type infrastructure that transparently enforces memory safety models that Rust doesn’t grok, which is a pretty nice feature. Many people underestimate what is possible using C++ these days. Complex for sure, but also very powerful.
  - kelnos 6y ago
    > Many people underestimate what is possible using C++ these days. Complex for sure, but also very powerful. And that's the problem. There are very few true C++ experts, and most people will run into these issues as a matter of course. This just feels like a reduction to the usual: if you are perfect, you will write perfect code, and never have memory-safety bugs. Thanks, but I'm not perfect, and I'd rather write in a language with a compiler that rejects programs with memory-safety bugs. And yes, that does mean sometimes it'll reject some programs that are perfectly ok, but the Rust borrow checker is getting better all the time, and sometimes you just have to accept being hamstrung a little for the greater good.

Animats 6y ago

And that's new code, not legacy. Embarrassing. I would have expected better from something written in this century. C++ does sort of have a safe subset. If you're passing raw pointers all over the place today, you're doing it wrong.

fabrice_d 6y ago
"sort of" is the key. If the language doesn't prevent you from shooting yourself in the foot, on any large project bad things will happen. Safer languages are better tools because they make obvious when you're stepping out of the safe zone, which is not the case with C++, even modern releases.
_se 6y ago
Passing raw (non-owning) pointers is fine, even if references would be better. Heap allocating with new instead of a smart pointer is the problem.
- zetafunction 6y ago
  Non-owning pointers are absolutely a problem if the object graph is large and complex enough. Many objects in Chromium have lifetimes managed by smart pointers, but unfortunately, that doesn't do anything to protect against code that mistakenly violates an invariant like "object X must always outlive Y due to these non-owning pointers". The problem is C++ turns a violation of lifetime invariants into undefined behavior rather than safely crashing.
scarmig 6y ago
At some point, the idea that a tool is fine, it's just that everyone is using it wrong starts to become a reason to look for alternatives to the tool. Chromium is a large cpp project, with lots of resources behind it, but people still fail to write safe code for it. There are small bore efforts that can be done to tangibly improve things, but in the end it seems like the real solution is to start writing components in a language that offers better memory safety and maintains high performance. That is a huge, risky effort as well, of course.
6y ago

sumanthvepa 6y ago

C++ can be used safely without memory safety issues. But it requires expertise with the language, which is a very steep barrier for most programmers, even ones on the Chrome team to pass successfully. In a project as large as Chrome the vast majority of programmers will not have the necessary expertise. And sadly, in this case, what you don't know will hurt you. Is that a reason for not using C++: maybe. But you would be hard pressed to find a more performant language that is mature and stable.

saagarjha 6y ago
Even the best software engineers make memory safety mistakes.
summerlight 6y ago
No, even world-class C++ experts can and will make subtle memory safety bugs across abstraction boundaries. Think about millions of lines of C++ codes which have their own assumptions on invariant and contract. Their time is a limited resource and for many cases memory safety is not the most valuable thing to put their efforts.
kbumsik 6y ago
> In a project as large as Chrome the vast majority of programmers will not have the necessary expertise. Wait, then what kind of devs would have enough expertise?
nindalf 6y ago
We need to let go of this idea that there are godlike engineers out there who can write perfect code. Everyone makes mistakes. As long as the compiler allows it, such mistakes will continue to happen. > in a project as large as Chrome the vast majority of programmers will not have the necessary expertise. Then how do we staff such projects? Hire only people with a track record of never writing such bugs? It’s not possible.
phkahler 6y ago
There is a big difference between "theoretically C++ could be written safely" and "Rust is safe."

rb808 6y ago

I gave up C++ 10 years ago and switched to more modern languages. I figured the language would die off, so am a bit shocked its still so prevalent. I really dont think there is any reason to use C or C++ any more, except perhaps some low level layer that interacts with the hardware.

dmortin 6y ago
Even if C++ is used less than before it won't die off and C++ experts can demand more money especially because there are fewer of them as most programmers move to more modern languages.
- lsofzz 6y ago
  COBOL
  - dmortin 6y ago
    Yep, the same case. Only I read that those old COBOL programs are a huge mess of spaghetti code, so you are well paid, but you have to put up with ugly, hard to maintain code. I'd rather work on something nicer for less money.
pjmlp 6y ago
Depending on which domains you are it is still unavoidable. For example, I hardly do any C++ nowadays, it is however what I get to use to integrate with OS native libraries and GPGPU shaders.
jve 6y ago
Even if there are 0 lines of code written in C from now on, existing codebase (huge) still has to be maintained. C wont be dead in our lifetime. Rewriting everything is also not an option. Imagine rebuilding your house with modern materials, because old ones may have some shortcomings. Who will pay for that?

foobar_ 6y ago

Can't we just enable bounds checking and gc and live with slowness. Shouldn't that be a choice, a compiler flag ? Every time there is a security issue, someone can see your naked pictures.

_ph_ 6y ago
Neither automatic bounds checking nor GC really add slowness. Any reasonably safe program will check the bounds explicitly, so there is no speed gained vs. guaranteed bounds checking via the compiler. Actually any good compiler can remove most bounds checks, if it can proove that the access is in bounds. Also GC can be quite faster than manual dynamic memory management.
GordonS 6y ago
Do you know of any fully-featured Web browsers that have been implemented with "safe" language, such as C# or Java? Would be a really interesting project to see!
- _ph_ 6y ago
  Very early on, Sun had a web browser implemented in Java. Unfortunately, this was dropped before Java got Hotspot and with that the decisive speed up. (They also had a web server implemented in Java, which sounds like an excellent idea too)
zetafunction 6y ago
There's actually been quite a bit of work to bounds check accesses for containers implemented inside Chromium, such as span and optional, but it's harder to get these checks into upstream libc++. GC is one way to reduce the number of memory safety issues, but there are often tricky interactions between GC and non-GC code. Another issue with GC is it's often much harder to reason about object lifetimes.

m463 6y ago

What if with "dangerous languages" like C you could turn off pointers, or make only functional subroutines? For instance, perl has this construct, to make your programs better: a program foo.pl: $c = 1; runs fine. Now turn on strict: use strict; $c = 1; and $ perl ./foo.pl Global symbol "$c" requires explicit package name at ./foo.pl line 2. Execution of ./foo.pl aborted due to compilation errors. you must declare $c: my $c = 1; the idea would be... write your program and you can opt-in to various constructs. NOTE: my first example didnt' work. use strict; $a = 1; won't throw an error. Turns out the variables "$a" and "$b" are exempt from "use strict;" ha. wow.

scarmig 6y ago
`use stricter;` is the obvious solution.
snicker7 6y ago
Not being allowed to use pointers means not having control of memory layout.
- m463 6y ago
  the idea would be routine by routine you could turn on features. So make this function functional with no side effects. This function doesn't (overtly) use pointers. etc... At various jobs, we've done things like this with warnings. Get a source file to compile warning free, then turn on -Werror (this is done via compile flags, a different mechanism)
lmm 6y ago
You have to be very careful that the looser language doesn't break the rules that the stricter language relies on. Have a look at the Noether design for a serious effort at doing this kind of stratified language.
raverbashing 6y ago
> What if with "dangerous languages" like C you could turn off pointers You can't. C is a fundamentally defective language because it doesn't have the "memory slice"/"array" construct. Of course you can work around it, but if you eliminate pointers then you can't do much with C. Heck you can't even print "Hello World" with it (well, ok, technically you can but not in the usual way).

phillipcarter 6y ago

Why haven't they just started to rewrite it in rust yet?

pjmlp 6y ago
Indeed, however Google's usage of C and C++ sometimes is quite interesting. For example, Android source code is also not a very good example of modern usage of C++ security features. After 10 years, the NDK keeps having a C only API space, with all the memory corruption issues that it entails, even though the actual implementations are in C++ or Java (via JNI). So their workaround, starting with Android 11, is requiring hardware memory tagging in all ARM devices, while having kernel fuzzing support for other platforms lacking such hardware capabilities.
- gmueckl 6y ago
  The C only interface is an absolute necessity. Only C++ can properly interface with C++ while C can interface with the rest of the world. And system libraries are there for whole world to use. if the system interfaces were converted to C++, all applications need to be written in C++ as well. You can wrap some features in other languages, but definitely not all of them.
  - pjmlp 6y ago
    Right, but in 10 years they surely would have the time to offer a type safe C++ API in addition, just like in other platforms. Instead, they have been postponing it since NDK was introduced in Android 2.0 until after the introduction of native packages, which will only arrive with Android 11. There are open tickets related to it.
blargmaster33 6y ago
Because : 1 : Rust syntax is weird, why not go with c/c++/java/c# like syntax? 2 : Rust has SJW bagage that turns alot of closet conservatives/libertarians off the language. There are two genders and a bunch of people with mental problems.
6y ago

riquito 6y ago

Matches closely the number of memory related security issues Firefox had in their CSS parser before the rewrite in Rust [1] > Over the course of its lifetime, there have been 69 security bugs in Firefox’s style component. If we’d had a time machine and could have written this component in Rust from the start, 51 (73.9%) of these bugs would not have been possible Also interesting on the topic of memory safety https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/ https://hacks.mozilla.org/2019/01/fearless-security-memory-s... [1] https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/ https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon...

asjw 6y ago
In this context I believe that the rewrite benefitted Firefox more than Rust At Firefox they already knew the problem they were trying to solve using Rust, they already wrote that software, already discovered many of the overlooked complications involved in writing a modern browser, so, in conclusion, even a rewrite in plain C would have solved many of the bugs. The simple operation of rewriting the same software with previous knowledge of how it works usually leads to simpler code (at the cost of developers time) Firefox is also the entity that invented Rust, so it's in their best interest to publicize it as "the final weapon" against bug, but "if we had used Rust from the beginning these bugs would not have been possible" is just wishful thinking. Rust itself could not be there without the browser war and the pressure that contemporary web puts on software that runs it And it'been C/C++ that has driven us there
- k__ 6y ago
  To me it leads to exactly the opposite conclusion. C/C++ or it's developers couldn't deliver, so they went a very risky direction that led to success.
- alex_duf 6y ago
  I think Rust is pretty much a meta-rewrite. The same way you describe a team learning from an existing product (CSS parser) what needed to be addressed, they applied the same logic but one level higher: on the very tool they were using. I think it's clever, it was risky but it seems to be paying off.

blintz 6y ago

It's funny how prescient "Eternal War in Memory" feels: https://people.eecs.berkeley.edu/~dawnsong/papers/Oakland13-SoK-CR.pdf https://people.eecs.berkeley.edu/~dawnsong/papers/Oakland13-... Of course, it's slightly dated, but a lot of the points feel truly 'eternal'. All of the SoK papers from Oakland are good, but this one is great.

fpoling 6y ago

Chromium initial design was a very simple main process and few untrusted relatively fat processes for web pages each holding set of tabs. That could have worked with C++. However the need for site isolation, performance considerations and hardware vulnerabilities later put an end to it. For example, initially Chromium had no support from isolating iframes from the main document. Everything was in Blink. But isolating iframes required extremely complex code in the main process to properly forward all DOM events between process. Then that code had to be made asynchronous so web pages could not block main UI. Then OS interfaces to GPU and it’s architecture rules out having GPU accelerated graphics and decoders in a per-site process. So that must be put in single a GPU process. Surely it is heavy sandboxed. But, as with the recent Networking process, it is still a shared component with very complex C++ code and fat platform libraries in C/Objective-C for interfacing with GPU. So at the end the original idea of writing everything in C++ and using sandboxed processes to make memory-safety bugs harmless just does not work. One needs a memory-safe language. The article mentioned various library-based approaches. But those, as having such foreign C++ usage, are becoming essentially domain-specific-languages that one needs to learn. That leads to boilerplating as the host language is not well-suited for that.

blub 6y ago
The idea of writing a constantly changing application and feeding it only untrusted content over the network while exposing more and more of the OS to that application does not work. It doesn't work in Firefox with its small block of Rust code, doesn't work in Chrome nor Safari. Because it's the dumbest fucking idea ever. But sure, at this point we don't have anything to lose by rewriting it in Rust/Swift/whatever.
- asiachick 6y ago
  And that alternative is what? you run no software on your computer? Native apps have way more access to your system then a webpage so I'm glad there are 100s or 1000s of web apps I can run rather then being forced to install native apps to get the same functionality.
  - 6y ago

mkj 6y ago

What is the "//base" mentioned here? It's kinda hard to google... "//base is already getting into shape for spatial memory safety"

tambre 6y ago
Chromium's base library. Includes basic utilities useful across the codebase, e.g. hash maps, containers, pointer wrappers, logging, metaprogramming utilities, etc.
maccam94 6y ago
Chromium uses a build tool called bazel. //base is a bazel path, where // is the root of a workspace (which is usually a version controlled repository). Thus it is referring to https://chromium.googlesource.com/chromium/src/+/refs/heads/master/base/ https://chromium.googlesource.com/chromium/src/+/refs/heads/...
- onekorg 6y ago
  Chromium actually uses GN, not bazel. https://docs.google.com/presentation/d/15Zwb53JcncHfEwHpnG_PoIbbzQ3GQi_cpujYwbpcbZo/edit?usp=drivesdk https://docs.google.com/presentation/d/15Zwb53JcncHfEwHpnG_P...
  - maccam94 6y ago
    Oh interesting, TIL. The syntax looked similar and it's a Google project, so I assumed gn was just some BUILD file generator on top.
esprehn 6y ago
Inside Google there's a C++ library of many common utilities called "base". The base in Chromium is an ancient fork of it that's evolved within the Chromium codebase over many years. Abseil is another descendant of the Google internal base library. WTF (Web Template Framework) is the similar library from WebKit, that also exists in Blink, though the two are quite different these days.

rurban 6y ago

That's why in the early 90ies people stepped back and created Java. Lisp was in its AI winter, but memory safety was still top priority for the industry.

Yuioup 6y ago

This is why C++ should be put to pasture and replaced by properly managed languages. It's time.

cgrealy 6y ago
Sure, all we need to do is rewrite billions of lines of code in some of the most popular software on the planet. And then replace it with... a language that is exactly as performant, is available on every known platform and has replacements for all the existing libraries (including all the ones written in C!).
- titzer 6y ago
  I'll pay 15% performance for safety[1]. It's just that we have the wrong priorities, and you betrayed that default attitude again with the requirement that everything be "exactly as fast" as before. I still do not understand this focus on performance above everything else. It is absolutely unquestioned. We can't even talk about it. And it's constantly an argument that is undone by time. Machines are still getting faster. In the heydays of Moore's law, when performance was doubling literally every 12 months, if we were arguing about 15% of CPU performance, that's 2--TWO--months of performance. Now, it might be 1-2 years to get 15% single-core performance. But almost no one is limited by single-core performance anymore. We got stuck with the worst of all possible worlds--long compile times, long debugging times, long bugtails, horrible security, rickety and hard to refactor, ugly code. Oh, but it's fast. Fast and broken. Wonderful. Wonderful. Grandma is so much happier with her 15% faster something or other that spends 95% of its time idle waiting for user input. Oh, but that 15% of 5%...man that 0.8% is keeping me up at night! We forgot to zoom out to see that people need and depend on reliable software and utterly failed at that. It's as if we removed seatbelts, airbags, windshields, and mounted knives in random places in cars because we thought everyone wanted to go fast. No other disciple in all of engineering is so wrong with their priorities. God, society should be hopping mad at us for being so hostile to them. [1] Obviously, performance differences between "fast" languages and "safe" languages are so variable that we might as well be talking about comparing Fords to Ferraris--without specifying whether we are talking racecars (Ford makes some fast ones)! But 15% is a number we see often in the JVM world. After years in this field, I think the fastest safe language is not more than 15% off the fastest unsafe language, across the wide spectrum. Sometimes, you can get absolutely the same performance for the innermost hot loop out of a safe language vs unsafe language in some situations, you can get 2x slower. But people get terrified they'll never figure out why, that there is some kind of hidden, unknowable "language cost" they'll never get offer. Which is of course hogwash. Every program can be tuned and improved. Offer tools to find and remove bottlenecks and stop being sloppy with allocating memory.

VSPrw3C1yK 6y ago

Does Chromium test with valgrind, various sanitizers and static checkers? Since when? This is 5 years of bugs. How many would be caught by modern tools? Could those tools be improved to catch those bugs? I'm surprised this isn't mentioned in what they're trying, but maybe they're at the practical limit.

pmarreck 6y ago

Would immutable variables (or as they call them in functional langs, just “values”) ameliorate this problem?

frou_dh 6y ago
That's just begging for completion of the circle with "or as they call them in maths, variables" :)

hr0m 6y ago

There is an proposal for a GC-library: https://docs.google.com/document/d/1Cv2IcsiokkGc2K_5FBTDKekNzTn3iTEUyi9fDOud9wU/edit#heading=h.i5ibcxqde9h2 https://docs.google.com/document/d/1Cv2IcsiokkGc2K_5FBTDKekN... That is just like programming in D with extra steps.

WalterBright 6y ago

D has been steadily focusing on solving memory safety problems. It now has a prototype ownership/borrowing system incorporated into the language.

eatonphil 6y ago
C++ also has ownership/borrowing system (i.e. smart pointers) now though too, right? I'm a fan of D but isn't the problem about 1) defaults (or even required behavior) and 2) existence of libraries following good paradigms more so than just support for static memory management?

idoby 6y ago

Not at all surprising, but it's not like Rust (and others like it) are going to be a silver bullet against this. Any complex enough program running on a stored-program computer (where code is data and data is code) will be vulnerable. You can reduce the attack surface, but never eliminate it.

95th 6y ago
Yes. But at least 70% bugs will be gone

deleted 6y ago

[deleted]

The_rationalist 6y ago

They should contribute and use https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-posted/ https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-post...

thePunisher 6y ago

The biggest problem is we are using systems programming languages to develop applications. We need to use application programming languages to develop applications. C and C++ are systems programming languages, to be used for developing operating systems, device drivers and other low level stuff. The problem is, we haven't had a real application programming language since the demise of Pascal / Delphi. And Java / C# have been able to pick-up some of the slack, but not nearly enough as there are still tons of software being written in unsafe languages.

miohtama 6y ago
The browsers have become systems themselves. Browsers need GPU, IO, media, etc. subsystems.

alfiedotwtf 6y ago

Every time someone tells me something along the lines of "you don't need Rust, just be a better programmer", I lookup CVEs for the projects they've worked on and sure enough there's memory safety issues. Just because you're a good driver doesn't mean you should forgo a seat belt!

johndoe42377 6y ago

Switching to a safe language is, obviously, not an option. However, it is possible, especially with resources of Google and other C++ shops to develop an advanced lint, which could be just a ripoff of compile time borrow checking from Rust (taking into account complexity of c++ memory model). Flagging simple things like use after free would already be a big deal. Nowadays it probably should be a plugin for clang or something similar instead of lint.

steveklabnik 6y ago
This is what the Core Guidelines are trying to do. Well, it's only attempting to tackle part of what Rust does.
titzer 6y ago
We should have more courage and attempt big things. Like writing the program we already wrote....again. We take this option off the table. Cannot rewrite. Definitely not in a safe language! Surely we have ceased to dream?
- adev_ 6y ago
  > We should have more courage and attempt big things. > Like writing the program we already wrote....again. That's not named courage, that's named stupidity. Specially when the program you talk about is several millions lines of code and the results of years en engineering of entire teams. > We take this option off the table. Cannot rewrite. Definitely not in a safe language! Surely we have ceased to dream? There is people that dreams and there is the one that code. Evolution are (almost) always preferrable to Revolution. In this case, Evolution can mean: - Rewrite progressively the security sensible part in Rust mixed with the legacy (aka the Mozilla way) - Develop the tooling to make C++ safer/ or even better safe. That has already been done for a subset in the aeronautic industry - Work with the comitte to make C++ itself safer, which Google is already doing.
mamcx 6y ago
> Switching to a safe language is, obviously, not an option. Forever, never, ever, ever? Switch, right now, is not a good idea, but NEVER switch is the cobol curse. And not forget: C/C++ cause BILLONS of damage and costs in this industry. Is WELL KNOW, for DECADES that is the wrong tool for the job. Yet, the persisten myth that "lets not rewrite to something better" hold everything back. Imagine how stupid will any of us look if a customer ask us for build a new version of the software (or port to the web, or to mobile or cloud) and we say "nope, sorry. Is not good. Not rewrite sir!" Or if the software WE build have be caught, OFTEN with severe security and reliability bugs and we answer equally "we can't do anything better, is not a option". Dumb, right? Why rewrite is ok, normal and good for others, but not us? And why the excuse that the MOST PROFITABLES COMPANIES IN THE WORLD (Apple, Google, MS, ...) can't do rewrite, is too costly.... and then the rest PAY the cost anyway, with not solution on sight...

kerng 6y ago

Hopefully Microsoft starts porting some of the code over to Rust soon. That should help.