How long should it take an average coder (has used C/C++ but isn't an expert) to understand what a buffer overflow is, why its a bad thing, and how someone might use it to take control of the application?
+1
A:
Understanding what a buffer overflow is and why it's a bad thing should take no time at all.
Understanding what a buffer overflow exploit is and how they work is another matter.
Fortunately, you don't really need to know how the exploits work to be convinced that buffer overflows are bad. Aside from the the fact that any programmer should be able to understand that they can be exploited is enough of a reason to avoid overflows (even if they don't understand how the exploit works), data corruption itself is enough of an argument.
Explaining how stack buffer overflow exploits work is no small task, especially if the person trying to understand them does not have a strong knowledge of the platform's instruction set, calling conventions and stack usage.
Wikipedia has decent explanation, but it's no walk in the park:
Also, Michael Howard's "Writing Secure Code" book has very good descriptions and exercises to explain how they work, but once again it takes some study.
Michael Burr
2009-01-27 00:21:30
+1
A:
I would think that a buffer overflow is something you learn about in one of your first programming classes. If it's not... yikes. And part of learning what it is should include learning why it is bad (i.e. how it can be used against you).
JMD
2009-01-27 00:37:22
+1
A:
Most "average programmers" who graduated in the past 10 years work with sandboxed languages like C# and Java and may not even understand what it means to allocate memory in way that you could actually skip from one location to another.
In my limited experience, explaining that concept is what's going to take a long time.
To an experienced C++ programmer, maybe 3 seconds.
Uri
2009-01-27 00:39:30