Text 5140, 83 rader
Skriven 2010-02-22 15:49:31 av Michiel van der Vlist (2:280/5555)
     Kommentar till en text av Ross Cassell (1:123/456)
Ärende: Windows Update Fix
==========================
Hello Ross,

On Sunday February 21 2010 10:20, you wrote to me:

 RC>>> Its not so much the quality of the code as it is the tenacity of
 RC>>> the bad guys to find and create new ways to get in that the code
 RC>>> writers didnt think of.

 MV>> If the code was good, they would not be able to get in. Period.

 RC> and the HMS Titanic was unsinkable.

Or so the makers falsely claimed. That does not mean one can not write good
code.

 RC> The code writers might be short sighted in calculating every possible
 RC> vector of attack..

Ever so often the problem is not that the programmers overlooked a way to open
the door, the problem is that there should never have been a door in the first
place.

The old FidoNet members from the DOS age may remember the "ANSI bomb". Among
the ANSI codes to position the cursor, change colour, etc, etc, there was also
a code to redefine a key and put a macro under it. So a text file could contain
code to redefine the return key as FORMAT C:<return>.

It is a door that should never have been there to begin with. A text viewer
should NEVER be able to execute another program. Redefinig keys should only be
possible from the keyboerad istself. Smart sysops used a modified version of
ANSII that does not have the redefine key feature.

 RC> But your musing isnt limited to M$ products, nor do I think you can
 RC> write bulletproof code unless you have insight on how people might
 RC> misuse the program in order to defeat it.

Most of the problems are created by doors that should not have been there in
the first place. Some doors are put there by design. See above. Some by sloppy
programming.  One of the most infamous is "buffer overflow". That could never
happen if the programmer includes code to check array bounderies. Good code
should NEVER write outside the assigned buffer. That is elementary and I am
surprised that buffer overflow exploits still happen.

In defence of the programmers I add that they often have to work under pressure
from "above". I have been a professional programmer myself. In 1992 I was
laying the last hand on a piece of measuring equipment for which I had designed
both the hardware and the firmware.

I was doing some final test when my boss came leaning over my shoulder and
asked me what i was doing. I told him I was checking if it would still work all
right after 1 jan 2000. He asked if it was otherwise ready and I said yes.

He told me to drop it and ship it to the customer right away. I protested, but
to no avail. 2000 is eight years in the future and we are not going to worry
about what will happen in eight years my boos said. I was ORDERED to drop it.

I expect I was not the first nor the last programmer that had that happen to
him.

BTW, I never knew if the thing actually was Y2K proof. I expect it was, because
I designed it to be, but I never got the chance to do the final test. I left
the company in 1996 and it went belly up the year after....

 RC> A company that makes battle tanks can design their tanks to have such
 RC> and such armor, be able to withstand this, that and the other thing,
 RC> but sooner or later, a potential adversary will have come up with a
 RC> way to defeat the tank. Why is this different from computer code, the
 RC> assholes whom write it have nothing but time and money incentive to
 RC> pry and poke?

It is different because a physical object like a tank is subject to the laws of
physics. The laws of physics say that a material object can not be of infinite
strength. The amount of energy one cab throw at it however is not limited by
the laws of physics. So it is not possible to make an indestructible tank.

Software OTOH, is not subject to the laws of physics.  It can be made
"unsinkable".


Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20070503
 * Origin: http://www.vlist.org (2:280/5555)