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

21–30 of 48 posts

Re: How security flaws work: the buffer overflow

#21

Post by cm2187 »

w0000t wrote: post #14
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.

What!? Size of the array is always known to the programmer in C. In fact, if the programmer wants to get rid of that information, he/she must deliberately do so. Once one does that, the array becomes useless. You also haven't explained how would that size information, which we already have, magically solve the problem.

A large part of overflows come from querying an array beyond its size. If the size of the array was already contained in the array (think of C# arrays which always have a Length property), developers could build more robust code that wouldn't rely on the size of the array being inferred from some other parts of the code.

Re: How security flaws work: the buffer overflow

#22

Post by drzaiusapelord »

ghuntley wrote: post #6

One of the best explanations ever written is the now classic "Cult of the Dead Cow issue #351 - The Tao of Windows [NT|95|98] Buffer Overflow" @ http://www.cultdeadcow.com/cDc_files/cDc-351/

>but if you don't have automatic bounds checking like Java, I guarantee you that those 'A's are going somewhere unfortunate.

20 years later and we're still using C++. I hope Rust takes off. The status quo today is terrible.

Re: How security flaws work: the buffer overflow

#23

Post by tedunangst »

ctz wrote: post #8
saurik wrote: post #4

Earlier quoted context omitted.

You have overlooked the CPU cost. Given that most memory objects already have at least an over-approximate size somewhere , and how we are more than happy to annotate stacks with canaries, I really don't think anyone is as concerned with the memory cost of adding a size to every array as the CPU cost of adding a read and compare to every array access.

Intel is adding hardware array bounds checking called MPX in skylake, so this could become a reality.

There already was a BOUND instruction. Nobody ever seems to remember this when they propose adding such an instruction.

Re: How security flaws work: the buffer overflow

#25

Post by rnovak »

renox wrote: post #15
saurik wrote: post #4

Earlier quoted context omitted.

You have overlooked the CPU cost. Given that most memory objects already have at least an over-approximate size somewhere , and how we are more than happy to annotate stacks with canaries, I really don't think anyone is as concerned with the memory cost of adding a size to every array as the CPU cost of adding a read and compare to every array access.

I think that the CPU cost could be reduced if the CPU had some kind of instruction for array access: if you 'hardcode' that an 'array' has its address stored in register Rx and its length stored in Rx+1, you can easily have an instruction " checked_load Ry " this instruction can have a latency similar to a normal load instruction as it could check the value of the index with Rx+1 in parallel to the load (1). And if y…

I think the problem a lot of people would have is that introducing hardware, which costs millions to design and bring to market, when it's possible to write code that isn't prone to overflow....just doesn't seem like a good idea.

When I was in school, my professor for CPU Architecture had a good saying: "If you're going down to NAND gates to debug your software you're doing something wrong".

I think another issue is that arrays, trees, and other structures are a complete abstraction. The CPU doesn't need to know a thing about them for them to work, because all it actually sees is addresses and instructions (I get that I'm grossly oversimplifying things), and so introducing that type of "check" at the hardware level is pushing the abstraction down, and I don't think that's a good idea either.

But I do think that's one of the great reasons for using a higher level language, where there are array bounds checks, etc.

To me, C/C++ is like "pretty" assemby language (Now with new features like Undefined Behavior!!!), and I like that about it. But I'm not sure how other people feel.

Anyways, that's just my take on it, take it with a grain of salt.

Re: How security flaws work: the buffer overflow

#26

Post by dmix »

drzaiusapelord wrote: post #22
ghuntley wrote: post #6

One of the best explanations ever written is the now classic "Cult of the Dead Cow issue #351 - The Tao of Windows [NT|95|98] Buffer Overflow" @ http://www.cultdeadcow.com/cDc_files/cDc-351/

>but if you don't have automatic bounds checking like Java, I guarantee you that those 'A's are going somewhere unfortunate. 20 years later and we're still using C++. I hope Rust takes off. The status quo today is terrible.

Also of note is the lack of investment in exploit mitigation at the operating system and compiler level. C++ and C are not going away from our systems any time soon. Yet exploit mitigation technology still remains on the sidelines of the security world while bug squashing, AV, and IDS are flush with cash.

Re: How security flaws work: the buffer overflow

#27

Post by shanemhansen »

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.

Re: How security flaws work: the buffer overflow

#28

Post by shanemhansen »

pyre wrote: post #18
rawdisk wrote: post #17

Are "buffer overflows" possible in systems without without virtual memory? I know how I would answer this question but I am curious how others would answer it. EDIT: s/possible/known to occur

As long as you have the ability to address memory directly, I would say that it's possible. I'm not 100% sure about how memory is allocated though. Outside of virtual memory, are the actual chunks of memory sequential, or would overflowing an offset get you a chunk of another process? (I imagine the answer might be implementation dependent)

It's more important to have bounds checked access and to disallow pointer arithmetic. If you do that, pointers (addresses) are fine.

Re: How security flaws work: the buffer overflow

#30

Post by billyhoffman »

kriro wrote: post #2

Alternatively (just the concept, this should not work as outlined on modern systems): http://phrack.org/issues/49/14.html

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.

Post reply on HN