LWN: Comments on "Google series on in-the-wild exploits"

Google series on in-the-wild exploits

ibukanov — Tue, 19 Jan 2021 12:26:47 +0000

The real problem is the use after free. Modern C++ provides enough features to get it. And with std::span and string_view one gets even more rope to hang themselves.

Google series on in-the-wild exploits

zlynx — Sat, 16 Jan 2021 20:44:38 +0000

I have seen C++ code trying to do everything correctly and still created two unique_ptrs to the same object. Double free! It can also happen with a unique_ptr and a shared_ptr.

Modern C++ makes it less likely but it isn't impossible.

Google series on in-the-wild exploits

mpr22 — Sat, 16 Jan 2021 16:00:14 +0000

For libraries in particular, C is the lowest common denominator. Implementing FFI infrastructure for C libraries is easy (you don't need to understand e.g. C++ symbol mangling), and every language whose users are likely to be interested in invoking external libraries not written in that language has a C FFI infrastructure.

Google series on in-the-wild exploits

mss — Sat, 16 Jan 2021 15:36:35 +0000

> It's hard to understand why new C development is still tolerated: slower, naturally insecure, and markedly less productive.

It is a peculiarity of grassroots open source projects which I don't really get either.

Where the project was started by a company C++ is nearly always used for the reasons you have mentioned.
See: both browsers, clang, Qt, OpenCV, LibreOffice, VirtualBox...
Even GCC started to be partially implemented in C++ when Ian Lance Taylor from Google worked on it.

But for Glib / GTK and many smaller open source projects we are stuck with C for some reason, with hand-written OOP requiring significant amounts of boilerplate code, usually without automatic type checking when casting, lacking RAII or good generic containers and algorithms.

Many parts (most?) of Glib wouldn't even be necessary had GTK been implemented in C++.

Google series on in-the-wild exploits

ras — Sat, 16 Jan 2021 09:57:14 +0000

https://1.bp.blogspot.com/-zWgmKrcnjv8/X_4pAn_ymUI/AAAAAA... is a graph from those blog posts showing when chrome was vulnerable to 4 exploits. If you turn off auto upgrades and somehow knew how to tip toe between the vulnerabilities you would indeed be able to Chrome in safely - from the listed exploits at least.

Geeze we suck.

Google series on in-the-wild exploits

ncm — Fri, 15 Jan 2021 04:11:26 +0000

I was impressed at the very large fraction of exploits based on double-free events. Used to be, buffer overruns ruled, but have faded.

Double-free never happens in modern C++ code. Or most things, really. It's hard to understand why new C development is still tolerated: slower, naturally insecure, and markedly less productive.

Google series on in-the-wild exploits

mss — Thu, 14 Jan 2021 14:45:41 +0000

Nice series, even if a bit long read.

Shows well how hard is to translate a "safe" language like JavaScript into an "unsafe" ISA like x86 or ARM.
Explicit checks are needed since many invalid operations might not cause an exception at the hardware level.

However, for example, bounds checking every memory access would ruin performance so JIT compilers try to be smart
and avoid checking where they can prove the access will always be within the accessed object bounds.
Which, in general, is a hard thing to do, so we get a constant stream of bugs.

This will always be a problem until CPUs somehow implement efficient per-object bounds checking and which-object-tagged memory accesses.