Sometimes people don't really get the point of defensive programming for security...

re: Sometimes people don't really get the point of defensive programming for security...

Jdev — Fri, 24 Nov 2006 06:03:31 GMT

If C# and C++ are too slow, then switch to Java.

I switched and never looked back.

re: Sometimes people don't really get the point of defensive programming for security...

Chris Lightfoot — Sat, 04 Nov 2006 02:13:44 GMT

He's not claiming that you should use assert(3) for parameter validation; indeed in that bit of the article he explicitly states that he wants to avoid doing parameter validation everywhere on efficiency grounds(!). The assert is just an expression of the "contract" of the function. Sure, the suggestions are pretty silly, but not really in the way you suggest, at least in that case.

re: Sometimes people don't really get the point of defensive programming for security...

Sun, 29 Oct 2006 05:08:00 GMT

"A few days ago I used _tcscpy safely. I ran a few _tsclen calls, added the results, did a malloc, checked the result of malloc, and then if still running I copied each string to the appropriate portion of the resulting buffer."

Did you remember to check to for overflow on your addition?

re: Sometimes people don't really get the point of defensive programming for security...

DaveZero — Wed, 25 Oct 2006 08:37:33 GMT

As I understand it, the main argument against to "Why stop here [C++] and not switch to C# or VB[.NET]?" is that C++ is still a LOT faster running...like 16 to 64 times faster...mostly due to the asbsence of strict variable typing and the direct access it affords to memory.

That's how I used to think even just a few years ago, and I still do, to the extent that I think unmanaged code is still a hellalot better for, say, massive scientific simulations and the like, because it's still WAY WAY WAY faster, deny it all you like.

However, for pretty much any business-related project I could imagine, and most anything else non-scientific (or gaming), the hardware is now simply so fast that: who cares how much slower managed code executes?...it's just not generally an issue that it runs many times slower. So, in the final analysis, I would never use C or even C++ for anything usual, especially if I needed the result to securly withstand public use.

re: Sometimes people don't really get the point of defensive programming for security...

kiwiblue — Wed, 11 Oct 2006 19:42:06 GMT

> The real solution is to use C++

Why stop here and not switch to C# or VB?

re: Sometimes people don't really get the point of defensive programming for security...

sohail — Wed, 11 Oct 2006 04:14:58 GMT

The real solution is to use C++

re: Sometimes people don't really get the point of defensive programming for security...

ndiamond — Sun, 08 Oct 2006 04:55:49 GMT

Friday, October 06, 2006 3:03 AM by Phaeron

> formal proof of buffer overflow impossibility through static

> analysis and design is a MUCH better way to produce secure

> software than runtime buffer size checks?

That is 100% true.

For some kinds of programs you can do a formal proof. How do you construct a formal proof? In my experience it was done by humans applying logic to demonstrate that each fact is provable from previously proven facts. In other words, humans were applying the same logic that humans apply in writing programs. So the bug rate wasn't zero, the bug rate might potentially be geometrically lower (two simultaneous failures being geometrically less probable than one failure), but the actual results weren't that good.

In the general case there won't always be even a theoretical possibility of a formal proof. It reduces to the halting problem.

Now, C strings are miserable. Most of the C language combines the power of assembly language with the beauty of assembly language because it was invented as a substitute for assembly language. Of course since being standardized it's not always possible to use it that way any more, but it still reflects the beauty of its origins (^_irony). The strings section of the library seems to have been designed more hastily. It took advantage of machine instructions which an assembly language programmer could code quickly for one kind of machine. It didn't prepare for efficient but harder coding that would measure once before copying and concatenating and comparing several times. C++, being object-oriented assembly assembly, derives with the same weak base, though it's a bit easier to make counted string libraries that will be easily usable by clients.

A few days ago I used _tcscpy safely. I ran a few _tsclen calls, added the results, did a malloc, checked the result of malloc, and then if still running I copied each string to the appropriate portion of the resulting buffer. Then I cringed at the thought of what will happen when someone copies and pastes the code without figuring out why it was OK this once. I wished I could just use VB's & operator instead.

re: Sometimes people don't really get the point of defensive programming for security...

Phaeron — Fri, 06 Oct 2006 10:03:37 GMT

I think the real point of the article is being missed here. Surely everyone here would agree that formal proof of buffer overflow impossibility through static analysis and design is a MUCH better way to produce secure software than runtime buffer size checks? Just checking string bounds isn't always enough -- you have to make sure that a truncated string isn't used in a way that could cause a different vulnerability, or that throwing exceptions doesn't allow an easy way to cause a DoS, etc. I don't think bounds checking is a bad idea, as it definitely helps with robustness as well as security (think hardware errors!), but it's not a _great_ solution. For calls that are solely internal, it's a bit like speculatively adding try/catch. Personally, I would rather see more emphasis on language features and tools that help me declare and enforce guarantees at compile time, because that would help avoid a lot more problems than just buffer overflows. Also, I think the performance issue is a bit of a red herring, not because the checks are "free" -- they aren't, either in runtime or code size cost -- but because string operations themselves aren't cheap, and overuse of strings is a common performance problem.

re: Sometimes people don't really get the point of defensive programming for security...

Anony Moose — Thu, 05 Oct 2006 23:15:48 GMT

If you're the world's best and safest driver, seatbelts protect you from all the morons out there. If you're the world's best and safest programmer, safe string copy functions protect your code from all the morons out there who accidentally work around your safety checks. And, also, if you're not quite as great as you think you are, they keep you from getting a whole lot of egg on your face. ;)

re: Sometimes people don't really get the point of defensive programming for security...

Larry Osterman [MSFT] — Thu, 05 Oct 2006 19:33:14 GMT

sergei: Interesting. I've never heard of that usage for strncpy (checking the byte at <length> for 0). I much prefer APIs that return errors when they fail as opposed to having to probe for side-effects.