On 23/03/15 18:38, Nicolas George wrote:
There is something you still do not seem to realize: if your stack is
corrupted, abort() is just a crash, anything else is a security issue,
including "return foo".
The stack must not be corrupted to begin with, putting an assert after
the fact is wrong, since it can easily not trigger as well... (or
trigger the shellcode itself)
I do care about Deny Of Service and that's why I'm slowly removing all of
this.
Replacing them by untested dead code.
Code that can be tested and verified easily actually.
An assert is exactly that: an assert means "I am sure my code is right, but
errare humanum est, and if it happens to be wrong a crash is better than a
security issue."
What part of this would you want to refute?
First, if you consider an assert a mean to check that a memory
corruption happened after the fact, you are doing it wrong in all the
possible ways once the memory is corrupted you lost.
Second, there are already good tools to prevent the kind of problem it
causes discomfort to you.
Third, most of the ~400 assert() and ~100 avassert*() are (luckily) not
misguided last safety against code injection.
Last, the assert that triggered this conversation is not within the
group you consider scary, but is really trading a return
AVERROR_INVALIDDATA for a crash.
lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
