Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How security flaws work: the buffer overflow

arstechnica.com

Post reply on HN
Print view View original

41–48 of 48 posts

Re: How security flaws work: the buffer overflow

#41

Post by nickpsecurity »

cm2187 wrote: post #3

The worse is that this error only happens because we are trying to save 4 bytes. If all arrays would also store their own size we could eradicate this bug with a limited memory impact.

You're in the right general direction. The replies to you are misleading and show the common problem of INFOSEC people having no knowledge of what was achieved in the past or present for immunizing systems. Systems far back as 1961 were immune to this with that one using 3 bits to do it [plus code/data separation]. CPU cost when done in parallel is almost zero. See my main comment.

https://news.ycombinator.com/item?id=10125348

Re: How security flaws work: the buffer overflow

#42

Post by nickpsecurity »

jakozaur wrote: post #11

There were so many critical vulnerabilities attributed to that... and in spite of putting tons of measures this is still potential danger. I knew projects decided to use Java instead of C++ (which got array boundary checks) mostly to limit security surface. Maybe if we could start CPU architecture from scratch, array with sizes would make more sense? Maybe even we could done it so memory segmentation would no longer…

Smart thinking. It was already done in a dozen different ways. Two cited in my comment:

https://news.ycombinator.com/item?id=10125348

Also see capability-based computer systems by levy. Free book. Pointer protection by itself can give all kinds of benefits. Modern version of that is Cambridge's CHERI processor which is open-source and already runs FreeBSD. :)

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

Re: How security flaws work: the buffer overflow

#43

Post by TazeTSchnitzel »

georgerobinson wrote: post #16
cm2187 wrote: post #3

The worse is that this error only happens because we are trying to save 4 bytes. If all arrays would also store their own size we could eradicate this bug with a limited memory impact.

It's not just their size, but wouldn't all arrays need know the address of their first element too? For example, consider a simple char buffer: char buf[512]; where we want to read x number of bytes from a file descriptor starting from a offset other than the first element: read(fd, buf + 256, sizeof(buf)); // Whoops, incorrect sizeof, buffer overflow! Could the compiler still detect this buffer overflow error withou…

For this case, you can use "fat pointers" that include the size of their destination.

Re: How security flaws work: the buffer overflow

#44

Post by dmix »

pyre wrote: post #36
dllthomas wrote: post #35

Earlier quoted context omitted.

The question is not just when we will have the tech, though. It is also when the tech will have an impact. A perfect Rust compiler only improves the safety of new (or rewritten) code.

I daresay that some codebases might rely on overflowing behaviour even if they don't know it. I've worked with a codebase where assumptions about unused RAM were that it was always zeroed out. Moving to a different platform (Linux) changed those assumptions, and there was lots of weird behaviour in the codebase because of that. I'll bet there are lots of legacy codebases that would actively resist using such a compil…

Legacy codebases like that tend to run on outdated operating systems, so addressing issues with buffer overflows in the software would probably do little to improve the security of the systems as a whole.

Re: How security flaws work: the buffer overflow

#45

Post by Alphasite_ »

shanemhansen wrote: post #27
jakozaur wrote: post #11

There were so many critical vulnerabilities attributed to that... and in spite of putting tons of measures this is still potential danger. I knew projects decided to use Java instead of C++ (which got array boundary checks) mostly to limit security surface. Maybe if we could start CPU architecture from scratch, array with sizes would make more sense? Maybe even we could done it so memory segmentation would no longer…

Friendly reminder: it's not just a choice between C and Java. In order to get bounds checking on arrays it's not necessary to give up the advantages of native programming and use a virtual machine. Rust is obviously a great example. So is Go. Bounds checked arrays in languages that compile to native is not a new thing.

Swift is another new language with it. Its getting to be the norm now.

Re: How security flaws work: the buffer overflow

#46

Post by dllthomas »

pyre wrote: post #36
dllthomas wrote: post #35

Earlier quoted context omitted.

The question is not just when we will have the tech, though. It is also when the tech will have an impact. A perfect Rust compiler only improves the safety of new (or rewritten) code.

I daresay that some codebases might rely on overflowing behaviour even if they don't know it. I've worked with a codebase where assumptions about unused RAM were that it was always zeroed out. Moving to a different platform (Linux) changed those assumptions, and there was lots of weird behaviour in the codebase because of that. I'll bet there are lots of legacy codebases that would actively resist using such a compil…

Certainly, though usually that winds up perceived as brittleness moving between compiler versions in general. Ideally, the tech we are discussing could help make it easier to understand those unknown behaviors.

But even if not, and even if this accounts for 60% of existing C/C++ codebases, improving the remaining 40% is a huge win that would take tremendously more time to reimplement in Rust.

This is not to say that I am not also very excited about Rust.

Re: How security flaws work: the buffer overflow

#47

Post by roghummal »

roghummal wrote: post #38
billyhoffman wrote: post #30

Earlier quoted context omitted.

I used to use Aleph One's article as a kind of shibboleth when interviewing candidates for security researchers. I'd just casually say "Smashing the stack..." and see if they would fill in the rest of the title. Not the best data point, but showed pretty quickly who had a self-taught (and usually practical) understanding of security vulnerabilities vs an academic understanding.

That's a class move and you are probably a cool person to work with.

That was not sarcasm.

Re: How security flaws work: the buffer overflow

#48

Post by bootload »

"The buffer overflow has long been a feature of the computer security landscape. In fact the first self-propagating Internet worm—1988's Morris Worm—used a buffer overflow in the Unix finger daemon to spread from machine to machine."

I thought the daemon exploited was sendmail? ... quick search later ... so the fingerd was used. Good explanation here: ~ Eugene H. Spafford, "The Internet Worm Program: An Analysis" http://spaf.cerias.purdue.edu/tech-reps/823.pdf

Post reply on HN