How security flaws work: the buffer overflow
arstechnica.com
How security flaws work: the buffer overflow
1–10 of 48 posts
Re: How security flaws work: the buffer overflow
#2Alternatively (just the concept, this should not work as outlined on modern systems):
http://phrack.org/issues/49/14.html
Re: How security flaws work: the buffer overflow
#3The 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.
Re: How security flaws work: the buffer overflow
#4The 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.
Re: How security flaws work: the buffer overflow
#5The 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 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.
Re: How security flaws work: the buffer overflow
#6One 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/
Re: How security flaws work: the buffer overflow
#7Alternatively (just the concept, this should not work as outlined on modern systems): http://phrack.org/issues/49/14.html
i like this one better.
Re: How security flaws work: the buffer overflow
#8The 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.
Intel is adding hardware array bounds checking called MPX in skylake, so this could become a reality.
Re: How security flaws work: the buffer overflow
#9Earlier 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.
I presume it would only be used for code compiled for skylake?
Re: How security flaws work: the buffer overflow
#10Earlier 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.
> Array boundary checking is I think desirable but I can understand that for some applications it is an unacceptable performance hit.
Given the severe potential security implications for not using it, enabling bounds checking is a sensible default in my opinion. People always mention the speed of C for example but ignore what is being sacrificed for it.