
How security flaws work: The buffer overflow - rbanffy
https://arstechnica.com/information-technology/2015/08/how-security-flaws-work-the-buffer-overflow/
======
tptacek
Despite the later references to ROP, this basically captures the mid-1990s
state of the art in memory corruption bugs.

------
feelin_googley
"Blame C"

"As an example of C's utter hostility toward safe development..."

Am I misreading or does this author fail to see any distinction between a.
programming language and b. functions in a "standard" library, e.g. gets(),
authored by particular C programmers?

The most "secure" programs I have ever seen are written in C. The reason they
are so "secure" is not because of the language chosen, but because of the
_competence_ of the person who wrote them. He writes his own basic functions
and uses very few from the "standard" C library. (Not necessarily
"reimplement". He may implement basic functions that have _no equivalent_ in
the C "standard" libraries.)

Secure is not in quotes to be "sarcastic". It is because there is always the
chance someone will expose a serious flaw in these programs. It is a
subjective assessment of security. However it has been roughly 20 years and no
one has done so yet.

~~~
mikeash
Is "secure" in quotes because you're being sarcastic? I would expect the venn
diagram of people who reimplement standard library functions and people who
write really secure C to have pretty much no overlap.

~~~
tedunangst
As legend has it, DJB rerolled most of libc for qmail.

