Re: Microsoft Zero Day security holes being exploited

On Thu, 28 Sep 2006 02:18:47 -0400, imhotep wrote:
cquirke (MVP Windows shell/user) wrote:
On Mon, 25 Sep 2006 05:45:39 +0100, "Stephen Howe"
"Ian" <Ian@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message

And note, I don't regard C as inheritently unsafe - it is just it requires
programmer discipline.

Humans are just system components, along with everything else - and as
such, they have notoriously high error rates.

I include myself in that frame - whenever something unexpected
happens, I always assume "user failure" on my part as the cause.

With C, the mindset was that programmers are smart enough
not to need training wheels, and the beauty of C was that it stayed
out of your way so you had full control (and full responsibility).

Seems his is more of a Microsoft problem than anyone else. Maybe it is not
languages fault after all!

I'm not sure if it is; if anything, it may be the reason why fleeing
MS for *NIX or MacOS doesn't reach the Promised Land after all.

The #1 reason why Windows is hit as hard as it is, is because it is
such a large target. In fact, MS's patching has made it harder work,
so there's been some deflection of attention towards softer targets,
such as commonly-used 3rd-party add-ons. There are several of these
that have larger markey share than the next most common OS, and
attackers can more easily leverage what they know about working within
Windows to build malware onto 3rd-party surface exploits.

I see things even in my fave software, such as Eudora, that I know
would become an exploited headache if these apps ever attracted as
much attention as Windows. I still prefer to use these alternatives
because the design is better and safer, and the risk of them being
exploited is lower, even if it would be easier to do so.

...and the problem with high level languages is that they put to many
restrictions on you. Higher layer languages were not designed, nor any
language, to hide the programmers ineptness!

Well, this has always been the ping and the pong. Software engineers
want good, non-heroic coding standards, while programmers would often
prefer the elegant dance on the edge.

Programming languages were originally written for completely different
reasons; FORTRAN for maths, Cobol so that PHB managers could
understand what programmers were writing, Pastel to teach proper
structured programming... and finally C, which was written so that
programmers could actually write efficient programs.

C was the first language that one could envisage replacing native
assembler, as it could approach it in runtime performance. It was a
key way to span disparite tribes of UNIX and hardware, via a common
source code base that could be library'd and compiled to whatever the
native system actually required.

Since then, we've seen some flight from the raw power and performance
of C. The balance has tilted; for many bread-and-butter applications,
processing resources are cheap while coding labour is not. It makes
more sense to throw a few $$$ at more RAM, HD or CPU speed than to
throw the same at more programmers, or longer development cycles, to
get the code to run fast enough on thinner hardware.

The other change that dates from C onwards, is that it's very rare for
a programmer to control every part of what the program does. This was
what put me off programming; having to use huge wads of other ppl's
code, i.e all those code libraries and API calls. You may well find
there are more errors at all the user/service interfaces between code
levels, than there are within the code itself.

The end-user's famous last words...

"But I thought you did the backups?"

....becomes the nemesis of code re-use...

"But I thought you checked the parameters?"

Languages, and the program that results, will ONLY be as good as the
programmer is...

Yeah, that's the problem. Expect failure, design for it.

You've heard the expression "if you're one in a million, there are x
million people out there just like you"?

Well, what's your personal error rate? Let's say a slack person makes
1 error in every 500 operations, while an excellent coder (who by now
is probably too expensive to actually have writing code) has an error
rate of 1 in every 5000 operations.

Great - now take that code and run it at, say, 1 million operations a
second. How well do you expect it to work? Well, better than the
numbers suggest, because 90% or the time, you'd be running 10% of the
code, and that 10% is going to get really well tested.

Fine... now let's re-use this code 3 years later. It's mature code,
right? After all, it's been used for years without having to be
bug-fixed. Except this time we're using it in a different way, and
probably exposing it to direct Internet access. Join the dots.



--------------- ----- ---- --- -- - - -
Tech Support: The guys who follow the
'Parade of New Products' with a shovel.
--------------- ----- ---- --- -- - - -
.

Quantcast