News for hackers. Stuff that matters.
Re:This shouldn't have happened: A vulnerability postmortem by lenkite on Thursday December 02, 2021 @01:09AM (#29413056)
Is it OK to remove modern C++ from your statement ? Using a `std::vector<std::byte>` wouldn't cause this problem. Don't know why everyone always berates C++ for vulnerabilities in traditional C code.
Re:This shouldn't have happened: A vulnerability postmortem by sebcat on Thursday December 02, 2021 @02:05AM (#29413365)
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<T,Allocator>::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 and some of those bugs have security implications.
Re:This shouldn't have happened: A vulnerability postmortem by Animats on Thursday December 02, 2021 @02:19AM (#29413427)
Sometime, somewhere, someone will call ...

I call this the mold seeping through the wallpaper. C++ tries to paper over C's terrible array model by using collection class templates, but those constructs leak. Too many things need raw pointers.

Re:This shouldn't have happened: A vulnerability postmortem by snovv_crash on Thursday December 02, 2021 @02:23AM (#29413449)
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.
Re:This shouldn't have happened: A vulnerability postmortem by staticassertion on Thursday December 02, 2021 @09:16AM (#29416320)
> The same thing would happen in Rust if you tried to pass a chunk of memory to C.

In an 'unsafe' block.

Re:This shouldn't have happened: A vulnerability postmortem by snovv_crash on Thursday December 02, 2021 @10:54AM (#29417684)
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 by staticassertion on Thursday December 02, 2021 @11:02AM (#29417845)
The very first thing you would do is audit for 'unsafe' though.
Re:This shouldn't have happened: A vulnerability postmortem by snovv_crash on Friday December 03, 2021 @06:16AM (#29428762)
Assuming you ever encounter the issue, sure. But this bug was only triggered by long keys, which are outside of the normal operating paradigms. So your Rust code calling into a C API would have had exactly the same security vulnerability as C++.

On the other hand, something like Java via JNI wouldn't, because it copies the data to a different address space as it goes through the language boundary. Horribly inefficient, but at least the C code only causes security issues in the C regions. By the time it gets back into Java it either crashes or it's safe again, no undefined behaviour leaks through the API boundary.

Re:This shouldn't have happened: A vulnerability postmortem by staticassertion on Friday December 03, 2021 @12:25PM (#29432540)
Copying the data before the FFI boundary would have done absolutely nothing to prevent this bug or make it any less difficult to exploit tho
Re:This shouldn't have happened: A vulnerability postmortem by pjmlp on Thursday December 02, 2021 @02:54AM (#29413597)
True, except the code will be tainted and it is easy to find it.
Re:This shouldn't have happened: A vulnerability postmortem by snovv_crash on Thursday December 02, 2021 @10:56AM (#29417727)
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 by pjmlp on Thursday December 02, 2021 @11:09AM (#29417952)
In Rust, or any other systems programming language with unsafe code blocks, all the way back to JOVIAL and ESPOL, one can search for those code blocks.

At very least they provide an initial searching point.

On C, C++ and Objective-C, any line of code is a possible cause for memory corruption, integer overflow, or implicit conversions that lead to data loss.

Re:This shouldn't have happened: A vulnerability postmortem by snovv_crash on Thursday December 02, 2021 @12:12PM (#29419030)
This is starting from the point of knowing it is a memory corruption issue though. From my experience, memory corruption usually manifests in logic or data behaviour changes. In a Rust program you'd probably spend a few days pulling your hair out trying to understand why some data structure doesn't do what it's supposed to before considering that it's one of the unsafe blocks.
Re:This shouldn't have happened: A vulnerability postmortem by pjmlp on Friday December 03, 2021 @02:36AM (#29427581)
Yeah, but at least you know where to start searching afterwards.

This applies to other languages with unsafe code blocks, note that JOVIAL and ESPOL were the first ones offering such capability.

Re:This shouldn't have happened: A vulnerability postmortem by pjmlp on Thursday December 02, 2021 @02:53AM (#29413590)
It would, because ISO std::vector<std::byte> doesn't do bounds checking by default unless you turn on the compiler checks in release builds, use at() everywhere, or create you own `std::checked_vector<std::byte>`.
Re:This shouldn't have happened: A vulnerability postmortem by CJefferson on Thursday December 02, 2021 @04:56AM (#29414313)
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.

Re:This shouldn't have happened: A vulnerability postmortem by gpderetta on Thursday December 02, 2021 @08:19AM (#29415721)
-D_GLIBCXX_ASSERTIONS
Re:This shouldn't have happened: A vulnerability postmortem by pjmlp on Thursday December 02, 2021 @08:38AM (#29415923)
Good luck advocating for that on release code.
Re:This shouldn't have happened: A vulnerability postmortem by flohofwoe on Thursday December 02, 2021 @05:18AM (#29414436)
People who memcpy bytes into a destination without caring if there's enough room would also not hesitate to use memcpy to copy bytes into a std::vector though.
Re:This shouldn't have happened: A vulnerability postmortem by lenkite on Saturday December 04, 2021 @04:00PM (#29444269)
Re:This shouldn't have happened: A vulnerability postmortem by raverbashing on Thursday December 02, 2021 @02:33AM (#29413484)
> Using a `std::vector<std::byte>`

And herein lies the problem. Your statement is correct. But that type definition is exactly why C++ feels like a 50's car retrofitted with an electric drivetrain and a DVD player on the dash

It will almost run like a modern thing but it will fail when it shouldn't.