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.
[ Parent
| on HN ]
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.