Linux 6.1 Feature Would Have Caught All memcpy Based Buffer Overflows Of Recent Years

[phoronix]

Phoronix: Linux 6.1 Feature Would Have Caught All memcpy Based Buffer Overflows Of Recent Years

A kernel hardening security improvement on the way for Linux 6.1 is the ability to provide warning of possible memcpy() based overflows. Right now this is only a warning but it's work towards being able to address "trivially detectable" buffer overflow conditions within the kernel and in the future may be able to block such overflows from happening...

https://www.phoronix.com/news/Linux-6.1-Memcpy-Dynamic-Warn

[kylew77]

Could do what OpenBSD did with Bluetooth and just not have a Bluetooth stack because it is too much of a security risk, lol.

[sinepgib]

Could do what OpenBSD did with Bluetooth and just not have a Bluetooth stack because it is too much of a security risk, lol.

Why settle for less? Let's not have memcpy either.

[ryao]

I suspect there are plenty of false positives from filesystem code. Things like filesystem logging/journaling are not going to be using nicely defined structures. There will be zero length fields for things like names and beyond that you will find data being placed.

[bug77]

This would have caught all of the memcpy()-based buffer overflows in the last 3 years, specifically covering all the cases where the destination buffer size is known at compile time.

I'd expect more rigor from a programmer.
While I don't know the internals of the Linux kernel, for generic code this would have caught less than half of the overflows, since what's usually being copied are lists that grow dynamically.
But hey, a(nother) tool to slap our wrists when not playing nicely is always welcome.

[Jannik2099]

So the kernel is finally getting basic safety that literally every other programming language had for decades...

This could've been avoided back then with C++, but at least we're getting Rust now.

[oiaohm]

So the kernel is finally getting basic safety that literally every other programming language had for decades...

This could've been avoided back then with C++, but at least we're getting Rust now.

Really this answer is no. Not all would have been prevented by using C++ instead of C. C++ has the issue of not tracking allocated memory length as well coded into the language.

https://www.cisa.gov/uscert/bsi/arti...c-std---string

The std::string generally protects against buffer overflow, but there are still situations in which programming errors can lead to buffer overflows. While C++ generally throws an out_of_range exception when an operation references memory outside the bounds of the string, the subscript operator [] (which does not perform bounds checking) does not [Viega 03].

The C++ solution in the language is imperfect. The reality here you still need something like FORTIFY SOURCE when dealing with C++ to catch coder mistakes. What has been implemented here is a feature that in userspace you would perform by valgrind or equal tool.

Lot of same issues that happen in C++ can happen in rust without its borrow checker validating rust code as well. C++ language can reduce the issues not cure them. Rust reduces the issues even more but is also not 100 percent cure there are ways to create loopholes.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

Cheri is example of building something with valgrind like checks into the CPU instruction set and the silicon.

The reality these problems have been going on for decades. The overhead to fix the issue correctly people have not been willing to put up with. Yes silicon or software runtime checking.

Yes even with rust there will be code where the Fortify Source/valgrind/silicon runtime checks will be required to locate all the memory defects coders have made.

[coder]

The C++ solution in the language is imperfect. The reality here you still need something like FORTIFY SOURCE when dealing with C++ to catch coder mistakes. What has been implemented here is a feature that in userspace you would perform by valgrind or equal tool.

FYI, compilers can now insert sanitizers to do similar things as valgrind, but with more potential to catch overruns of stack-allocated data structures. They do come at substantial cost (mostly runtime, but also build time), so I'm not claiming they're a perfect solution. Most release builds won't use them. They are lower-overhead than valgrind, at least.

As for std::string access, random-access C++ containers (including strings) support the at() member function, for doing range-checked access when the programmer wants a runtime check. Leaving this up to programmer discretion means they're often not used when they're actually needed.

https://en.cppreference.com/w/cpp/st...asic_string/at

Of course, that's STL, not the core C++ language. The kernel wouldn't use STL, but would doubtless have some classes of its own.

If you wanted, you could embed range-checking into the [] operator of your containers. So, that leaves is raw pointer accesses/offsets as unprotected. And there, C++ offers the notion of a pointer that's not supposed to be NULL (although they actually can be, in practice), called a "reference" (denoted as &), which can help you figure out which you should check against null, before accessing them. C++ also makes it easy to pass a pointer + range, in case you also want to do range-checked accesses (e.g. std::string_view).

So, it provides one with the tools to write safe code that's easy to understand & maintain. The question is really one of how ambitious you want to be.

C++ language can reduce the issues not cure them.

C++ & STL reduces string bugs by making many string operations much simpler, and heap allocation trivial. That cuts way down on the number of fixed-sized string buffers allocated on the stack (a plague of C code), which present most of the more ripe opportunities for buffer overrun exploits.

[oiaohm]

As for std::string access, random-access C++ containers (including strings) support the at() member function, for doing range-checked access when the programmer wants a runtime check. Leaving this up to programmer discretion means they're often not used when they're actually needed.

Yes that the big thing programmers will fail to put the checks in the right places.

C++ reduces string bugs by making many string operations much simpler and heap allocation trivial. That cuts way down on the number of fixed-sized string buffers allocated on the stack, which present the more ripe opportunities for buffer overrun exploits.

That something that need to be taken with a grain of salt.
Does items std::string in fact make it simpler?
1) again you are depending on program to use the std::string and to use the at feature when they should.
2) generated code wise its not simpler or at least not as simple as it could be.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ You do need to look at cheri here. Cheri is new but there was something historic equal remember how arm processes could run java byte code. Simple thing here all pointers are two pointers with cheri. One pointer has the allocation information and One pointer has where the operation is going to happen. So C operation in cheri system is safe because the bounds checking is mandatory. Yes the history java byte code interpreters in arm processors also had bounds checking as mandatory.

FORTIFY SOURCE is will in time come bounds checking is mandatory if it enabled.

The reality here is there is a huge stack of bugs that don't need to exist. The problem we have not been willing to pay the cost to be rid of them. C++ standard library is design to reduce the faults not 100% elimination. Rust with it borrow checker is closer to 100% elimination.

Think about we don't attempt in software to replicate hardware ECC because in reality its too performance costly. Items like cheri or the old arm hardware based bound checking used with the java byte code processing has less than 0.1% performance cost. So bound checking is really cheap performance wise if it implemented in hardware.

Implement in software bound checking is not that cheap. Hard reality is nothing forbid mandatory bounds checking with C.

Reality here is nothing about C Standard ever forbid pointers from containing two values that the cheri trick they simple define that pointers had to have two pointer values one is the pointer address the other is the allocation. Yes in the ISA with cheri there is a duplication of registers. So you have pair of registers one of the pair contains the value we know that is the old address pointer value and the other has pointer to the allocation that has the size of the allocation. Yes this is a old solution. None of this requiring programmers to use the correct size of buffer or any thing else to prevent problems.

Funny right the reason why strcpy and the like is unsafe is because the define of pointer we use with C and C++ .... is lacking information. So instead of creating new class and all the things C++ does just make pointers little bit more descriptive.

[stormcrow]

Could do what OpenBSD did with Bluetooth and just not have a Bluetooth stack because it is too much of a security risk, lol.

Sure they could. Nothing stops you from disabling Bluetooth in firmware settings. But there happens to be a reason why OpenBSD isn't as common an OS as Linux: "My way or the highway" ultimatums just piss most people off who will in turn tell you to shove it. Security beyond a certain point becomes tyranny. Where that point is differs between individuals, but generally speaking, just ignoring a feature because you don't like it (like Theo did with WIFI for years) is bound to not win you any converts. In the end he got overruled by other developers that wanted the convenience of WIFI networking with reasonable security protocols.

That comes from someone that does use OpenBSD as a secondary system. I continually get irritated by their "principled stands" that amount more to posturing than any practical or proven security measures or vulnerabilities.