Slashdot Mirror
String Cleanup Results On OpenBSD
Dan writes "OpenBSD's Theo De Raadt provides an update on his team's efforts to remove potential buffer overflows within OpenBSD code by always calculating what the bounds of an operation are. They have been going through the source tree cleaning out all calls to sprintf(), strcpy(), and strcat(). Theo says that they have removed (replaced) approximately 2000 occurences of these functions." (The same buffer overrun-squashing effort was mentioned earlier this month.)
I kind of admire Theo, but it's SOOOOOO tempting to call him "Theo the Rat".....
Good work OpenBSD team!
Does the BSD team have a list (or rules of thumb?) that mentions other safe coding practises? There has to be book on this, right? (I've always been impressed by the pro-active stance BSD takes towards security -- I just wish the rest of the commercial world could afford the time to do things right, instead of the cheesy no liability out-clause in the EULA.)
:)
If most developers are still using these "trivial" funcs, I'm scared what other funcs are just as buggy!
Funny how one can forget all about these "harmless" bad practises. Time to add it to the internal coding standard.
These guys have been claimng to be super-secure and constantly performing security audits on the OpenBSD code for years.
Yet they've launched a major effort to cleanup 2,000 unsafe string functions in the last two months...
What has Theo been doing all this time other than being an obnoxious prima donna and re-writing packet filters because of some minor squabble?
Conformity is the jailer of freedom and enemy of growth. -JFK
Look people, I can read this news, and get more comments on it at deadly.org. Let the specialty and community-oriented news sites do their thing. Why couldn't a link have been given to the place that first aired this story? Give credit where credit is due, damnit. What, is your next BSD story going to be the continued DARPA funding? If the news is happening at Deadly.org, have some class, and give them some flow. Take a page out of Dave Winer's book.
Also, by removing down-moderating this post, you are proving my point that you censor what isn't convenient or fits your own purposes. Objectivity is sorely needed here, and the best place to start is by rigorously acknowledging the origins of a story. Be a part of the solution and not the problem, take some criticism once in a while, don't restrict your news items to what is simply in your own best interest!
That is all.
I wonder when Theo can say they have removed ALL occurrences of these functions??
But more importantly, why wasnt it possible to replace the functions in the library with something (if a bit slower) robust?
Are we witnessing the evolution of the New Libc(tm) ?? Can I patent it?
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
To answer your question, it's not possible to replace the original functions in libc because there's no maximum length param in those functions (unlike the safer "n" equivalents like snprintf()).
...when his mother/SO said, "I think you should do some spring cleaning."
Something that irritates me about using MSVC:
/* wont compile */ /* will compile */
#include
void main(void){
char buff[1024];
snprintf(buff, 1024, "Test");
_snprintf(buff, 1024, "Test");
return;
}
GRR!! Very annoying when trying to write code for both win32 and *nix.
Exactly, the bugs are in libc, not the calling programs. OpenBSD should remove all dangerous libc functions, like sprintf() and strcpy(). Then unsafe user programs will not even compile. If OpenBSD is really, really serious about security, they could then disallow these unsafe programming practices. Source code ported to the new restrictive OpenBSD libc would benefit on other platforms, too.
If forever removing strcpy() and friends is just too radical, OpenBSD could use a transitional approach by moving the function prototypes of the unsafe libc functions to a non-standard header file. Call is something like unsafe.h, deprecated.h, or i_like_buffer_overflows.h.
cpeterso
[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It'
At least functions that call that stuff could produce a warning to stderr, like other functions are known to do.
Would be pretty neat.
The problem with removing strcat and strcpy is that you can use them safely if you put some thought into what you're doing. There's no reason to ban them from libc just because some programmers don't check their buffer sizes. Removing the old string functions would make a lot of code not work on OpenBSD.
Also, the OpenBSD team isn't going to touch most of the third party code in the tree: "We are obviously not doing this to some parts of the tree which we borrow from other projects. In particular, the gnu part of the tree might remain largely dirty." So they'd kill a lot of functionality by banning them. They did make the changes in OpenSSL and Apache and it sounds like they've had some luck convincing the BIND and Sendmail guys to move to strl. It's obvious OpenBSD knows you can't change the world, but they can change their neighborhood and set a good example.
What they might end up doing in the future is adding a compile time warning similar to the one generated by mktemp that suggests using mkstemp instead. That's probably the best approach.
Groan. Umm, we do spring cleaning in the southern hemisphere too ya know! Our spring follows winter (the cold one) and preceeds summer (the hot one) as well!! The only difference is the time of year.
// todo: implement sig
Sometimes it's "safe" to use "unsafe" calls. For example it's never safe to use gets() but I can use strcpy() if I know that the src does not exceed dest. If I know how big my buffers are, and have taken into account every possibility for the size of the buffer being copied... Should I be penalized by having to bother with a size argument, or a slightly slower strcpy()?
Some people on here are asking what the obsd group has been up to over the past few years. Some are claiming that they have spent a couple years rewriting packet filters, and are just now checking for unsafe string handling. This is not true. The source tree was/and is continuously being audited. strcat/strcpy/sprintf can be dangerous functions, BUT BUT BUT BUT, if they are used with proper condition checking code before they are called (as the obsd src does), then they are no more dangerous than strncat, etc. i.e.
:-)
char buf[10];
if(strlen(ptr) < sizeof(buf) - 1){
strcpy(buf, ptr);
}
This example uses an unsafe function, but in a relatively secure way.. (assuming strlen(...) works properly