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.)
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
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
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
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
Why couldn't a link have been given to the place that first aired this story?
/. works. Try reading the FAQ before opening your yap.
You obviously do not understand how
Also, by removing down-moderating this post, you are proving my point that you censor what isn't convenient or fits your own purposes.
Once again, read the FAQ. Nothing is censored. Set your threshold to -1 and you can read all the trolls, like this one.
You are clueless.
Tequila: It's not just for breakfast anymore!