Re: [Lit.] Buffer overruns
From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: Sat, 01 Jan 2005 12:57:43 +0100
Douglas A. Gwyn wrote:
> David Wagner wrote:
>> Ok, ok, let me anticipate one potential response. Maybe you are
>> "I'd much rather be sure I'll both get to the supermarket *and* live".
>> But this is often not an option.
> Then I think I'd move to where it was much safer to
> go to the supermarket!
Mmm, if you have much money, you could also employ someone
to do the purchase for you and let him risk his life just
in case ;-)
>> ... Sometimes there is no way
>> to ensure that both goals will be met, and then you have to consider
>> which goal is more important and build your system appropriately.
> This isn't about trade-offs, it about mistaking loss
> of correctness in the *primary design* for some
> incidental unforeseeable spurious random error. Since
> buffer overruns are foreseeable and, in an attack
> context not spurious nor random, the assumed error
> model is inapplicable. If you want to put effort into
> stopping such attacks, then allowing the flaws to
> exist and trying to deal with the consequences is far
> inferior to making sure that the flaws do not exist.
> The former allows a perpetual denial of service, for
> example, while the latter achieves its main function
> despite attack attempts.
> Air bags are helpful, but the main reason they were
> mandated was that drivers refused to take the trouble
> to use their existing safety harnesses.
What is your 'model' against hackers exploiting buffer
overruns? What do you do for that in your code? (Do you
know all the tricks that they could perform in the future?)
Cf. a recent post of Wagner.
M. K. Shen