Re: (part 30) Han from China answers your C questions

Anthony Fremont wrote:
Andrey Tarasevich wrote:

To the OP: I hope you understand, that while the potential buffer
overrun issue present in the original version of the code is a serious
problem, trying to fix that problem by simply _truncating_ the data,
as our "Han from China" did here is not even remotely a viable
solution. It is rather a way to sweep the problem under the carpet
and make it resurface elsewhere. What "Han from China" apparently is
trying to tell you is that code that doesn't crash and doesn't work
is better than code that crashes. In reality, the exact opposite is
true: when your code's internal invariants are irrecoverably
violated, the best possible outcome is the one when the code crashes
as soon as possible, instead of continuing to run.

I'm certainly no C expert, but from a programming standpoint I disagree. What exactly should the program do?

It heavily depends on the application area. But generally, if the error is unrecoverable, the program should just quit.

It can't possibly reconstitute a valid address if the length isn't 4 (this is assuming IPV4). Allowing the program to write all over memory is certainly no guarantee that the program is going to crash either. Tens of thousands of buffer overflow exploits speak for themselves. While not being the "perfect" solution, the Han from China approach is orders of magnitude better than allowing an overflow in this example.

I'm in no way trying to push the original (overflowing) version of the code as the "proper" one. As I said before, it does suffer from a very serious problem, which needs to be taken care of. But sweeping it under the carpet, as "Han" suggested, is not even a remotely valid way to deal with it. It simply replaces a current known error with an future unknown one.

Code that doesn't crash and doesn't work (when given garbage input) IS far better than code that simply trusts its input and crashes.

While your original logic is correct (aside from your misunderstanding of my intent), the conclusion that you make here is not. In reality, neither way is really acceptable. The real danger of the original (overflowing) code is that instead of making the program crash, it will actually continue to run, opening the possibility of various buffer-overflow-based exploits. In other words, at certain level of abstraction the danger of the original code manifests itself in generally the same way as the one in the modified code: the code continues to run after its invariants have been broken. For this (purely theoretical reason) I'd half-jokingly refer to the original variant as "better one" because it seems to have a better chance to crash right away. But seriously, once again, neither variant is really acceptable.

--
Best regards,
Andrey Tarasevich
.

Relevant Pages