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

11–20 of 48 posts

Re: How security flaws work: the buffer overflow

#11

Post by jakozaur »

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 be needed: https://en.wikipedia.org/wiki/X86_memory_segmentation

Haven't figured out the details, but maybe we can even gain some performance that way.

Re: How security flaws work: the buffer overflow

#12

Post by hannob »

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 can get pretty tough protection with address sanitizer (it works technically a bit different). It doesn't come for free however. It's much faster and better than anything that was there before (e.g. valgrind), but the performance impact is still significant. Still I think address sanitizer is an amazing project that should definitely get some more publicity.

Re: How security flaws work: the buffer overflow

#13

Post by wslh »

cm2187 wrote: post #5
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 am not necessarily suggesting checking array boundaries on every array access, but at least providing an easy and safe way to refer to the array size. Array boundary checking is I think desirable but I can understand that for some applications it is an unacceptable performance hit.

This exists for years: https://msdn.microsoft.com/en-us/library/windows/hardware/ff...

Re: How security flaws work: the buffer overflow

#14

Post by w0000t »

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.

Re: How security flaws work: the buffer overflow

#15

Post by renox »

saurik wrote: post #4
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 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 you have a 'load aligned double word' instruction which load two consecutive word in Rx and Rx+1 (aligned to avoid the thorny issue of page missing in the middle of an instruction), you can reduce the cost of having to manage both the array address and its length.

Sure this isn't free: more registers used, more cache used, still it doesn't look THAT bad from a performance POV no? Or very complex to implement. Is-there something I'm not understanding?

1: and if the checks fails there is TRAP executed, which is compatible with C/C++ semantic.

Re: How security flaws work: the buffer overflow

#16

Post by georgerobinson »

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 without knowing the address of the first element in the array?

What about:

    char *dst = buf + 256;
    ...
    read(fd, dst, sizeof(buf));
perhaps the compiler could trace back all the calculations performed on the dst pointer to see whether this operation is valid?

Re: How security flaws work: the buffer overflow

#18

Post by pyre »

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)

Re: How security flaws work: the buffer overflow

#19

Post by scott_s »

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

Yes. Why would you think not?

If you're thinking that memory for the program is less likely to be contiguous, then, yes, that is a way it may end up being less likely. But there are already techniques that do exactly that for systems with virtual memory (see https://plasma.cs.umass.edu/emery/diehard.html). But as long as you have a stack frame contiguous with a previous stack frame, you're susceptible to buffer overflows, and I think that will be likely even without virtual memory. (That is, the stack frames are not that large, and are likely to be well within the contiguous block size for the memory system.)

Re: How security flaws work: the buffer overflow

#20

Post by asanagi »

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.

if passing array by reference to an external function means 'deliberately getting rid of' the size information...
Post reply on HN