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

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

#441

Post by staticassertion » Thu, Dec 02, 2021, 2:38 PM UTC

shadowgovt wrote: post #440

staticassertion wrote: post #421

Earlier quoted context omitted.

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…

I think it probably makes sense that the languages it's easiest to write code in would dominate in an ecosystem where incentives are encouraging software to eat the world. The asbestos comparison is pretty apt. Possibly also apt would be steel plants. Yes, steel manufacture is extremely hard on the local environment. Doesn't matter. The world's in the middle of an industrial revolution, and we need steel now. Now now…

> Given the factors involved (private ownership of language resources, complex runtime putting minimum requirements on hardware, etc.), C and C++ might be the only two paths of least resistance for a critical era of the software industry.

Maybe! We'll never know. I just don't think that rewriting history to be "C people were doers" is giving any meaningful context to language development, or how much was getting done in languages that were significantly safer.

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

#442

Post by scoutt » Thu, Dec 02, 2021, 2:45 PM UTC

native_samples wrote: post #398

nineteen999 wrote: post #300

Earlier quoted context omitted.

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 that's actually true. I think it's rather than the market rewards performance above security. Let's see: is there a mature, maintained TLS stack written in a memory-safe, high performant, cross platform language that Mozilla could have been using for free, instead of NSS? Your argument is that there isn't one because only C++ coders are "doers" instead of "talkers" but this argument is wrong because suc…

Sincerely, as a C/C++ programmer, if I have to start a new project and you propose to link a Java library, it'd give me the creeps. Let's say I agree: does my project now requires to install a Java VM together with my project? Which Java VM? I still don't understand the difference between OpenJDK and the "other one"... JDK? JRE? I only installed it once many years ago because Eclipse CDT required it and I might have wrote "sudo update-java-alternatives --set /path/to/java/version" one too many times (AOSP development).

OK. I'll make an installer to install Java with my project. But the customer has another older version, or a competitor version, or ..... I don't care anymore.

Do I have to build this library? What paraphernalia do I have to install and learn to automatize, build and test a complex Java library? Do I have to maintain a JNI interface too?

Where is the JCA/JSSE source code? (I can't find it for real) And who maintains it? Oracle? What if Oracle one day pulls the plug or comes after me with one of their famous legal moves just because?

These are my concerns. You might try to convince me, but I already learnt about C/C++ libraries, DLL hell, etc, and have all my fixes in place.

> Bugs happen

They will still happen. Put your heart at peace.

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

#443

Post by shadowgovt » Thu, Dec 02, 2021, 3:10 PM UTC

staticassertion wrote: post #441

shadowgovt wrote: post #440

Earlier quoted context omitted.

I think it probably makes sense that the languages it's easiest to write code in would dominate in an ecosystem where incentives are encouraging software to eat the world. The asbestos comparison is pretty apt. Possibly also apt would be steel plants. Yes, steel manufacture is extremely hard on the local environment. Doesn't matter. The world's in the middle of an industrial revolution, and we need steel now. Now now…

> Given the factors involved (private ownership of language resources, complex runtime putting minimum requirements on hardware, etc.), C and C++ might be the only two paths of least resistance for a critical era of the software industry. Maybe! We'll never know. I just don't think that rewriting history to be "C people were doers " is giving any meaningful context to language development, or how much was getting don…

I agree. The thing of interest here, I think, is the observation that language popularity is path-specific. JavaScript is just the worst, but everyone who does browser work has to know it because it happened to be the language clapped together to demo some nifty ideas for extending HTML and then those ideas stuck. Alternatives to JavaScript existed but were either privately-owned and therefore not trusted (vbscript) or too complicated to get off the ground (at some point, Mozilla had a fascinating proposal for HTML pages selecting features of the rendering engine and possibly even declaring that the whole page should be interpreted via user-definable code modules; had this won the day, you could write you web page in LaTeX for all anybody cared, but no-one was going to invest the time to write a dozen rendering agents when the HTML one was already expensive to develop and keep stable).

"C people were doers" is probably reductive, but C and C++ had an alchemy of factors that made something like, say, LISP or Erlang not be where they are.

If I had to hazard a guess, I'd say the most dominant factors are the language runtime's portability, the language's features allowing for relatively low-level access to the backing hardware (i.e. the thinness of the abstraction between C memory access and microprocessor read-write instructions means things like memory maps or "magic addresses" that trigger hardware effects on mutation could just be handed to user code), and the compatibility of the runtime with what came to be (for a ton of reasons) a dominant model of computation in the commercial and consumer space: the x86 architecture.

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

#444

Post by staticassertion » Thu, Dec 02, 2021, 3:16 PM UTC

shadowgovt wrote: post #443

staticassertion wrote: post #441

Earlier quoted context omitted.

> Given the factors involved (private ownership of language resources, complex runtime putting minimum requirements on hardware, etc.), C and C++ might be the only two paths of least resistance for a critical era of the software industry. Maybe! We'll never know. I just don't think that rewriting history to be "C people were doers " is giving any meaningful context to language development, or how much was getting don…

I agree. The thing of interest here, I think, is the observation that language popularity is path-specific. JavaScript is just the worst, but everyone who does browser work has to know it because it happened to be the language clapped together to demo some nifty ideas for extending HTML and then those ideas stuck. Alternatives to JavaScript existed but were either privately-owned and therefore not trusted (vbscript)…

I would guess that a huge part of C's popularity is UNIX. I think a number of other languages could have easily competed in the other areas ie: thin abstraction.

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

#445

Post by blub » Thu, Dec 02, 2021, 3:21 PM UTC

davedx wrote: post #368

blub wrote: post #357

Earlier quoted context omitted.

Before I ditched Windows a couple of years ago, I was able to experience first hand how bloated and slow was the software that Microsoft rewrote in C#, so I kind of understand why such rewrites were being sabotaged. If by some minor miracle a C# or Java GUI app is not slow, then it will use a ton of memory. A whole OS of such apps would be a nightmare.

You literally mention Java GUI apps in response to a post that calls out Android, a mobile OS and application ecosystem implemented in Java . The languages are not the issue.

It took Google more than a decade of trying and a VM rewrite to get close to the perceived performance of iOS.

And anything performance intensive was done in the NDK anyway.

All of this because of Java.

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

#446

Post by wheelerof4te » Thu, Dec 02, 2021, 3:43 PM UTC

titzer wrote: post #275

lucb1e wrote: post #8

A title that actually describes the post, mostly paraphrasing the first paragraph: Reasons why this buffer overflow wasn't caught earlier despite doing all the right things And then to give those reasons: - "each component is fuzzed independently" ... "This fuzzer might have produced a SECKEYPublicKey that could have reached the vulnerable code, but as the result was never used to verify a signature, the bug could ne…

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 .

C ABI is still stable after all these years. Programs written in "The C Programming Language" bible still compile and work fine.

That's why.

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

#447

Post by snovv_crash » Thu, Dec 02, 2021, 3:54 PM UTC

staticassertion wrote: post #436

snovv_crash wrote: post #331

Earlier quoted context omitted.

You're just talking about more C interfaces, not C++. The same thing would happen in Rust if you tried to pass a chunk of memory to C.

> The same thing would happen in Rust if you tried to pass a chunk of memory to C. In an 'unsafe' block.

The memory corruption would happen in the C code though. By the time that the program is actually affected by the memory error it could be much later, back in Rust code, and now you don't have any tools for debugging memory corruption because "that never happens in Rust".

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

#448

Post by snovv_crash » Thu, Dec 02, 2021, 3:56 PM UTC

pjmlp wrote: post #345

snovv_crash wrote: post #331

Earlier quoted context omitted.

You're just talking about more C interfaces, not C++. The same thing would happen in Rust if you tried to pass a chunk of memory to C.

True, except the code will be tainted and it is easy to find it.

Memory corruption doesn't always trigger segfaults. I don't believe it will be obvious why some random other part of your program will start giving intermittent errors even if it is in Rust.

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

#449

Post by jstimpfle » Thu, Dec 02, 2021, 3:59 PM UTC

pornel wrote: post #404

jstimpfle wrote: post #193

Earlier quoted context omitted.

One complication is that it's not just about ABIs but at least as much about APIs. And C headers often make some use of the preprocessor. Usage of the preprocessor often even is part of the API, i.e. APIs expose preprocessor macros for the API consumer. Zig has a built-in C compiler and supposedly you can just "include " from within a Zig source file. Rust has a tool called bindgen. There are other tools, I haven't t…

The Windows meta-API thing is done: https://lib.rs/windows We'll probably continue using C headers as a poor ABI definition format, even without writing programs in C. Sort-of like JSON used outside of JavaScript, or M4 known as autoconf syntax, rather than a standalone language. But C headers as an ABI definition format are overcomplicated and fragile (e.g. dependent on system headers, compiler-specific built-in def…

Not disagreeing about the issues of header files and the difficulty of consuming them from other languages (which was my point).

But regarding ABI definitions, I suspect that introducing "thread-safety information, machine-readable memory management, explicit feature flags" will make interopability at the binary level difficult or impossible, which is even worse.

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

#450

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

snovv_crash wrote: post #447

staticassertion wrote: post #436

Earlier quoted context omitted.

> The same thing would happen in Rust if you tried to pass a chunk of memory to C. In an 'unsafe' block.

The memory corruption would happen in the C code though. By the time that the program is actually affected by the memory error it could be much later, back in Rust code, and now you don't have any tools for debugging memory corruption because "that never happens in Rust".

The very first thing you would do is audit for 'unsafe' though.