FreeRADIUS fragged by fuzzer – by invitation – and fifteen fails found The folks over at FreeRADIUS took a look at Guido Vranken's work with OpenSSL, liked what they saw, asked him to fuzz the famous login/security server ... and then didn't like what they saw. Pretty much anybody who's logged into an ISP account has touched FreeRADIUS, since it's the most popular implementation of the venerable …
“C is a terrible language for security”.
Only if written wrong...
RUST is looking quite cool. There's a growing and strong argument in favour of re-writing lots of stuff in it.
There's a whole OS (redox?) coming along nicely, with a kernel written in RUST. The speed with which it's been written is pretty impressive.
The language seems to be a happy balance between ideas taken from high level languages and being a suitable systems language.
It's not standardized and does not have a specification. This means it's going to be very, very difficult to get it adopted within safety-related. The same should also be true for security-related.
Without a standard and/or specification, it's going to be very difficult to prove that the language is correct and robust. It will contain (at least) undefined and unspecified behaviours, and these need to be known so that they can be avoided and tools can be used to ensure that they aren't invoked.
What's really needed is a decent, fully-specified language with robust compiler support. Such languages do exist, but they are considered "too hard" to use by the masses.
A long program of static tests – the post name-checks Coverity, Clang analyser, cppcheck, and PVS-Studio – clearly hasn't been enough to turn up all the bugs, which arise because “C is a terrible language for security”.
C is an excellent language for security and for systems that need to be fast and efficient. C++ on the other hand is a lousy language to debug because people who write in C++ tend not to know how to write clean code and there are better OO languages around. (Objective-C as an example.)
Today most coders are like drivers, and those that can code in C are like professional race car drivers. You can put a professional driver in your average car and they can drive. You try putting an average driver in an F1... boom.
... if you're a security consultant and earn money from all the security issues in C code.
Keep on believing C coders are the best because C is the language god coded the world with, reality actually shows they aren't.
C was designed to be fast and to make compiler "simpler", it was never meant to be safe, and still lacks a lot of features that could make it more robust, but because they would break with "tradition", are saw as heresies.
Quite. Consider the following:
void freeSecurityBuffer( char * pBuffer, size_t len )
{
( void ) memset ( pBuffer, 0, len );
free ( pBuffer );
}
This probably doesn't do what the programmer thought it would (erase a buffer before it is returned to the heap).
"This probably doesn't do what the programmer thought it would (erase a buffer before it is returned to the heap)."
I'd expect the possibility of memset() being optimised away by the compiler, so I'd use something else. How about you?
If you use a sharp tool it's your own responsibility to avoid cutting yourself.
Spoken like a person who never mastered the C language.
If you've never learned to code in C, then you'll never be a jedi master.
Said as an old Jedi Master who's written a couple of C programs/apps and an embedded OS still in use today around the world.
I routinely code in C and other languages (I learnt first using assembly...), that's why I'm not blind to the many C shortcomings when it comes to security. It wasn't ever designed with security in mind, in an era with slow CPU and very little RAM, when being small and fast was of paramount importance.
Jedi master? That's exactly the wrong attitude, "we're superior because we code in C, the language of the true elite". There's a reason, after all, why all the Jedi died.
Sure, by carefully writing each and every line in C you can end up with a good application, after a long time, and then comes a fuzzer and finds fifteen bugs in a few hours.
A fuzzer is not exactly your average profiler or static code analyzer... and I wish to know how many projects actually do profile and analyze code properly. A fuzzer is another step, and may be not easy to use and then inspect the results.
C is as good at security as the programmer writing it.
So what is obviously needed is a security-minded IDE that embodies security best practice and enables goofs like me to turn out good, secure C. Built in goof alerts, stuff like that.
Can/does such a thing exist?
Built in goof alerts, stuff like that.
To a large extent you can help yourself to write safer code:
* always use the 'n' limited library functions instead of the unlimited equivalents, i.e. always use strncpy() instead of strcpy() and snprintf() rather than sprintf().
* where they don't exist, you can build a private library of fixed functions and use those instead.
* its also easy enough to write an awk script that can scan your code and report any unsafe library functions it finds. You could even make it return a failing error code if it finds anything unsafe and include it in your Make recipes.
So, don't wait around for somebody else to do this simple stuff for you: just do it.
Doesn't help with legacy code though - you'll potentially end up with thousands of uses being reported and only a few (if any) identifying the site of latent defects.
Code has to be written to be "good" rather than trying to use tools to detect errors after the fact.
You can use some tools to catch brain farts, but yes, you really have to know what you're doing and learn how to think.
Today, many who think that they can code, can't. The quality of software has gone downhill because bean counters look at the cost of developing software and then having it in production for less time because of the paradigm shifts and language shifts so expensive well written code becomes a luxury.
When you look to hire a senior level developer, check out to see what sort of watch he's wearing.
Ask him why he wears that watch. If he doesn't wear a watch and says his phone tells time for him... that's a major red flag.
"So, don't wait around for somebody else to do this simple stuff for you: just do it."
In addition: GCC has a ton of new sanity checks for you to enable.. Use them.
If your compiler provides a way to annotate varargs. Use them (ex GCC: __attribute__ ((format(printf, 2, 3)));"
If your compiler lets you annotate parameters as allows NULL/must never be NULL etc. Use those too.
Always make sure your code compiles without warnings.. Warnings are often the C language telling you that what you are doing is undefined and even if you leave the safe warnings in place they will hide the important warnings in the noise.
Then someone should do something about this. In fact I can remember reading about such solutions a long time ago in Dr. Dobbs Magazine. IIRC, something about overloading the basic memory functions to provide memory protections and automatic and clean recovery when exiting a function. What are they teaching them in computer security school lately.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
