On Mon, 2004-05-10 at 12:11, Stuart D. Gathman wrote:
On Mon, 10 May 2004, Jeremy Pullicino wrote:
Buffer overflows are a result of incompetent programming and not macro
expansion so the DVP people are wrong on this point.
It's the result of incompetent programming with a dangerous language
such as C. While there are other things to screw up with bounds
checking languages (like Python or the Perl reference implementation),
buffer overflows at least are eliminated.
The most common security problem I've seen with high level language
implementations is passing shell meta-chars along to a shell, or
passing client data to an eval().
Buffer overflows can be easily avoided in C. Interpretive languages are
the devil! I'll tell you why. They make for LAZY programmers who grow
overly comfortable with having everything done for them. IMO its a
byproduct of this "now" generation where everything must not only be
easy, and non-complex, but it must also happen in an instant. Writing
everything in interpretive languages is certainly a shoddy solution to
eliminating buffer overflows. Why not simply debug your application?
Something like Valgrind goes a long way at removing BOF's.
Like all things, there is a time and a place, or more specifically,
there is a "right tool for the job". Interpretive languages have high
overhead, and can not be easily optimized for specific tasks, and I'm
sorry, but I REFUSE to accept idiotic statements like "Well CPU's are
much faster these days..." as reasons to use interpretive languages in
places they don't belong.
Perl is my second most favorite language, however, just because I can
write a web-server in it, doesn't necessarily make it a great idea. And
just because that web-server might not necessarily be prone to buffer
overflows, that doesn't mean its not exploitable. I don't know about
you, but I've had my way with more than a few CGI's to find my way in
the back door... so rather than looking for shortcuts, why not just DO
IT RIGHT the first time? Whatever language is being used, people should
be taught to program PROPERLY. And code that does not meet some
acceptable level of standard, should be refused or held back. Whilst I
realize that is is somewhat of an idealistic viewpoint, we are where we
are today (the sheer volume of exploits and exploitable pieces of
software) because of poor decision making and lazy "scripters".
Cheers,
James
--
James Couzens,
Programmer
-----------------------------------------------------------------
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scehem library
-----------------------------------------------------------------
PGP: http://gpg.mit.edu:11371/pks/lookup?op=get&search=0x6E0396B3
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/spf-draft-200404.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
signature.asc
Description: This is a digitally signed message part