Slashdot Mirror
Microsoft Open-Sources 'Checked C,' A Safer C Version (softpedia.com)
An anonymous reader writes from a report via Softpedia: Microsoft has open-sourced Checked C, an extension to the C programming language that brings new features to address a series of security-related issues. As its name hints, Checked C will add checking to C, and more specifically pointer bounds checking. The company hopes to curb the high-number of security bugs such as buffer overruns, out-of-bounds memory accesses, and incorrect type casts, all which would be easier to catch in Checked C. Despite tangible benefits to security, the problem of porting code to Checked C still exists, just like it did when C# or Rust came out, both C alternatives.
strcpy_s is part of the C11 standard, and it was a library addition, not a language change.
This won't gain traction until it's compatible with the C99 and C11 standards.
how the heck are you gonna shoehorn this into standard C? We are talking about restricting what the programmer can do, there's NO WAY you can achieve bounds checking behavior without breaking existing C behavior, because "broken" programs with bounds checking problems are "perfectly acceptable" C.
My ism, it's full of beliefs.
That's it, I've had enough. I'm going back to Turbo Pascal.
The CPU just needs to set aside an area of memory exclusively for return addresses, and make that protected. No more security issues, buffer overruns, execution of arbitrary code. The real problem is that return addresses are mingled with other data. This should be solved at the hardware level, and AFAICS, it could be done totally transparently to code, even binaries.
The funny little known fact is: C99 already has a bounded pointer type: A pointer to a variable-length array.
void foo(int N, char (*ptr)[N]) // undefined behaviour
{
(*ptr)[N + 3] = 10;
}
Using the undefined-behaviour sanitizer, you can also have the compiler add automatic checks.
That's the right direction. Apple already has a pretty good version of it. (See below.)
Bounds checking C like this now is weak and very, very late:
https://gcc.gnu.org/ml/gcc/199...
https://www.lrde.epita.fr/~aki...
http://blog.qt.io/blog/2013/04...
http://valgrind.org/docs/manua...
https://en.wikipedia.org/wiki/...
But the grand champion memory debugger is the Mac OS X standard malloc libraries. You can simply set environment variables and instantly get better debugging than most methods on all other platforms. I presume this is because Objective C/C++ is such a pain to debug that they just built in features to always be available, even for production apps.
http://www.cocoawithlove.com/2...
Those libraries are clever because when debugging array bounds corruption and used/free, all mallocs get their own mmapped memory block surrounded by unmapped memory. Plus writing patterns into free / allocated memory to detect writing to freed memory, etc. This is great because it triggers a system signal that debuggers can catch deterministically.
I found and used those techniques on my last big project a couple years ago. The Windows desktop app and imaging C++ libraries were full of errors, memory corruption, struct and 32bit/64bit problems, etc. I had to do a lot of debugging and rewriting to port to Mac OS X, then a lot to solve corruption and threading issues. And found out, the hard way, what a mess the "standard" pthreads API / libraries were. Just spurred me on to switch to C++11 to have standard threads. This Mac OS X built-in debugging along with gdb made it a snap to find all of those kinds of errors, even for code meant for Android, Linux, and Windows.
Stephen D. Williams
As yet, nobody has made an OS that isn't C at the bottom. There's a reason for that. Although there are projects that claim it's now possible, not one major operating system uses them for kernel programming.
And wrappers like this have existed since the first day of C. You can always wrap your own memory and pointer management functions and structures and just expect people to use them. They come with a performance cost, and wrapping C means people can only use your wrappers. Even this, which claims compatibility, basically just introduces two new pointer "types" which can't be dereferenced in the normal way.
It's not that this has been impossible forever and people are only just going "Oh, maybe we should do something". It's been this way because there are things that you need to take account of still. And though security is certainly a high-priority, a system that runs dog-slow, isn't compatible with other APIs, has to have tricks all over it to make it work, and ultimately still has to end up with hardware pointers where the bounds are set by the programmer (as here) means that it won't get used at all.
There's a reason that even "theoretical" OS like MINIX still use C and pointers. At the OS level, hardware access needs unbounded pointers or pointers that only the programmer knows the bounds of. Basically, bang, security problem if they use them wrong.
Even ordinary applications made in pointer-managed languages have to - by definition - include more checks and code than those that don't. I'm not saying those checks aren't worthwhile, or don't stop security problems, but there is still yet to be a serious OS or even low-level drivers written in anything other than C.
And people speak as if, if we were to all just move to Rust or whatever (which also includes its own pointer types including a special insecure "unbounded" pointer - wonder why that is even in there, hmm?) that all the security problems would magically disappear. Unfortunately it's not like that.
It's about eliminating human error and there's a lot that can go wrong with pointer arithmetic and lack of checks. But that human error is present whether or not a pointer is used. Most of the time the problem is lack of bounds checking - that, in any language, can lead to serious problems like crashes, acting on incorrect data, getting into infinite loops, etc.
The problem is that the one part you NEED that kind of balance, deep in the kernel rings where you're using drivers and low-level memory access outside of the normal protections, you don't have it available as the hardware needs real pointers to be manipulated in order to operate.