On 14 February 2011 21:54, Rick Stevens <ricks@xxxxxxxx> wrote: > On 02/14/2011 11:23 AM, Joe Zeff wrote: >> On 02/14/2011 10:03 AM, James Mckenzie wrote: >>> I've found very obvious buffer overflow conditions and failures to enforce changes of variable types in publically available code bases. >> >> It's been years since I did any C programming, and my memory of it is >> dusty (as Ziva David once phrased it) but I do remember that there are >> two, very similar functions for copying strings. One copies as many >> bytes as you give it, the other copies only as many as you specify if >> there are "too many" given. Just using the second instead of the first >> would prevent most of the easier buffer overflow exploits, if not all. >> By now, I'd think that would be automatic, but then, I'm not a >> programmer any more. > > You're talking about "strcpy()" (copy until you see the NULL) and > "strncpy()" (copy until you see the NULL, but no more than N bytes). To derail discussion slightly, this doesn't really fix the problem, just shifts it to a different place (keeping track of lengths and dynamically handling data), the problem being that people for whatever reason, be it laziness or time pressure or something else) make poor assumptions about the data combined with the traditional C string handling not being great. There are a few GNU extensions which make life much simpler, I spent a while some time ago fixing some code which made heavy and buggy use of static buffers for strings with a liberal application of stuff like getline and asprintf, which is easy to do and reduces your potential problems to memory leaks (which on most systems will die when your application does). If you have licensing problems with glibc or need to work on a non-gnu platform then these are pretty easily implemented from their specs. While C hasn't moved as far as C++ or modern languages (you have to work at allowing a buffer overrun in Python), James Mckenzie is right, this shouldn't happen any more. Unfortunately it still does. -- imalone -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
