This shouldn't have happened: A vulnerability postmortem • Hacker News Board

Re: This shouldn't have happened: A vulnerability postmortem

#421

Post by staticassertion » Thu, Dec 02, 2021, 1:19 PM UTC

nineteen999 wrote: post #300

titzer wrote: post #275

Earlier quoted context omitted.

The whole post is a giant blinking red sign that says (or should say) "Fuzzing is a horribly ineffective workaround for a treacherous language." No offense to the many bright and capable people who have worked hard on the C/C++ language, tools, compilers, libraries, kernels, etc over the years, but we will someday look back on it as asbestos and wonder why we kept at it for so damn long .

No issue with the first sentence of your message at all, but... > No offense to the many bright and capable people who have worked hard on the C/C++ language, tools, compilers, libraries, kernels, etc over the years, but we will someday look back on it as asbestos and wonder why we kept at it for so damn long. We won't wonder at all. We will understand that those people are the ONLY ones that stepped up to the task o…

I don't think this paints an accurate picture. This sort of presupposes that C/C++ were a first iteration, but that's not true.

People chose C and C++ for bad reasons, even with historic context. Languages used to be more correct. Algol2 used to validate array subscribting and not have null etc. It was C programmers who pushed languages to be worse because it made it easier to write code.

They very much created this problem and we regressed because of their choices. Things could have been a lot better.

Re: This shouldn't have happened: A vulnerability postmortem

#422

Post by staticassertion » Thu, Dec 02, 2021, 1:22 PM UTC

nineteen999 wrote: post #411

titzer wrote: post #403

Earlier quoted context omitted.

> We will understand that those people are the ONLY ones that stepped up to the task over 50 years to write this kind of software, organize standards bodies for their languages and platforms, get their software packaged as part of mainstream operating systems and out into the world, deal with patches from users, and help millions of other people make a living, enable the internet to happen, etc. While my comment was…

This comment misses the point so far as to be completely unnecessary.

It pretty much addresses your core thesis and shows it to be based on a fictional retelling of history.

Re: This shouldn't have happened: A vulnerability postmortem

#423

Post by gpderetta » Thu, Dec 02, 2021, 1:29 PM UTC

ummonk wrote: post #200

openasocket wrote: post #92

Earlier quoted context omitted.

There's different classes of memory un-safety: buffer overflow, use after free, and double free being the main ones. We haven't seen a mainstream language capable of preventing use and free and double free without GC overhead until Rust. And that's because figuring out when an object is genuinely not in use anymore, at compile time, is a really hard problem. But a buffer overflow like from the article? That's just a…

As far as I know, nothing in the C/C++ standard precludes fat pointers with bounds checking. Trying to access outside the bounds of an array is merely undefined behavior, so it would conform to the spec to simply throw an error in such situations.

There's address-sanitizer, although for ABI compatibility the bound is stored in shadow memory, not alongside the pointer. It is very expensive though. A C implementation with fat pointer would probably have significantly lower overhead, but breaking compatibility is a non-starter. And you still need to deal with use-after-free.

Re: This shouldn't have happened: A vulnerability postmortem

#424

Post by pjmlp » Thu, Dec 02, 2021, 1:35 PM UTC

nineteen999 wrote: post #410

FeepingCreature wrote: post #333

Earlier quoted context omitted.

I don't think this is fair. First-mover advantage is absolutely a thing at the ecosystem level.

There were plenty of first movers before UNIX and C, and later C++. They didn't stick. Now, step up to the plate and fix it.

It is hard to stick against free beer OS, available with source code.

Had UNIX been a comercial endevour and it would have failed, unfortunely it wasn't the case, and now C plagues the industry.

Re: This shouldn't have happened: A vulnerability postmortem

#425

Post by pjmlp » Thu, Dec 02, 2021, 1:38 PM UTC

gpderetta wrote: post #419

CJefferson wrote: post #378

Earlier quoted context omitted.

The default [] for vector doesn't do bound checking, so I don't feel it helps they much. One thing in practice I like about Rust over C++ is the "easy option" is safe, and you have to do things like write 'unsafe' to opt out of safety. Certainly when teaching C++ I wish the defaults were safer. I can teach ".at", but it isn't what you see in most code / tutorials.

-D_GLIBCXX_ASSERTIONS

Good luck advocating for that on release code.

Re: This shouldn't have happened: A vulnerability postmortem

#426

Post by pjmlp » Thu, Dec 02, 2021, 1:40 PM UTC

adrianN wrote: post #286

titzer wrote: post #275

Earlier quoted context omitted.

The whole post is a giant blinking red sign that says (or should say) "Fuzzing is a horribly ineffective workaround for a treacherous language." No offense to the many bright and capable people who have worked hard on the C/C++ language, tools, compilers, libraries, kernels, etc over the years, but we will someday look back on it as asbestos and wonder why we kept at it for so damn long .

Unfortunately it's too much work to throw away all code written in unsafe languages. So it's valuable to try and improve tools and techniques that make these languages less unsafe.

One reason why we are getting hardware memory tagging to transform modern computers into basically C Machines, is that everyone kind of gave up doing it at sofware level in regards to C and C++.

Re: This shouldn't have happened: A vulnerability postmortem

#427

Post by pjmlp » Thu, Dec 02, 2021, 1:44 PM UTC

xiphias2 wrote: post #59

slownews45 wrote: post #39

Earlier quoted context omitted.

What's somewhat interesting is memory safety is not a totally new concept. I wonder if memory safety had mattered more, whether other languages might have caught on a bit more, developed more etc. Rust is the new kid, but memory safety in a language is not a totally new concept. The iphone has gone down the memory unsafe path including for high sensitivity services like messaging (2007+). They have enough $ to re-wri…

Memory safe language that can compete with C/C++ in performance and resource usage is a new concept. AFAIK ADA guarantees memory safety only if you statically allocate memory, and other languages have GC overhead. Rust is really something new.

What new concept? When C and C++ appeared they were hardly usefull for game development, hence why most games were coded in Assembly.

After C, alongside TP, got a spot on languages accepted for game development, it took about 5 years for C++ to join that spot, mostly triggered by Watcom C++ on the PC, and PS2 SDK.

There was no GC overhead on the systems programming being done in JOVIAL, NEWP, PL/I,...

Re: This shouldn't have happened: A vulnerability postmortem

#428

Post by pjmlp » Thu, Dec 02, 2021, 1:47 PM UTC

Enhex wrote: post #260

slownews45 wrote: post #13

Wow. We continue to be reminded that it's hard to write fully memory secure code in a language that is not memory secure? And by hard, I mean, very hard even for folks with lots of money and time and care (which is rare). My impression is that Apple's imessage and other stacks also have memory unsafe languages in the api/attack surface, and this has led to remote one click / no click type exploits. Is there a point a…

this is C code. stuff like void*, union and raw arrays do not belond in modern C++. while C++ is compatible with C it provides ways to write safer code that C doesn't. writing C code in a C++ project is similar to writing inline assembly.

Here, https://android.googlesource.com/platform/ndk/+/refs/heads/m...

Re: This shouldn't have happened: A vulnerability postmortem

#429

Post by pjmlp » Thu, Dec 02, 2021, 1:48 PM UTC

nickelpro wrote: post #95

zionic wrote: post #22

Earlier quoted context omitted.

C/C++ don’t really have “benefits”, they have inertia. In a hypothetical world where both came into being at the same time as modern languages no one would use them. Sadly, I’m to the point that I think a lot of people are going to have to die off before C/C++ are fully replaced if ever. It’s just too ingrained in the current status quo, and we all have to suffer for it.

On any given platform, C tends to have the only lingua franka ABI. For that reason it will be around until the sun burns out.

On Android, ChromeOS, IBM i, z/OS, ClearPath it isn't.

Re: This shouldn't have happened: A vulnerability postmortem

#430

Post by scoutt » Thu, Dec 02, 2021, 1:51 PM UTC

pornel wrote: post #417

scoutt wrote: post #396

Earlier quoted context omitted.

Please.... https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust I read "double free", "denial of service", "out-of bounds read", "NULL pointer dereference", etc... And that's a list of vulnerabilities found for a language that is barely used compared to C/C++ (in the real world). It won't change. C/C++ dominates and will dominate for a very long time.

You need to read the list more carefully. • The list is not for Rust itself, but every program ever written in Rust. By itself it doesn't mean much, unless you compare prevalence of issues among Rust programs to prevalence of issues among C programs. Rust doesn't promise to be bug-free, but merely catch certain classes of bugs in programs that don't opt out of that. And it delivers: see how memory unsafety is rare co…

> The list is not for Rust itself, but every program ever written in Rust.

This is, I think, obvious unless you are talking about C/C++ compiler bugs (which I am not).

But if you think it that way, the same happens with C/C++! Besides compiler bugs, the published CVEs for C/C++ "are not for C/C++ itself, but every program ever written in C/C++".

Still, potential severe vulnerabilities in Rust stdlib can happen too (https://www.cvedetails.com/cve/CVE-2021-31162/ or https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3631...), so there is a blurry limit between "a bug is in Rust" or not.

> unless you compare prevalence of issues among Rust programs to prevalence of issues among C programs.

I don't know but you mention an interesting PoV. Do you propose to compare the ratio of total quantity of code EVER written in C/C++ and the numbers of "issues" found? Compared to the quantity of "issues" per code EVER written in Rust?

I guess nobody can figure out those numbers, but if I have to guess, then the ratio of total "Quantity of code"/"issues" will be in favor of C/C++.

I don't want to discuss the cause/reason of those Rust vulnerabilities, but the message I read is: "unaware programmers can still introduce potential UAF, double-free, read uninitialized memory, dereference NULL pointers, etc. Just like with C/C++ but just in smaller quantities".