This shouldn't have happened: A vulnerability postmortem

Post by pjmlp » Thu, Dec 02, 2021, 7:48 AM 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 .

Post by foobiekr » Thu, Dec 02, 2021, 7:51 AM UTC

saagarjha wrote: post #307

foobiekr wrote: post #269

Earlier quoted context omitted.

I don’t disagree with you. But just before writing that message I was code reviewing some python that was vulnerable a to the most basic SQL injection. Who needs or wants execution authority when you can dump the users table of salted sha passwords?

In C you can just use code execution to grab the passwords before they get salted…

Post by pjmlp » Thu, Dec 02, 2021, 7:54 AM UTC

snovv_crash wrote: post #331

sebcat wrote: post #325

Earlier quoted context omitted.

It wouldn't cause the problem in itself perhaps, but I find it a bit reductive to look at the type in isolation like that. Sometime, somewhere, someone will call std::vector ::data on that vector and use the resulting pointer as the src argument to memcpy (or some other function), and someone else will make a change that causes an overflow of the dst buffer. Shit happens and code written in modern C++ also has bugs a…

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.

Post by pjmlp » Thu, Dec 02, 2021, 7:59 AM 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.

Post by avar » Thu, Dec 02, 2021, 8:05 AM UTC

shakna wrote: post #124

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…

> That's just a matter of saving the length of the array alongside the pointer and doing a bounds check, which a compiler could easily insert if your language had a native array type. Pascal and its descendants have been doing that for decades. GCC has also had an optional bounds checking branch since 1995. [0] GCC and Clang's sanitisation switches also support bounds checking, for the main branches, today, unless th…