Hacker News new | comments | show | ask | jobs | submit login
How security flaws work: The buffer overflow (arstechnica.com)
39 points by rbanffy 10 months ago | hide | past | web | favorite | 5 comments

Despite the later references to ROP, this basically captures the mid-1990s state of the art in memory corruption bugs.

"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.

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.

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

I'm not sure where you're getting this from the article? It's just going over the callstack.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact